Tuesday, March 13, 2012

Searching the command line history in bash

With as much as I've been using bash lately, it's weird that it's taken me this long to stumble across a need for searching the command-line history. But it happened today, and it was easy to do, as soon as someone told me how to do it. I had a command I'd run a few times over a week ago, and in the intervening time I'd run thousands of other commands. I could figure out all the parameters to this command if I wanted to, but the Second Rule of Programming states that "Programmers are Lazy," so I was going to find a better way. And it's pretty simple:

Hit CTRL+R at the command prompt, then start typing what you remember of the command. When the one you want shows up, hit Enter to run it or Escape to have a chance to edit it. Simple as that.

I really enjoy using all the *nix operating systems and the power you get in the shell environment. However, the biggest drawback is that using the shell environment is not intuitive like a GUI can be (if designed correctly, of course). Chances are, you can do whatever it is you need to do, because someone else needed to do it first and went and made that possible. But you need to go and learn it yourself, because there's not a whole lot you can divine from a screen blank except for a cryptic '$> ' and a blinking cursor with zero prior knowledge. That's fine by me, as long as such knowledge is as readily available as possible when I need it. I'd much prefer that to a ridiculously complicated ribbon interface with a buttons for so many things that finding the button I need takes longer than asking Google to find it for me. I mean, if I'm Googling anyway, it's easier for me to remember a command name or a keystroke combo than a series of menus or ribbon tabs to drill through. I'd further argue that executing a known command in a shell or a keystroke combo is an O(1) operation, whereas executing a command from a menu or a ribbon interface is O(log(n)), with n being the number of available menu options or ribbon buttons. With few possible commands (like, say, MS Paint), it's not a big deal. With a ton (like, say, MS Word), it can be a nightmare if you need something fairly obscure.

Friday, March 2, 2012

Automated Testing with MonoTouch on an iPad: Revisited

Back in December, I wrote this post about my efforts to set up automated testing on an iPad in MonoTouch. I updated that a couple of weeks ago, noting that there was now a --launchdev option which might make all of that unnecessary, so long as your test app didn't need any data. Unfortunately, mine did. However, as of MonoTouch 5.2.5 (or potentially earlier, but 5.2.5 is when I noticed it), I saw a new command-line option appear for the mtouch program: --argument. It's description? "Launch the app with this command line argument. This must be specified multiple times for multiple arguments." Could this be a way I could ditch the separate launcher app and related AppleScript incantations completely? The short answer is yes. The long answer follows, after the break.