Bash Color Prompt Problems With Reverse-I-Search in Terminal.app

I recently colorized my bash prompt. It's a nice touch, and with a bit of taste, it's good design. Makes visual parsing very quick.

Gone are the days of souped up command-line prompts that look like they're about to lift off into orbit. For a trip down memory lane, check this out. I stumbled across it while Google'ing this problem. Good fun. :-)

No, my prompt is very Spartan:

shaque@marius is user@host (so you know what computer you're on), ~/git_tree/users is the present working directory, and ihaque/vim-tweaks is my git branch.

All of this is awesome. The colors are awesome too (Solarized), they're specially picked colors for a low contrast delta between the foreground and the background, while maintaining excellent readability over prolonged periods. Prevents tired eyes. Go to Ethan Schoonover's website I've linked to, and integrate it into your environment. Srsly.

The problem: once you have colors, and if you use bash's builtin reverse-i-search for previously typed commands, things get fudged. Terminal.app doesn't write the characters properly on-screen so if you reverse-i-search for a previous command, then scroll backward or forward to edit it, it doesn't display correctly.

I spent a lot of hours tinkering with my bash prompt to make this work. It was awful, because bash syntax is very un-pretty. Look at the code for my prompt:

export PS1="\[\e[0;36m\]\u@\h\[\e[m\] \[\e[0;34m\]\w\[\e[m\] \[\e[0;33m\]\$(parse_git_branch)\[\e[m\]\$ "

Uffffff.

The fix: use iTerm.app. Terminal.app doesn't render color properly, apparently. I don't have an explanation for this yet, but iTerm.app will gladly handle your colorized prompt and finicky interactive shell features with barely a sweat.

It's also an actively maintained open source project with a shorter release cycle (read: one that is not pinned to that of OS X's).

Bless the folks at Apple, I think they did a pretty good job with Terminal.app. It's miles and miles better than any stock CLI shell Microsoft ever shipped with their operating systems, and the anti-aliasing and opacity control is better than anything I've seen on Linux (though Terminal.app is not nearly as feature rich, or as responsive as anything on Linux).

Credit goes to Terminal.app, I stuck with it for a long time, but I'm switching to iTerm.app now. It's just better.

Installing ack with Macports

Macports is awesome. Also, ack is awesome. ack is made to replace 99% of the use-cases of grep, and it's customizable with an runtime configuration too (~/.ackrc). To install one awesome thing with another awesome thing:

user@host $ sudo port install p5-app-ack

Not a very intuitive name for ack, but this is the naming convention for CPAN modules on Macports.

I was having a spot of trouble finding the package name for ack (port search ack returns way too many results to be meaningful, thank goodness for Google), and came across this blog post that complains about Macports deciding as soon as you want to install ack that the stock perl in OS X isn't good enough, and summarily takes over your computer by downloading and installing a more recent perl on your box.

This made me think. That's not nice.

But then I thought some more, and I decided, no, that is nice. In fact, it's awesome.

OS X ships once every couple of years (which is considered a pretty sprightly clip in the world of operating systems) and stock installations of OS X ship with obsolete versions of perl for the majority of the product's life-cycle.

I'm glad Macports takes over and updates my perl for me. It saves me the trouble of doing it, and worrying about dependencies. I don't want to worry about dependencies. That's why I installed Macports. If I wanted to "roll my own," I'd download tarballs and roll up my sleeves (right after I cut myself with shards of glass).

The first thing I'm going to do when I get a new Mac is install Macports. It's really so convenient.

I like to think of these package management systems as open-source App Stores, which they basically are, except you never have to pay. And to consider open source developers had mature implementations of these so many years before App Stores ever entered the mainstream.

Whatever those guys are doin', they're doin' it right.

Basic Usage of launchctl (with MySQL)

Macports is awesome. I've installed Vim 7.3, Emacs 23.3, mutt, and mysql5-server, and it has been as smooth as apt on Debian (a very high compliment!). Dependencies, download sources, building, linking, it's all taken care of.

You need to have developments tools installed on OS X, though, because it uses gcc, and from what I can tell, it compiles everything.

Macports Just Works.™ I recommend. I am a fan.

I needed to install MySQL on my local machine, but I didn't want mysql5 running all the time; I want to start it up whenever I need it, and shut it down when I'm done. When Macports finished the install, it told me to run a command to make it run on start-up, which I ran.

I wanted to undo it, because I wanted to know how to.

launchctl (short for "launch control"), controls what launches on startup on OS X. Very basic usage is:

user@host $ launchctl load -w com.your.daemon.plist

To make sure it starts up on login. Or:

user@host $ launchctl unload -w com.your.daemon.plist

To make it not start up on login.

It does magicks in the background you don't need (immediately) to know about. Just use it to control what goes on startup and what doesn't.

If you're worried things are starting up that you don't know about, go to /Library/LaunchDaemons/, and do an ls -l (-l is important, because they're all symlinks).

It's basically a directory of symlinks to plist files that are read to get details on daemons to start up for you. If you don't like something (I noticed some Microsoft registration thingy there), just launchctl unload it.