Tracking issue for incompatibilities with GNU ls

[tavianator]

• ln=target should color symlinks like their target

  Add support for ln=target #11 was closed as wontfix, but this might be possible now after Add a Colorable trait to factor out metadata retrieval #45.

• ca (regular file with capabilities set)

  Support more dircolors keys #6 was closed as mostly completed, but ca (and do) remain unimplemented.

  It is very slow to check for capabilities (at least two syscalls per file). ca is no longer part of the default GNU ls color scheme.

• do (Solaris door)

  These are rare.

• Custom control sequences

  Add support for all possible ANSI styles? #2 and Unsupported ANSI codes should be ignored #21 are relevant issues. Currently lscolors will ignore control sequences it doesn't understand, while GNU ls just passes everything through verbatim.

  GNU ls even supports non-ANSI terminals by customizing rs, lc, rc, ec, cl.

• Escape sequences

  LS_COLORS="ex=m\07\033[0" should ding a bell every time an executable file is encountered.

• fi=0 should not fall back to no

• Smart case sensitivity for suffix matching (Sensitive cases #69, gnu compatiblity fix for case sensitivity handling of suffixes #86)

[sharkdp]

Thank you for collecting these!

[alexkunde]

Hi, Im working on getting the color-term gnu test for coreutils ls. And it present the following obstacle:

# rust version
~/coreutils/debug/target/ls --color=always exe
# c version
ls --color=always exe

-^[[0m^[[01;32mexe^[[0m$
+^[[1;32mexe^[[0m$

LSCOLORS with either nu-ansi-term or just ansi-term creates the additional colors as 1;xx instead of 01;xx, as well as it does not add a reset-character at the start. From what Ive tested so far, shell doesnt really care if you do any of that. At least newer shells. Maybe it was specific back in the day?

Any chance to improve here?

[alexkunde]

Please see nushell/nu-ansi-term#41 it will enable a LS fix

[tavianator]

I just discovered a new GNU ls behaviour which even bfs gets wrong: no is not used as a fallback for fi if fi is explicitly set to 0. In every other case I tested, 0 is the same as being unset.

[alexkunde]

another behavior that is ignored by lscolors crate right now, at least for nu-ansi-term, is reset styling re=xx.

[matrixhead]

hey, I would like to solve this issue. if you could give me some guidance on this, it would be really nice.

[tavianator]

I just discovered a new GNU ls behaviour which even bfs gets wrong

FTR this was fixed in bfs by tavianator/bfs@1d14431, and will be fixed here by #85.

[matrixhead]

Hi, I was working on GNU compatibility for uutils-ls where I encountered an issue with the suffix matching.

For example:

If we specify same suffix with two different cases and with same style.

touch img1.jpg IMG2.JPG img3.JpG
LS_COLORS="*.jpg=01;35:*.JPG=01;35" ls -U1 --color=always

This would give us the output.

^[[0m^[[01;35mimg1.jpg^[[0m
^[[01;35mIMG2.JPG^[[0m
^[[01;35mimg3.JpG^[[0m  <---------- notice it ignored the case and applied .*jpg's style to .*JpG

This would work just fine with our current version, since we always ignore the case, But if we specify the same suffix with two different cases with two different styles.

LS_COLORS="*.jpg=01;35:*.JPG=01;35;46" ls -U1 --color=always

This would give us the output.

^[[0m^[[01;35mimg1.jpg^[[0m <----------------------
^[[01;35;46mIMG2.JPG^[[0m   <---------------------- notice it honoured the cases for both the specified cases 
img3.JpG <----------- it didn't ignore the case and treated .JpG as another suffix which is not specified

So in short I suppose this is how gnu's suffix is matched, when two or more suffixes are specified in the env with different style then the matching would become case-sensitive otherwise it would ignore the cases.

[matrixhead]

Hi, I was working on this issue for uutils and encountered this issue,

• ca (regular file with capabilities set)

I would like to work on this, if possible could you guys give me some guidance on this 😀