Support more dircolors keys

[tavianator]

Right now it supports the ones based on file types. But there's also

• ca for files with capabilities set
• do for doors (some Solaris thing)
• fi for regular files
• mh for files with multiple hard links
• no the "normal" color which acts as a fallback
• ow for directories writable by other users
• su for setuid files
• sg for setgid files
• st for sticky files
• tw for sticky directories that are writable by other users

[sharkdp]

Thank you for the feedback. Sounds good! We should try to support all of these (if feasible / possible).

[sharkdp]

Do you know how ls treats multiple matches?

What if a file is both executable (ex) and has multiple hard links (mh)?

[tavianator]

My version of the logic in C, in file_color(): https://github.com/tavianator/bfs/blob/master/color.c#L371.

In particular, ex seems to supersede mh if ex is set. But if ex is unset or zero, then mh applies.

I'm currently cooking up a test script that compares my version against the output of ls, so there may be some differences in corner cases, but I've tested a lot of it by hand and it seems to behave the same.

[sharkdp]

Thank you very much for sharing your implementation!

So I guess there is no real specification on how LS_COLORS is intended to work, as you also seem to use the ls implementation as your reference.

[tavianator]

Yeah the spec is the implementation AFAIK ;)

There's man dir_colors on Linux which specifies some details like

       ORPHAN color-sequence
              Specifies the color used for an orphaned symbolic link (one
              which points to a nonexistent file).  If this is unspecified,
              ls will use the LINK color instead.

but it doesn't tell you details like the relative priorities of things like su, sg, ex, etc.

[trapd00r]

Hey,
I'm trying to implement the same thing in my File::LsColor library and I wonder if this really can be implemented in a good way that doesn't take away any usefulness of our modules.
When I use it myself I don't always care for if the files do exist or not, or where in the filesystem they reside. I might only be interested in the basenames, and given for example:

the filenames are relative and you can't stat them, thus you can't decide if they are directories, executables or anything else. (In this simple example I know what they are, but you get the point).

If we want to implement all of these extra keys, we would need to always get absolute paths as input which I don't think is feasible.

Thoughts?

[sharkdp]

If I understand you correctly, the question is not really about relative or absolute paths, but rather about whether LS_COLORS-based colorization makes sense for paths which we can not stat for some reason (might be a made up filename, a relative path where we do not know the origin, a path on a remote system, etc.).

In my understanding, there are two steps in the LS_COLORS colorization.

1. Metadata-based colorization (for directories, symlinks, executable files, etc.)
2. If none of the patterns from step 1 apply, use a filename-suffix based loopkup (e.g. colorize *.flac files in a specific way)

lscolors is definitely designed in such a way that we always perform step 1 first, i.e. we need to have the filesystem metadata (unless it's actually a "missing" file). On the other hand, I can see how it could be useful to have a public method that would allow a suffix-based lookup without performing step 1.

[trapd00r]

I made the first step configurable with a simple binary on/off switch, because of

• the usefulness of not freaking out if a 'file' can't be stat():ed
• performance reasons

[sharkdp]

I believe this can be closed. I don't expect that anyone will miss do and ca. Otherwise, please let me know.