Bug 70383 - colorls.sh does not check whether terminal actually allows color
colorls.sh does not check whether terminal actually allows color
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2002-07-31 18:58 EDT by Brent Thompson
Modified: 2014-03-16 22:29 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-29 16:11:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Brent Thompson 2002-07-31 18:58:14 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; HP-UX B.11.11 9000/785)

Description of problem:
/etc/profile.d/colorls.sh checks, as it should, whether /etc/DIR_COLORS 
contains an entry blocking colorization for all users on all terminal types, but 
if not then proceeds to colorize without checking whether the specific terminal 
in use is listed in DIR_COLORS as actually being colorizable, despite DIR_COLORS
being exactly such a list.

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

How reproducible:

Steps to Reproduce:
1. login using any terminal which does not allow/have color
2. ls /

Actual Results:  colorization garbage shows on display

Expected Results:  only output of ls (or whatever other command was issued)
show on display, not colorization escape codes.

Additional info:

colorls.sh should include an extra line like this:

   egrep -qi "^TERM[    ]*$TERM" $COLORS &>/dev/null; then

as shown here in my modified colorls.sh:

######### begin new colorls.sh #########
# color-ls initialization
eval `dircolors --sh /etc/DIR_COLORS`
[ -f "$HOME/.dircolors" ] && eval `dircolors --sh $HOME/.dircolors` &&
[ -f "$HOME/.dir_colors" ] && eval `dircolors --sh $HOME/.dir_colors` &&

if echo $SHELL |grep bash 2>&1 >/dev/null; then # aliases are bash only
  if ! egrep -qi "^COLOR.*none" $COLORS &>/dev/null && \
   egrep -qi "^TERM[    ]*$TERM" $COLORS &>/dev/null; then
        alias ll='ls -l --color=tty'
        alias l.='ls -d .[a-zA-Z]* --color=tty'
        alias ls='ls --color=tty'
        alias ll='ls -l'
        alias l.='ls -d .[a-zA-Z]*'
######### end new colorls.sh #########

/etc/init.d/functions also don't properly check for ability to colorize
the terminal currently in use, resulting for example in this message on a
b&w terminal, but this is due to some different mechanism than colorls.sh:

> # /etc/init.d/xfs start
> Starting xfs: 60G[  0;32mOK0;39m  ]
Comment 1 Todd Allen 2002-08-03 12:24:38 EDT
See bug 70668 also.
Comment 2 Karsten Hopp 2002-08-06 10:59:58 EDT
The colorls part has been fixed, changing component to initscripts for 
the /etc/init.d/functions part
Comment 3 Bill Nottingham 2002-08-12 15:06:03 EDT
What sort of terminal are you using?
Comment 4 Bill Nottingham 2005-09-29 16:11:34 EDT
Closing bugs on older, no longer supported, releases. Apologies for any lack of

If this persists on a current release, such as Fedora Core 4, please open a new bug.

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