I’ve been writing a little bash script to wrap up the functionality in the JIRA CLI, and i’d noticed that sometimes, my script was spitting out the following error:

sh.exe": [: too many arguments

The code in question was:

j () {
if [ -z $3 ]; then
echo jira --action progressIssue --issue "$1" --step "$2";

It turns out the problem was that the variable $3 in the second line was being substituted directly into the if statement, without being quote delimited. So Bash is treating any input in $3 with spaces as multiple arguments (hence the “too many arguments” error). Duh.

Solution is to quote the $3 variable in the conditional to treat it as a single argument. Shouldn’t make this mistake again…

The marketing of the LaCie Network Space 2 claims that the device is Time Machine compatible, but when you try and dig for instructions on how to get it to work, the tubes becomes very very empty.

If you’re connecting your Network Space via USB, I imagine the device works out of the box. i.e. you just connect it to the Mac and Time Machine will find the drive and use it. In my case, my Network Space is connected to a wireless router, and I wanted to use it as if it was a Time Capsule.

Ordinarily, when you try and set up a Time Capsule, Time Machine will try and search for the Time Capsule over Bonjour, but because the Network Space doesnt identify itself as a Time Capsule it doesnt show up in the list. As it turns out, you can still do this, but you first need to tell Mac to chill out and show Time Machine capable devices which AREN’T the Time Capsule. In Terminal:

defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

Now, when you “Show Supported Devices” in Time Machine, the OpenShare share is discovered and you’re good to go.

It’s no surprise I love git. To date, the worst part about git however, was the lacklustre downright shithouse  state of the pre-packaged GUI tools – git gui and gitk.

Well here’s a command-line replacement i’ve devised for gitk which does a reasonable job at visualising a project tree.

git log --oneline --decorate=full --graph --remotes


Hopefully Don will forgive me for the creative licence I’ve taken in bastardising on the title of his book, but it seemed quite fitting given my recent experience with my Ryobi impact drill.

Basically what we’re talking about here is a standard, off-the-shelf drill with two operating modes: Drill mode and Impact/Hammer mode

Without getting into the detail of why you need two drill modes, the point remains that the drill itself contains a switch to flick between both modes.

(click the image to see a bigger version)

So the question is – which way do you need to flick the switch in order to engage hammer mode? Do you flick it right so that you can see the Hammer glyph, or do you flick it to the left so that the Hammer is covered up?

I asked a number of people this question, and interestingly NOBODY got the answer right. If you answered “flick it to the left so that the Hammer is covered up” then you got it WRONG. The switch actually needs to be flicked to the right. I cant explain why it was done like this and it seems completely counter-intuitive to me. There are much better ways of representing this modal change – the most obvious being if the glyphs themselves were shown on the side of the switch rather than at the bottom, and they swapped positions. This means the switch is then used to “engage” a particular mode, and the ambiguity is now removed by having to physically move the switch closer to the appropriate glyph.

So in the course of typing this blog-post, I thought about giving Ryobi a chance to respond and sent them a brief description of the problem and my proposed solution. Sadly I haven’t heard back from them. Shows how much they care about customer feedback in general. Ryobi fail.