Re: patch: use color mode if CLICOLOR is set

[Michael Wardle]

[CCing bug-coreutils. hope you don't mind, Bob.]

On Wed, 19 Mar 2003 11:40:31 -0700 address@hidden (Bob Proulx) wrote:
> Michael Wardle wrote:
> > I work in a mixed environment of mostly FreeBSD, GNU/Linux, and IRIX
> > systems.  FreeBSD has a color ls that will enter color mode if the
> > -G option is specified or if the CLICOLOR environment variable is
> > set.  GNU has a color ls that will enter color mode if the --color
> > option is specified.  IRIX does not have a color ls mode.
> > 
> > In this environment, a simple shell alias such as "ls"="ls
> > --color=auto" to automatically colorize ls output will not suffice,
> > as non-GNU versions of ls do not understand the--color option.  I
> > prefer the FreeBSD approach, which is to use color mode if the
> > CLICOLOR environment variable is set, and if the output is a
> > recognized terminal type, similar to "--color=tty" in GNU ls.
> 
> How about something like this in your user shell cusomization?
> 
>   if ls --version 2>/dev/null | grep -q -e fileutils -e coreutils;
>   then
>     eval $(dircolors -b)
>     alias ls='ls --color=auto'
>   elif sometestforbsd; then
>     alias ls='ls -G'
>   fi

Thanks for the example.  It's quite possible I will end up using
something like that (at least in the short term).

> And, of course, the whole topic of color is one of personal
> preference.  A large can of worms for those who tread there.

Part of the fun is that ls does not accept the same flags on different
platforms in the first place.  I decided to tackle this when I noticed
that Red Hat Linux and Debian GNU/Linux both attempted to have colorized
ls happen by default, but neither of their implementations was
satisfactory to me.

I had a suspicion that colorization might have been a sacred issue, but
I don't really understand why.  It is clear to me that various GNU/Linux
distributions wish colorization to happen by default, and I believe my
approach provides a simple setting that will avoid use of aliases, will
work on more platforms, will not colorize if the output is not a
terminal, and will still allow the user to override it using the usual
"--color=<arg>" flag.  This does not break any existing behavior, and
only even attempts colorzation if the user has set the CLICOLOR
environment variable.  Can you think of a situation where automatically
colorizing output if $CLICOLOR is set could have a negative side effect?

Another approach would be to automatically colorize the listing if
$LS_COLORS is set.  It seems to me that LS_COLORS is traditionally set
by running "dircolors", and that the existence of this environment
variable is already a clue that the user (or the vendor/sysadmin) would
like to try to colorize the listing if possible.  As previously stated,
it would be trivial to change my suggested patch to do things this way
as well/instead.

Thanks for your reply

-- 
Michael Wardle
Adacel Technologies