Better Mac Support

[hponde]

I was able to get this working on a Mac by using gls (GNU ls) instead and just then compiling the repo using dircolors in a quick Ubuntu docker.

I think it could be nice to add these instructions/functionality to the repo and for example compile LS_COLORS automatically by default on each commit.

@rpdelaney what do you think? Would you approve if I created a Pull request for it? I didn't see anything on the docs about your thoughts on Mac support

[rpdelaney]

We've shied away from trying to support every shell in the docs, but there is not so much proliferation in desktop operating systems that people use LS_COLORS on. Whether I would accept a PR might swing on what it is we are documenting.

The problem (I think) is that one needs GNU dircolors, which is not available on macOS without installing GNU coreutils. coreutils in homebrew used to have an --install-default-names option but that was removed because it can cause breakage on other parts of the system. Instead you now get this info printed:

Commands also provided by macOS have been installed with the prefix "g".
If you need to use these commands with their normal names, you
can add a "gnubin" directory to your PATH from your bashrc like:
  PATH="/usr/local/opt/coreutils/libexec/gnubin:$PATH"

Putting that into the README -- along with the warning about possible instability from replacing BSD coreutils that ship on macOS with GNU coreutils -- is getting pretty long already.

Maybe it's enough to say that GNU dircolors is a dependency and mention that macOS users will have to install it from somewhere, and leave it at that?

[rpdelaney]

Another option might be to provide a Dockerfile for building in Docker, as you did

[hponde]

Wow I didn't even make the connection that indeed from the installation I have gdircolors available and could have gone that way.

I don't know much about shell intricacies so in fact it took me a bit to realize I needed to use gls instead of the default ls to get the colors working as intended. With just the macOS ls I was running into the issue:

error: invalid character '8' in LSCOLORS env var
...

Like mentioned in #64

So I would like to help make this simpler on macOS but it seems that it would require:

1. Having some Dockerfile to "compile" LSCOLORS/LS_COLORS (easy)
2. Instructing people to install gls (which I assume comes from coreutils as well)
3. Alias ls to gls --color=tty (or something similar)

I could not get rid of 2. since it seemed that the default macOS's ls does not handle the color formats as we want.

But if we're telling people to install coreutils then you don't need a Dockerfile since they can use gdircolors directly. So I don't know what it does, unless you can get around the ls -> gls need. Do you have any thoughts/knowledge on that?

[rpdelaney]

My over-arching concern about all such things is that I just want to keep the documentation on LS_COLORS as simple as possible. If we start documenting individual (corner) use cases then we have to maintain documentation for tools that have their own documentation elsewhere already.

The upshot of that might be that saying something like "On macOS you need GNU dircolors" and/or "you need GNU ls" is fine. But once we get into "and here's how you can install it and set it up using this one package manager here" (will macports users now want their own docs in this repo?) and "here are aliases that you can use" then this all proliferates in complexity, especially over time.

Related: #3

[hponde]

I see. That makes sense, I think simplicity is a good goal here. I think for someone that is not as knowledgeable as me trying to get it to work on Mac, something like "On macOS you need GNU dircolors and ls." plus the optional "You can look into installing coreutils for that" would have been enough to have saved me some time.

Are you ok with making a change like that?

[rpdelaney]

Check out #164 and let me know what you think.