[CCing bug-coreutils. hope you don't mind, Bob.] On Wed, 19 Mar 2003 11:40:31 -0700 [EMAIL PROTECTED] (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 _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
