I’m fine customizing most settings in LS_COLORS. I don’t need help customizing the colors for different file suffixes. What I would like to do is configure special colors for certain directories, based on their suffix.

(For example, I’d like dir1/ to display in the standard directory color, but dir2.special-suffix/ to display in a different color, which I set for directories with names that end in .special-suffix.)

I’ve tried to do this using the standard *.«suffix» method (as used with files), but without luck. All directories are displayed in the color specified for di, and ignore any subsequent *.«suffix» rules.

Is this even possible?


Probably not, though this may have surprised the devs as well. Here's a comment from an excerpted GNU's ls.c:

#   /* Extensions only apply to regular files, apparently. */

Here is a link to the full ls.c source in which you will find the same, though it is not as pretty to read, maybe.

It is worth noting though you can get some alternation in color for directories based on their modes and/or depending on their link state. Of course, such things would amount to changing the contents of the report for sake of the reporter, but I'm no philosopher; so here's one way you might:

mkdir t_not_other_writable
mkdir x_not_other_writable
chmod o+t t_not_other_writable 
LS_COLORS='lc=:rc=:rs=:di=FG=BLD;CLR=BLUE :st=FG=REV;CLR=BLUE :' \
    /usr/bin/ls --color=always -nFl


drwxr-xr-x 1 1000 1000 0 Aug  7 14:37 FG=BLD;CLR=BLUE x_not_other_writable/
drwxr-xr-t 1 1000 1000 0 Aug  7 14:36 FG=REV;CLR=BLUE t_not_other_writable/

And just to be sure such a thing wasn't a ludicrously dangerous idea, I did double-check with google about what the sticky bit does:

A Sticky bit is a permission bit that is set on a file or a directory that lets only the owner of the file/directory or the root user to delete or rename the file. No other user is given privileges to delete the file created by some other user.

So if we're talking about your directories which are not things you intend to allow others to delete in the first place, probably there is no harm done.

P.S. If you're curious about what's going on with the $LS_COLORS definition there I covered it pretty well (I hope) here. I have also pasted in some more comments from the source below which I expect you will find align pretty well with the output dircolors -p will provide you (for the ones it bothers to also define, that is):

#   /* lc: Left of color sequence */
#   /* rc: Right of color sequence */
#   /* ec: End color (replaces lc+no+rc) */
#   /* rs: Reset to ordinary colors */
#   /* no: Normal */
#   /* fi: File: default */
#   /* di: Directory: bright blue */
#   /* ln: Symlink: bright cyan */
#   /* pi: Pipe: yellow/brown */
#   /* so: Socket: bright magenta */
#   /* bd: Block device: bright yellow */
#   /* cd: Char device: bright yellow */
#   /* mi: Missing file: undefined */
#   /* or: Orphaned symlink: undefined */
#   /* ex: Executable: bright green */
#   /* do: Door: bright magenta */
#   /* su: setuid: white on red */
#   /* sg: setgid: black on yellow */
#   /* st: sticky: black on blue */
#   /* ow: other-writable: blue on green */
#   /* tw: ow w/ sticky: black on green */
#   /* ca: black on red */
#   /* mh: disabled by default */
#   /* cl: clear to end of line */

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.