Bug 145485

Summary: Screen color ls is setup from DIR_COLORS and not DIR_COLORS.xterm
Product: [Fedora] Fedora Reporter: Jonathan Underwood <jonathan.underwood>
Component: coreutilsAssignee: Tim Waugh <twaugh>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-01-19 10:10:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Jonathan Underwood 2005-01-18 21:42:00 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
Currently, dircolors set up LS_COLOR for Gnu screen from
/etc/DIR_COLORS which is fine, but it's inconsistent with xterm,
gnome-terminal and konsole which use DIR_COLORS.xterm (since
$TERM=xterm for these). DIR_COLORS and DIR_COLORS.xterm differ in that
DIR_COLORS uses bold for coloured entries, which looks fairly horrible
(IMO of course). Anyway, there's no reason for screen to not have the
same settings as xterm and friends, so fixes would be to symlink
DIR_COLORS.xterm to DIR_COLORS.screen and add the lines 
TERM screen
TERM screen.linux
to DIR_COLORS.xterm

Or in fact, why bother with a separate .xterm file ? Anyway, would be
nice to have things consistent.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Fire up an xterm and run ls
2. screen
3. repeat (1), colours are now bold.

Actual Results:  LS_COLORS different for $TERM=xterm and $TERM=screen

Expected Results:  LS_COLORS could/should be the same for $TERM=xterm
and $TERM=screen

Additional info:

Comment 1 Tim Waugh 2005-01-19 10:10:33 UTC
Why should TERM=screen be the same as TERM=xterm rather than TERM=console? 
Since screen can be attached to other terminals, I think this is something that
will always need a certain amount of customization, and no one solution will
suit every use.