bash process started from C# returns unexpected characters

Question

I started bash (cygwin) from C# and I for that purpose created a new process from C:\\cygwin64\\bin\\bash.exe with the arguments --login -i. I've also redirected its output.

Bash runs, but the output contains unexpected characters like [0m[37;1m or [0m> or [K> or even > (there is an ESC character before all of these but stackoverflow does not seem to let it be displayed). This is unexpected cause I don't seem to see any of these characters from the mintty program.

Why is this happening? Where are these characters coming from? How can I prevent them from appearing?

Answer 1

The unexpected characters are escape sequences used to format text output (concerning the terminal emulator). (See Wikipedia: terminal emulator for more about this.)

In detail, the output of prompt may be configured using certain bash variables, namely PS1, PS2, PS3, PS4. In How to change bash prompt color based on exit code of last command?, the effect of modifying them (just for fun) is shown.

In your case, the call of bash should source a special script which re-defines them simply without any escape sequence. Thus, you could get rid of the undesired formatting. This may help: SO: Running a custom profile file on remote host but this seems also promising: Is it possible to start a bash shell with a profile at a custom location, in a one liner command?.

Writing this, I remembered that certain commands (e.g. ls) support colored output also. As I was not sure I tried this:

$ mkdir test ; cd test ; touch test1 ; ln -s test1 test2 ; mkdir test3 ; touch test4 ; chmod a+x test4

$ ls --color
test1  test2  test3  test4

$

I do not know how to format it with colors here but, on my xterm, it's looking like Mardi Gras. Thus, I use hexdump to show the effect:

$ ls --color | hexdump -c
0000000   t   e   s   t   1  \n 033   [   0   m 033   [   0   1   ;   3
0000010   6   m   t   e   s   t   2 033   [   0   m  \n 033   [   0   1
0000020   ;   3   4   m   t   e   s   t   3 033   [   0   m  \n 033   [
0000030   0   1   ;   3   2   m   t   e   s   t   4 033   [   0   m  \n
0000040

As you can see: ls does use terminal escape sequences also. Then I remembered the variable TERM. This link The TERM variable mentions the terminfo or termcap also which are probably part of the game.

Thus, in addition to the re-definition of PS1 ... PS4, it could be useful to redefine TERM also:

$ TERM=

$ ls --color | hexdump -c
0000000   t   e   s   t   1  \n   t   e   s   t   2  \n   t   e   s   t
0000010   3  \n   t   e   s   t   4  \n                                
0000018

$

Btw. I recognized that the bash prompt is still colored. Thinking twice this becomes obvious: The escape sequences in PS1 ... PS4 are "hard-coded" i.e. does not consider the setting of TERM.

Update:

To test this I wrote a sample script mybashrc:

PS1="> "
PS2=">>"
PS3=
PS4="++ "
TERM=

and tested it with bash in cygwin on Windows 10 (64 bit):

$ bash --init-file mybashrc -i
> echo "$PS1 $PS2 $PS3 $PS4"
> >>  ++ 
> exit
exit

$

Btw. I noticed that the [Backspace] key works somehow strange in my sample session: It still has the intended effect but the output is wrong. Output is instead of deleting the last character although the internal buffer seems to handle this correctly:

$ bash --init-file mybashrc -i
> echo "Ha ello"
Hello
> echo "Ha ello" | hexdump -c
0000000   H   e   l   l   o  \n
0000006
> exit
exit

$

(In both cases, I typed [Backspace] once after echo "Ha.) The reason is possibly the missing terminal emulation.

Thus, I believe if the console (in your application) handles backspaces in the output channel of the bash appropriately then it should be less confusing.