colors don't kick in for ls on macOS Big Sur, Monterey (and maybe FreeBSD)

[floam]

This is because at some point they (I think this is from FreeBSD ls) added --color=auto but it works different than coreutils ls:

from the manage:

             [--color=]auto will make ls output escape sequences based on termcap(5), but
             only if stdout is a tty and either the -G flag is specified or the
             COLORTERM environment variable is set and not empty.

and ls.fish no longer will execute ls -G, since --color=auto doesn't fail. I think we should just export the variable.

[faho]

think we should just export the variable.

@floam

No, we should not be setting terminal configuration variables, just like we shouldn't be changing $TERM. Really, the terminals here should be setting them, especially when core utilities shipped with the system expect them.

What we can do is fall back on cheesy --version GNU detection.

[floam]

Well, it'll take CLICOLOR too. I don't exactly see what the problem would be; it's just the user expressing a preference that nothing except ls even is aware of, right? It's more like LS_COLORS or aliasing ls than messing with TERM or LANG. If we're pretty sure --version will tell us whether we need to use -G or --color=auto on FreeBSD still, I suppose that's good.

[floam]

(If a concern could be that setting either of those variables will force colored output if e.g. TERM=dumb, that is not the case. The auto behavior is reasonable.)

[faho]

it's just the user expressing a preference that nothing except ls even is aware of, right?

It's, uh, not. It's a general variable that'll be used in more places.

It's more like LS_COLORS or aliasing ls than messing with TERM or LANG.

No, it's like messing with TERM.

I'm not specifically aware of anything that uses "$CLICOLOR", but it doesn't have "LS" or anything else marking it as specifically for ls in the name, so it doesn't seem safe, and I know for a fact that $COLORTERM is used elsewhere - e.g. even fish will use it to enable truecolor!.

It might be possible to set these just in the ls wrapper, but then you have the issue of setting it also for other lsen, and could change things there, when it's just about macOS' default settings being broken!

[faho]

Okay, there are a bunch of mentions of CLICOLOR on github, many of which requests for other tools to support it.

So this should not be set by us in general.

[floam]

It's, uh, not. It's a general variable that'll be used in more places.

Okay, I was going based on what I read about one of the variables being ls-specific and my own system (just ls, and sudo passing it through):

floam@M1 /bin> ggrep -r 'CLICOLOR\|COLORTERM' .
ggrep: ./ls: binary file matches
floam@M1 ~> cd /usr/bin
floam@M1 /u/bin> ggrep -r 'CLICOLOR\|COLORTERM' .
ggrep: ./sudo: binary file matches

Regardless, we'd only be exporting CLICOLOR locally for ls, so we can just do whatever is most convenient, that or -G.

[faho]

►grep -r 'CLICOLOR\|COLORTERM' /usr/bin/ --files-with-match 2>/dev/null | xsel --clipboard
/usr/bin/libtool
/usr/bin/x86_64-pc-linux-gnu-c++
/usr/bin/ls
/usr/bin/ccmake
/usr/bin/gcov-tool
/usr/bin/x86_64-pc-linux-gnu-gcc-11.1.0
/usr/bin/pkexec
/usr/bin/lazygit
/usr/bin/vdir
/usr/bin/gcc
/usr/bin/autopoint
/usr/bin/alacritty
/usr/bin/mc
/usr/bin/gcov
/usr/bin/nvim
/usr/bin/ctest
/usr/bin/libtoolize
/usr/bin/cpack
/usr/bin/cpp
/usr/bin/c++
/usr/bin/tree-sitter
/usr/bin/x86_64-pc-linux-gnu-gcc
/usr/bin/dir
/usr/bin/ninja
/usr/bin/xprop
/usr/bin/bat
/usr/bin/gnome-terminal
/usr/bin/g++
/usr/bin/cmake
/usr/bin/x86_64-pc-linux-gnu-g++
/usr/bin/rav1e
/usr/bin/autoconf
/usr/bin/cmake-gui
/usr/bin/gettextize
/usr/bin/hyperfine

Okay, I was going based on what I read about one of the variables being ls-specific and my own system (just ls, and sudo passing it through):

It no longer is, apparently at least one rust crate supports it, so e.g. hyperfine uses it.

---

Okay, so this seems down to FreeBSD's ls now supporting ls --color=auto but then still relying on these variables. This means we would have to detect FreeBSD's ls specifically, but on FreeBSD it probably won't be an issue because the terminals there would just set $COLORTERM.

I'm leaning towards either a uname = Darwin check, or $TERM_PROGRAM = Terminal.app (I'm imagining iTerm might be better here?)

[faho]

Okay, $TERM_PROGRAM is a winner, iterm sets $COLORTERM: https://gitlab.com/gnachman/iterm2/-/issues/5294.

[floam]

Okay, so this seems down to FreeBSD's ls now supporting ls --color=auto but then still relying on these variables

This is what I explained in the initial post. Correct.

I'm leaning towards either a uname = Darwin check, or $TERM_PROGRAM = Terminal.app (I'm imagining iTerm might be better here?)

Are you saying to export the variable, or to use -G which forces it?

[faho]

Are you saying to export the variable, or to use -G which forces it?

Export the variable. We don't actually know for sure that the ls is FreeBSD ls (might even be gnu ls!), and detecting that is annoying, but setting $CLICOLOR should be relatively harmless.

For GNU ls, -G is --no-groups, which is, uh, different.

[mqudsi]

I hate to suggest it, but isn't a uname-based approach cleaner here? I also don't like the hard-coded Apple_Terminal bit; this affects much more than that.

This isn't really a new issue, I have a custom ls.fish in my fish.config repo to get colored ls output on FreeBSD from years ago. I'd still have to keep it even with this patch.

If, as we are arguing (and I would concur) setting CLICOLOR for the duration of the command is fairly harmless, I think we should just do it. We really prefer not to special case things dependent on the terminal emulator wherever possible.

Okay, so this seems down to FreeBSD's ls now supporting ls --color=auto but then still relying on these variables. This means we would have to detect FreeBSD's ls specifically, but on FreeBSD it probably won't be an issue because the terminals there would just set $COLORTERM.

FreeBSD isn't exactly a world-famous desktop environment, I'd wager a huge chunk of heavy FreeBSD users (like me!) use it strictly over ssh from a non-FreeBSD environment, in which case that variable isn't set.

[faho]

I hate to suggest it, but isn't a uname-based approach cleaner here?

I don't see what uname fixes. This is a problem on terminals with bad defaults, and the main terminal with bad defaults is Terminal.app (it's probably the terminal we have the most workarounds for).

This isn't really a new issue, I have a custom ls.fish in my fish.config repo to get colored ls output on FreeBSD from years ago. I'd still have to keep it even with this patch.

If you, yourself, want to have the color, then just set $COLORTERM or $CLICOLOR yourself. No need for a custom ls.fish. We just can't do it because it's a land grab.

If, as we are arguing (and I would concur) setting CLICOLOR for the duration of the command is fairly harmless, I think we should just do it. We really prefer not to special case things dependent on the terminal emulator wherever possible.

That's an option. I'd rather not do that because I have no idea if anything else uses $CLICOLOR and if it might be configured, by the user, on an actual FreeBSD system. Or if it means something else elsewhere.

Hence the targeted fix: Just do it for the terminal we know to be bad, which only runs on the one system we know to be bad.

But tbh I don't care too much, so if you want just remove the test entirely and set $CLICOLOR unconditionally.