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/ (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

(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Linux colors ls ––color command, shell ls colorization


More Articles by

Find me on Google+

© Tony Lawrence

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.

Kerio Samepage

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

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

privacy policy