Make the default LS_COLORS value match ls

[tavianator]

Previously, LS_COLORS_DEFAULT included colors for a lot of extensions that are not colored by default by GNU ls. That meant that for an unset/empty LS_COLORS, or just one with different extension colors set, lscolors would disagree with ls about how to color many files, e.g.:

$ export LS_COLORS=
$ ls /proc/config.gz
/proc/config.gz
$ lscolors /proc/config.gz
/proc/config.gz

The lscolors output was bold red, while the ls output was plain.

Fix it by using the same defaults as GNU ls.

[sharkdp]

Thank you for the contribution.

I think the value I used was probably extracted from some distribution default (Debian/Ubuntu? I should have added a reference). While I agree that, given the description in the README concerning the compatibility with ls, we should offer the ls default in some way, I'm not sure if anyone really wants that stripped-down default?

For fd as a downstream package that uses this library, we do have quite a few users that will see the default colorization, particularly on non-Unix platforms. Okay, I just realized that we have a separate LS_COLORS_DEFAULT in fd.

[tavianator]

The existing default is probably nicer for people without LS_COLORS set at all, though still different from ls. The thing that worries me is if you intentionally remove something from your LS_COLORS, it might not get removed from lscolors/fd:

Okay, I just realized that we have a separate LS_COLORS_DEFAULT in fd.

Hmm, I didn't know that. It seems to only apply if LS_COLORS is totally unset, not just empty.

[sharkdp]

The thing that worries me is if you intentionally remove something from your LS_COLORS, it might not get removed from lscolors/fd

I.. don't really understand why that happens? Is it a bug? Isn't the default LS_COLORS_DEFAULT value only used if LS_COLORS is unset/empty?

[tavianator]

The defaults are per-indicator since https://github.com/sharkdp/lscolors/issues/19