Escape sequences for 256 colors are only interpreted if they are the only content of an ESC [ m sequence, i.e. the following Python code:
print '\x1b[0;38;5;196mfoo\x1b[0m'
outputs a white blinking foo as the 38;5;196 is not recognized as a color switching sequence. Instead the 38 is ignored and the 5 switches on blinking. I would have expected this sequence to reset all character attributes (via 0) and then switch the foreground color to color 196 (via 38;5;196) (which is a bright red in the default palette).
The specification of Xterm control sequences at http://invisible-island.net/xterm/ctlseqs/ctlseqs.html states that in a
CSI Pm m
sequence, the Pm part are multiple Ps and one Ps may be 38;5;Ps, so IMHO this should work.
The attached patch fixes this problem.
An open question remains what to do with incomplete sequences. With the patch
print '\x1b[0;38;5mfoo\x1b[0m'
still outputs a blinking foo.
This patch seems a bit buggy.
It should do i += 2 rather than i += 3.
That is because the for loop will do ++i too.
This off-by-one error causes iTerm to skip the next parameter after the 38;5;Ps or 48;5;Ps sequence.
For example, CSI 38;5;100;48;5;200 m would skip the 48, and then treat the following 5 as a slow-blinking-on attribute.
Indeed that's a bug in the patch. Attached is a new version of the patch.
It seems that this is a duplicate of bug #2830207.
Any chance of this patch getting into iTerm? (The bug is still there in 0.9.6.20090928)