Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for incompatibilities with GNU ls #48

Open
1 of 7 tasks
tavianator opened this issue Jun 15, 2022 · 9 comments
Open
1 of 7 tasks

Tracking issue for incompatibilities with GNU ls #48

tavianator opened this issue Jun 15, 2022 · 9 comments

Comments

@tavianator
Copy link
Contributor

tavianator commented Jun 15, 2022

@sharkdp
Copy link
Owner

sharkdp commented Jun 15, 2022

Thank you for collecting these!

sharkdp added a commit that referenced this issue Apr 1, 2023
This adds an initial set of integration tests that make sure that we
generate the same styles as GNU `ls`.

Related: #48
sharkdp added a commit that referenced this issue Apr 1, 2023
This adds an initial set of integration tests that make sure that we
generate the same styles as GNU `ls`.

Related: #48
sharkdp added a commit that referenced this issue Apr 1, 2023
This adds an initial set of integration tests that make sure that we
generate the same styles as GNU `ls`.

Related: #48
@alexkunde
Copy link
Contributor

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
Copy link
Contributor

alexkunde commented May 22, 2023

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

sholderbach added a commit to sholderbach/lscolors that referenced this issue Jun 6, 2023
This release includes support for `gnu_legacy` output of CSI sequences. This should resolve one of the outstanding issues in sharkdp#48

For the full release notes see:
https://github.com/nushell/nu-ansi-term/releases/tag/v0.48.0
@tavianator
Copy link
Contributor Author

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.

Screenshot_20230608_112707

@alexkunde
Copy link
Contributor

alexkunde commented Jun 13, 2023

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

@matrixhead
Copy link
Contributor

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

@tavianator
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor

matrixhead commented Jul 6, 2024

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants