bashescapingzshansi-escape

Mixing \e and other escape characters


I recently came to know how ANSI-C quoted strings can be used to give colourful prompts to commands that do not recognize escape characters. For e.g.

% read -q $'val? \e[31mFoobar\e[0m:'                 
 Foobar:          # Prints 'Foobar' in red

So, I was wondering what the ANSI-C string looks like when it is passed to the read command. I just created a sample file to print the individual characters

# test.sh
foo=$1
for (( i=0; i<${#foo}; i++ )); do
  echo "${foo:$i:1}"
done

and this is the output

% ./test.sh $'\e[31mFoobar\e[0m:'   





F
o
o
b
a
r




:             # Prints each 'Foobar' character in red

So, I was a little confused after seeing the output and ran this

% echo $'\e\b[\b3\b1\bm\bFoobar'
Foobar         # Prints 'Foobar' in red
% echo $'\e\n[\n3\n1\nm\nFoobar'





Foobar         # Prints 'Foobar' in red
% echo $'\e\t[\t3\t1\tm\tFoobar'
    [   3   1   m   Foobar          #Doesn't print 'Foobar' in red

As seen above, clearly in some cases the escape characters are not stopping the color. What is happening here?

I'm on zsh 5.9 (arm64-apple-darwin24.0) on MacOS Sequoia 15.2. Although, I worked using zsh the same even happens in bash

Edit: Adding the output of printf "TERM=${TERM}\n"

% printf "TERM=${TERM}\n"
TERM=xterm-256color

Solution

  • I suppose it is (somehow) defined behaviour, because it works on Linux terminals, MAC and Windows10 more or less the same.

    All control characters (0x00-0x1F) seems to be allowed, but some will have an effect, like \n adds a newline before changing the color.

    Only in the old windows cmd.exe/conhost all control characters are shown, but the color escape sequence still works.