search

sharkdp / lscolors

A Rust library and tool to colorize paths using LS_COLORS
Apache License 2.0
265 stars 18 forks source link

Support LSCOLORS env variable on macOS #55

Open ArtAndreev opened 2 years ago

ArtAndreev commented 2 years ago

I wanted to customize fd colors and read the docs. I found out that it uses LS_COLORS for customization.

macOS builtin ls command reads colors from LSCOLORS env variable, not LS_COLORS.

man ls ``` LSCOLORS The value of this variable describes what color to use for which attribute when colors are enabled with CLICOLOR or COLORTERM. This string is a concatenation of pairs of the format fb, where f is the foreground color and b is the background color. The color designators are as follows: a black b red c green d brown e blue f magenta g cyan h light grey A bold black, usually shows up as dark grey B bold red C bold green D bold brown, usually shows up as yellow E bold blue F bold magenta G bold cyan H bold light grey; looks like bright white x default foreground or background Note that the above are standard ANSI colors. The actual display may differ depending on the color capabilities of the terminal in use. The order of the attributes are as follows: 1. directory 2. symbolic link 3. socket 4. pipe 5. executable 6. block special 7. character special 8. executable with setuid bit set 9. executable with setgid bit set 10. directory writable to others, with sticky bit 11. directory writable to others, without sticky bit The default is "exfxcxdxbxegedabagacad", i.e., blue foreground and default background for regular directories, black foreground and red background for setuid executables, etc. ```

I suggest to support this variable and read from it on macOS. Also lib can provide default value (exfxcxdxbxegedabagacad) for it.

The style will be more consistent across ls and fd by default.

ArtAndreev commented 2 years ago

As workaroung setting LS_COLORS to di=34:ln=35:so=32:pi=33:ex=31:bd=34;46:cd=34;43:su=30;41:sg=30;46:tw=30;42:ow=30;43 (converted from default value by https://geoff.greer.fm/lscolors/) helped. Maybe it can be useful.

sharkdp commented 2 years ago

Thank you for your feedback. I'm not sure if that's something that we will support in this library. Certainly not by default, because that could lead to unexpected behavior. For example, what if someone has both LSCOLORS and LS_COLORS set? Which should take precedence?

ArtAndreev commented 2 years ago

LSCOLORS variable looks like a fallback variant of LS_COLORS since this library provides support for LS_COLORS first. But maybe the library should focus on one thing at the moment: LS_COLORS.

tavianator commented 2 years ago

As workaroung setting LS_COLORS to di=34:ln=35:so=32:pi=33:ex=31:bd=34;46:cd=34;43:su=30;41:sg=30;46:tw=30;42:ow=30;43 (converted from default value by https://geoff.greer.fm/lscolors/) helped. Maybe it can be useful.

That website's conversion is not 100% accurate: Screenshot of different blue colors

Anyway I think it's reasonable to use LSCOLORS if it's set and LS_COLORS is not. I plan to do that in bfs.

tavianator commented 2 years ago

Oh actually that depends on $TERM. The FreeBSD/macOS ls implementation checks termcap for color support. If you give it TERM=xterm instead of TERM=xterm-256color then it will match.

sharkdp commented 2 years ago

Okay. Using it as a fallback seems reasonable. Still not sure if we should do this by default (I'm talking about lscolors the library here. I'd probably be okay with doing that in fd by default). Or does GNU ls do that on BSD/macOS? Doesn't look like the source code references LSCOLORS somewhere.