Linux shell colors; shell ls colorization
© Tony Lawrence, aplawrence.com
(This is an update and expansion of an earlier post on the same subject)
Personally, I don't like colors in my shell. I think it would be fine as an option, but to have it as the default offends me and many other old Unix hands.
You can shut off command line colorizing by editing /etc/DIR_COLORS and changing "COLOR tty" to "COLOR none" or (less drastically) by removing the "TERM ansi" line from the same file (which removes colorization for ansi but doesn't affect console use).
The shell DEFINITELY shouldn't be attempting colors when the TERM is not "linux". This just makes things worse. A common result is dark blue lettering on a black background - almost impossible to read.
If you hate vi (vim) colorization as I do, see Controlling Linux colors in vi (vim).
A more typical response advises you to edit .dir_colors. That's fine if you are regularly vising this machine, but for tech support folk, you are often coming in to use someone else's account temporarily, and you wouldn't do that, so resetting "LS_COLORS" would seem to make more sense. Unfortunately, that does nothing because the usual reason is that "ls" has been aliased. The best fix is to change the alias to 'color=never"' or to remember to use /bin/ls (which bypasses shell aliases).
(Another reason to avoid colorization is explained at ls -color considered harmful which explains why colorized "ls" may hang when a text version would not.)
If you LIKE colors and simply find the default choices awful, you can edit ~/.dircolors (if it doesn't exist you can create it with:
dircolors -p > ~/.dir_colors
Your .bashrc might then have something like:
eval `dircolors ~/.dir_colors` alias ls="ls --color=auto"
My "man" and"info" pages for "ls" only give 3 options for --color:
--color[=WHEN] control whether color is used to distinguish file types. WHEN may be 'never', 'always', or 'auto'
However, "color=tty" also works. That 'tty' colorizes output to ttys, but not pipes (where you likely definitely do not want that junk!)
See man/info dircolors (though neither tells you much - your /etc/dir_colors or /etc/DIR_COLORS file may tell you more).
The actual setup of colorization is more involved. On this Linux system, that's handled by /etc/profile.d/colorls.sh (sourced from /etc/profile).
# color-ls initialization alias ll='ls -l' 2>/dev/null alias l.='ls -d .*' 2>/dev/null COLORS=/etc/DIR_COLORS [ -e "/etc/DIR_COLORS.$TERM" ] && COLORS="/etc/DIR_COLORS.$TERM" [ -e "$HOME/.dircolors" ] && COLORS="$HOME/.dircolors" [ -e "$HOME/.dir_colors" ] && COLORS="$HOME/.dir_colors" [ -e "$HOME/.dircolors.$TERM" ] && COLORS="$HOME/.dircolors.$TERM" [ -e "$HOME/.dir_colors.$TERM" ] && COLORS="$HOME/.dir_colors.$TERM" [ -e "$COLORS" ] || return eval `dircolors --sh "$COLORS" 2>/dev/null` [ -z "$LS_COLORS" ] && return if ! egrep -qi "^COLOR.*none" $COLORS >/dev/null 2>/dev/null ; then alias ll='ls -l --color=tty' 2>/dev/null alias l.='ls -d .* --color=tty' 2>/dev/null alias ls='ls --color=tty' 2>/dev/null fi
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version