Bash complete, and other colourful fun

One of the attractions of Bluehost, my host, is the ability to ssh into your box, which makes administering your site that much easier if you know how to use the *nix command line. (See related post.)

I’ll just write about two things that I’ve worked out recently.

Lesson #1: Read the README file.

Well duh, you say. The story is, I’ve had the bash_completion script for some time (a really useful extension that makes typing on the command line that much easier), but I’ve never quite worked out why it didn’t work. Now I know why. It’s because I naively assumed that the script was the meat of it, and simply called it from .bashrc, expecting it to just work. It would, ordinarily, but I don’t have it installed in /etc which is where it expects to be (it’s in my home directory). If you have somewhere else like me, you will need to set the $BASH_COMPLETION variable and modify the script to reflect where you’ve actually put it.

Lesson #2: If you didn’t set up the system yourself, things might not be as you expect them to be.

SUITS has a bunch of useful scripts that you can use to improve your command line experience on the undergraduate IT servers, and I copied them over to my account on because I like them so much. One of these scripts sets nice colours for the command line. It was all working fine until I realised TortoiseSVN could no longer access the Subversion repositories via svn+ssh, failing with the error “connection closed unexpectedly”. I figured something I added recently was injecting garbage into the stream. It turns out it was the colour-adding script! But why? It was protected like this:

if [ -n "$PS1" ]; then
        . ~/.bash/colors

That means that it should only have been run if it was running in an “interactive” terminal, and the colour-adding script should not have been called if I was using svn+ssh. After some more poking around, I found this in /etc/bashrc (which was being called from .bashrc):

# For some unknown reason bash refuses to inherit
# PS1 in some circumstances that I can't figure out.
# Putting PS1 here ensures that it gets loaded every time.

Uhh, ok, nice work, Bluehost. I guess not many of their customers actually use ssh. At least there was a comment.

But even if it was called, why the colour-adding script was failing in the first place? It turns out that tput colors fails if $TERM is not set, which happens to be so when using svn+ssh. (Actually, this would not normally prevent me from accessing my Subversion repositories. The command line svn seems to ignore errors; however, TortoiseSVN dies the moment it sees anything untoward.) My ultimate solution was to simply pipe error to /dev/null.

Tags: , , , ,