`or` and `mi` are different about lscolors HOT 4 CLOSED

Or you could apply the fallback when you construct the LsColors object. Or wait until you're actually coloring a file to apply it.

The problem is that those fields are currently public. They were intended for users of this library that don't want to rely on one of the provided methods (like style_for_path) but rather implement their own logic and just use this library as a parser for LS_COLORS. Another reason was that, in principle, users could also overwrite certain styles after constructing the LsColors object from the environment variable.

from lscolors.

Thank you for the detailed report. This should be fixed. I misinterpreted (or rather: didn't really know) what mi represents.

My understanding of the semantics is that or (orphan) is for broken links, and mi (missing) is for files that don't exist.

I can reproduce this. You are right.

Additionally, mi falls back to or if mi is not set, so LS_COLORS='or=31;01:' results in both getting the red or color.

This is interesting, because it probably requires me to rethink the API of lscolors a little bit. It currently exposes LsColors::broken_symlink: Option<Style> as a field, but if there are fallbacks, we probably need functions (like LsColors::missing_style() -> Option<Style>) that implement the necessary fallback logic.

Finally, setting a key (besides rs) to a string containing only zeros is the same as having it unset, so
LS_COLORS='or=31;01:mi=00: keeps everything red.

👍

I'm not sure if lscolors tries to color links differently than link targets, but regardless, mi=00: shouldn't be overwriting the or color.

Yes, absolutely. For the lscolors library, there should be a way to get the style for both "orphan" and "missing". For the lscolors binary, we could print broken symlinks as "orphan" and print any non-existing path as "missing".

from lscolors.

This is interesting, because it probably requires me to rethink the API of lscolors a little bit. It currently exposes LsColors::broken_symlink: Option<Style> as a field, but if there are fallbacks, we probably need functions (like LsColors::missing_style() -> Option<Style>) that implement the necessary fallback logic.

Or you could apply the fallback when you construct the LsColors object. Or wait until you're actually coloring a file to apply it.

from lscolors.

The main issue has been resolved in #12.

I have opened two new tickets #13 and #14 for the remaining issues (fallback from mi => or, reset via zero).

from lscolors.