or and mi are different

[tavianator]

On my system,

$ ln -s nowhere broken
$ ./target/debug/lscolors broken
broken

is printed without any color, despite ls showing it bold and red. The reason is that I have or=40;31;01:mi=00: in my LS_COLORS, and lscolors does

                            "or" | "mi" => lscolors.broken_symlink = Some(style),

so mi=00 overwrites or.

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

$ LS_COLORS='or=31;01:mi=33;01:' ls -lh broken
lrwxrwxrwx 1 tavianator users 7 Jan  7 14:23 broken -> nowhere

broken gets the red or color, and nowhere gets the yellow mi color. 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.

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.

[sharkdp]

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".

[tavianator]

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.

[sharkdp]

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.

[sharkdp]

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).