Lots of similar questions, but I can't quite seem to find anything that is an exact match.
I am using the default Terminal (in Yosemite) to SSH into a VM. The VM's terminal is set up to use
TERM=xterm-256color properly, and 256 colors works locally on the VM with the same terminal settings, but the colors will not make it over the SSH connection. Does anyone have any idea what it takes to get Terminal to just treat the output as normal 256 color sequences?
All I want here is to figure out why 256-color escape codes are ignored in Terminal.app when they come over an SSH connection. And, of course, to get it to stop ignoring the escape sequences.
Possibly excessive info:
The VM is running windows 7, shell is bash on cygwin, ssh server is bitvise.
I'm looking at 3 cases -- locally on native OSX bash in Terminal.app, locally in the VM bash in MinTTY, and in the VM via SSH in Terminal.app.
infocmp xterm-256color produces identical results in all three cases, and
tput colors reports 256 in all cases.
(tput setaf 200 && echo pink) > pink produces the identical results in all three cases:
$ hexdump -C pink 00000000 1b 5b 33 38 3b 35 3b 32 30 30 6d 70 69 6e 6b 0a |.[38;5;200mpink.| 00000010
cat pink either in Terminal.app (locally, not SSHed out anywhere) or in MinTTY on the VM prints out the expected pink text.
cat pink in Terminal.app while SSHed out to the VM produces default light gray text.
The SSH connection is configured with
EscapeChar none, so data should come though binary clean (changing this setting made no difference).
The preferences in Terminal.app are set to report as
xterm-256color, though I don't think that should make any difference.
Any ideas on what is eating the escape sequence to fail? I'm not using anything other than plain ol bash for shells, no
tmux (unless Terminal.app uses it automatically/internally).