I am trying to get the solarized color theme to work in my terminal. I read the instructions here but I get the following dircolors error:

dircolors: `/home/avazquez/.dircolors_zsh':90: unrecognized keyword RESET
dircolors: `/home/avazquez/.dircolors_zsh':94: unrecognized keyword MULTIHARDLINK
dircolors: `/home/avazquez/.dircolors_zsh':103: unrecognized keyword CAPABILITY

when running:

if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"

from my .zshrc in zsh (latest version) (which I remotely access ssh -X from gnome-terminal in Ubuntu).

The path to the .dircolors file in question is here and the troubling lines seem to be some of the special files definitions:

## Special files

NORMAL 00;38;5;244 # no color code at all
#FILE 00 # regular file: use no color at all
RESET 0 # reset to "normal" color
DIR 00;38;5;33 # directory 01;34
LINK 01;38;5;37 # symbolic link. (If you set this to 'target' instead of a
 # numerical value, the color is as for the file pointed to.)
MULTIHARDLINK 00 # regular file with more than one link
FIFO 48;5;230;38;5;136;01 # pipe
SOCK 48;5;230;38;5;136;01 # socket
DOOR 48;5;230;38;5;136;01 # door
BLK 48;5;230;38;5;244;01 # block device driver
CHR 48;5;230;38;5;244;01 # character device driver
ORPHAN 48;5;235;38;5;160 # symlink to nonexistent file, or non-stat'able file
SETUID 48;5;160;38;5;230 # file that is setuid (u+s)
SETGID 48;5;136;38;5;230 # file that is setgid (g+s)
CAPABILITY 30;41 # file with capability
STICKY_OTHER_WRITABLE 48;5;64;38;5;230 # dir that is sticky and other-writable (+t,o+w)
OTHER_WRITABLE 48;5;235;38;5;33 # dir that is other-writable (o+w) and not sticky
STICKY 48;5;33;38;5;230 # dir with the sticky bit set (+t) and not other-writable
# This is for files with execute permission:
EXEC 01;38;5;64
  • I made an ambitious attempt to make sense of dircolors. While it is not an answer to your question, it might interest you to check it out. Apr 1 '13 at 3:29

That has little to do with zsh. zsh supports coloured completion like GNU ls does (with things like blue for directories, green for executables...), and it supports the same configuration directives as GNU ls does.

GNU ls colour configuration is done via the LS_COLORS environment variable. When that variable contains ln=01;36, that means that symbolik links are to be rendered in bold cyan (36 being the ANSI colour code for foreground cyan and 01 being bold).

In zsh, you can do the same with:

zstyle ':completion:*' list-colors 'ln=01;36'

And actually you generally configure zsh coloured completion with:

zstyle ':completion:*' list-colors ${(s.:.)LS_COLORS}

So zsh colours completions the same way GNU ls does.

To make it easier writing the content of the LS_COLORS variable, GNU ls comes with the dircolors command. That command takes as input a configuration file with a more verbose content (as configuration files don't have space constraints like environment variables have) and generates the corresponding content of the LS_COLORS variable suitable for your terminal.

Above we have:

LINK 01;38;5;37

01 is still bold, but 38;5;37 is the specification for extended colour modes for terminals like xterm that support 88 or 256 colours.

That's foreground colour 37 which is some shade of cyan (rgb:00/af/af) slightly darker than the default colour for the ANSI colour 6 (cyan3 at least with my xterm, which here is rgb:00/cd/cd).

~$ tput setaf 37 | sed l

When passed through dircolors, that becomes ln=38;5;37.

There's also MULTIHARDLINK 00 which says that files with more than one hard link are to be rendered with the default colour. That would translate to mh=00 in $LS_COLORS.

However, that's been introduced in a relatively recent version of ls/dircolors. It used to be HARDLINK/hl, but was renamed to MULTIHARDLINK/mh in coreutils 7.5 in 2009 as that was a more correct choice of wording.

It seems that you have an older version of dircolors. Note that zsh supports neither hl nor mh (though it wouldn't complain, just ignore it), and because it's just set to the default colours, you might as well remove that line.

RESET/rs was added in coreutils 6.11, and is not supported by zsh either.

CAPABILITY/ca was added in coreutils 7.0 and is not supported by zsh either.

There are probably more of those not supported by zsh (See info zsh 'The zsh/complist Module' for details), but again, zsh just ignores what it doesn't support.

The errors you get there are from dircolors. It just means that whoever wrote that dircolors file had a newer version of coreutils (the GNU suite of utilities including ls and dircolors) than you have. Just remove the lines that are not supported in that file.

  • Thanks @Stephane. This is so helpful. What is the difference between the two zstyle completion lines? I think I understand the first one as saying "use this color for sym links", but what about the second one? Also, what does completion have to do with the colors that ls uses to display files? I understood most of your thread, but there are few things that are not still clear to me. Mar 31 '13 at 21:44
  • OK I think I got it, you mean that zsh also supports colors for completing files and directories, and that it also supports a syntax similar to that of dircolors (as in your first zstyle example). The second zstyle example tells zsh to use whatever definitions present in LS_COLORS correct? Mar 31 '13 at 21:46

In order for zsh to work you MUST ADD :

alias ls='ls --color=auto'

I also have some stuff on github with a .zshrc example

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.