[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: patch: use color mode if CLICOLOR is set
From: |
Michael Wardle |
Subject: |
Re: patch: use color mode if CLICOLOR is set |
Date: |
Thu, 20 Mar 2003 09:37:09 +1100 |
[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