(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
Libdave pointed out:
Got something to add? Send me email.
More Articles by Tony Lawrence © 2015-12-03 Tony Lawrence
A C program is like a fast dance on a newly waxed dance floor by people carrying razors. (Waldi Ravens)
Sun Mar 28 20:00:28 2010: 8290 anonymous
Well, I for one much prefer using colorized output. Keeps my mood up, especially during troubleshooting.
Sat Mar 3 14:59:57 2012: 10699 anonymous
dircolors is fine, but the hard part is when I take my dircolors to another machine, they look completely different! The 036 "cyan" on one machine looks totally different from the 036 "cyan" of another machine, even using the same monitor. Ideas on how to overcome that would be helpful.
------------------------
Printer Friendly Version
Linux colors ls ––color command Copyright © May 2011 Tony Lawrence
Have you tried Searching this site?
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.
Contact us
Printer Friendly Version