Linux shell colors; shell ls colorization
(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:
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
[ -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
Libdave pointed out:
Quick and dirty but repetitious:
If you preface any alias with a backslash it un-aliases is in effect.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2015-12-03 Tony Lawrence