Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 77831 - colors not handled right in screen because of missing file
Summary: colors not handled right in screen because of missing file
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: fileutils
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-11-14 07:19 UTC by Nathan G. Grennan
Modified: 2007-04-18 16:48 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-01-03 03:37:09 UTC


Attachments (Terms of Use)

Description Nathan G. Grennan 2002-11-14 07:19:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20021017

Description of problem:
/etc/profile.d/colorls.sh checks $TERM and looks for /etc/DIR_COLOR.$TERM  This
makes colors work right in terminal programs that have their $TERM set to xterm.
I today switched to a setup where my terminals are automatically run with screen
on top of zsh so that I can use "ctrl-a d" to push something into the background
and not have to worry about it going away if X crashes. This is especially nice
with downloads/uploads. So my $TERM is constantly set to screen instead of
xterm. This results in sub-optimal ls colors. As a workaround I have used cd
/etc ; ln -s DIR_COLORS.xterm DIR_COLORS.screen

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


How reproducible:
Always

Steps to Reproduce:
1. screen
2. ls

	

Actual Results:  Colors work, but aren't correctly set, so things like archive
files aren't red.

Expected Results:  Proper colors for all file types.

Additional info:

Comment 1 Tim Waugh 2002-11-14 09:17:24 UTC
Perhaps a better solution is to add a line to /etc/DIR_COLORS, rather than make
a new file.


Note You need to log in before you can comment on or make changes to this bug.