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

Support LSCOLORS env variable on macOS #55

Open
ArtAndreev opened this issue Oct 28, 2022 · 6 comments
Open

Support LSCOLORS env variable on macOS #55

ArtAndreev opened this issue Oct 28, 2022 · 6 comments

Comments

@ArtAndreev
Copy link

ArtAndreev commented Oct 28, 2022

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

ArtAndreev commented Oct 28, 2022

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

sharkdp commented Oct 29, 2022

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

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

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

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

sharkdp commented Oct 29, 2022

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.

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

3 participants