5

I have a line in my .bashrc that sets a color-scheme:

eval $(dircolors colorfile) 

This works as expected, setting LS_COLORS with the right string generated from 'colorfile'.

When I use screen, the bashrc file is read again, but I lose my colors. Testing, I ran dircolors colorfile in the commandline in screen, and get

LS_COLORS='';
export LS_COLORS

I can work-around this pretty easily, but I'm curious what's causing dircolors to act differently in screen vs not. I thought it just blindly parsed the file and outputed the string. But it must be checking some env variable or something?

Any clues? Here's some extra info: My .screenrc is blank, I'm using gnome-terminal. Dircolors version is 8.25.

I used the which command to make sure I wasn't using two different binaries (I wasn't). I checked the value of $? after running dircolors, it was 0 in both cases.

2 Answers 2

4

The value of $TERM is different inside screen. Accordingly your colorfile file should probably begin with

TERM screen*
TERM xterm*
0
0

For what it's worth, older versions of dircolors do not support name globbing for the TERM arguments—e.g., xterm* is not supported, in which case you must explicitly list every terminal type you want to support (one per line):

TERM xterm
TERM xterm-16color
TERM xterm-256color
TERM xterm-color
etc.

To quickly check whether your version of dircolors supports name globbing, do

dircolors --print-database | grep TERM

and check for one or more globbed names in the TERM listing, e.g.,

TERM *color*
TERM xterm*

If you don't see globbed names in the TERM listing—e.g., *color*, xterm*, etc., then it's likely that version of dircolors doesn't support name globbing.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .