1

I have a RHEL 6.9 host that loses its color when starting a screen session. Vim colors and directory colors exist before starting the screen session. Here are a few settings to help troubleshoot:

  • $TERM returns screen
  • I am using force_color_prompt=yes in my bashrc
  • echo "$(tput setaf 1)red$(tput sgr0)" successfully prints out red (in red)

Any advice on how to fix is appreciated, thanks!

Improve this question
2
  • Did you try screen-16color? Commented May 14, 2018 at 15:06
  • How do I use that? Do I run it as a screen command or put it in .screenrc? Commented May 14, 2018 at 15:13

3 Answers 3

Reset to default
4

$TERM returns screen

You've told the programs that you are running under Screen to look at the screen entry from the terminfo database when they want to do terminal-related stuff like colourize output. That entry tells them (via the common ecma+color entry) that the terminal has 3-bit standard colour support from 1976.

In fact, your version of Screen can very likely support a lot more than that.

You are probably looking for the screen-256color entry, which tells them that the terminal supports 8-bit indexed colour, or even the screen-256color-bce entry which specifies 8-bit indexed colour capability and background colour erase capability.

You tell them this by simple dint of setting the TERM environment variable to the value screen-256color, or screen-256color-bce.

You can start screen with the -T option to specify what TERM variable it should set for the programs it runs, i.e.,

screen -T screen-256color-bce

This is preferable to setting that somewhere "globally", as it doesn't affect programs run any other way than from within a screen session.

Further reading

Improve this answer
6
  • screen honors the 256-color escapes in either case (checked an hour ago). Commented May 14, 2018 at 20:49
  • It would, as its actual processing of SGR sequences is unaffected by the environment variable in some other process. The version of Screen that wouldn't support more than that would be one dating from before the introduction (into Screen) of 8-bit indexed colour support. I haven't checked when that was, because (as I said) it isn't the very likely case. (-: Commented May 14, 2018 at 20:55
  • In either case, the explanation of why there's no color appears to be missing. Commented May 14, 2018 at 21:00
  • I tried screen defbce/bce on however the exec defbce or bce does not exist on the host. Also setting the TERM variable to one of the ones you suggested in and out of the screen session did not fix the issue. Commented May 15, 2018 at 13:21
  • I think there is some kind of limitation on this host. When I login to an ubuntu host start a screen session there and then have each terminal login to the problem host things work fine, I suppose because I am using the settings of the original host. Commented May 15, 2018 at 13:30
-1
  1. Place this in your ~/.screenrc, create and add if not exists 
    shell -$SHELL
  2. Place this in your ~/.bashrc or ~/.zshrc, whichever shell you have configured. 
    export TERM=screen-256color
  3. Apply the changes 
    source ~/.zshrc screen -S screen_name
Improve this answer
1
  • not a good solution to hard-code the terminal name. In fact, a bad solution: this will break terminal emulators, and downgrade terminal emulators that can do more than screen-256color. Just start screen with -T screen-256color to make screen set the TERM variable only for itself and descendants. Commented Mar 18 at 11:37
-1

Try these commands in screen session:

alias egrep='egrep --color=auto' alias fgrep='fgrep --color=auto' alias grep='grep --color=auto' alias l.='ls -d .* --color=auto' alias ll='ls -l --color=auto' alias ls='ls --color=auto' alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
Improve this answer
1
  • this just tries to force a small selection of programs to ignore things that may or may not be impossible, and will also override a lot of defaults that the user might not want changed. I'd say this is not a good solution, and only for a tiny percentage of the actual problem! Commented Mar 18 at 11:38

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.