Bash and the non-printing characters fiasco

Once upon a time, bash (or some other shell) introduced color in the shell prompt. The syntax was funky and all but illegible, so manpages and HOWTOs were written. The technical elite (i.e. high school kids and sysadmins with nothing better to do than configure their bash prompts) rejoiced.

Once upon a more recent time, I crafted this bash prompt:

PS1='$(r=$?; [ 0 == $r ] || echo "\[\e[33m\]$r\[\e[0m\] ")\u@\h:\w\n\[\e[32m\]\$\[\e[0m\] '

Actually, its history is more of an evolution than a crafting, but nonetheless
I like it.

Then, out of the blue, someone broke bash. The \[ and \] non-printing character delimiters stopped working (or stopped working properly). Their purpose is to tell bash that the stuff inside is non-printing so don’t count it when you’re counting the number of characters in the prompt. This is vital for proper wrapping and tab completion in the presence of color escape sequences. I don’t know who broke it or why, but removing \[ and \] seemed to fix the symptom.

Fast forward far too long, and someone fixed the problem. Once again you needed \[ and \].

Fast forward again, and it’s broken. Or maybe we’re just going around in circles on which version of bash is being used in various distributions and OS’s. In this case, Ubuntu is still (or again) broken and OS X is broken in a different way. They’re both running 3.2.x. The bug is probably the same and the manifestation is simply different.

The current manifestation of this bug is that neither with nor without the delimiters works. I’m forced to go back to a noncolored prompt, and I’m not happy about it. This bug has been around for at least a year. I’ve reported it several times to various distros. Why is it not yet fixed? If they fixed it today, we’d still be battling the bug for years to come because of the many distros and OS’s that have assumed buggy versions of bash.


Leave a Reply