Updated activation instruction for zsh color issue

[szul]

This should resolve #20 and hopefully #17.

[brianrobt]

Can we get this merged? This same applies for fish.

[szul]

No clue why it hasn't been reviewed or merged yet.

[brianrobt]

I'm using a completely different .dir_colors file now, which I actually like more: https://github.com/trapd00r/LS_COLORS

I have a patch ready for the dircolors util to add Fish support that I need to submit to GNU.

[arcticicestudio]

Hi @szul :wave:, thanks for your contribution :+1:

No clue why it hasn't been reviewed or merged yet.

Even when this is “just“ a simple theme repository, the maintenance of the Nord could be a full time job. I'm a single person and there are currently 350+ issues and pull requests in all Nord repositories. This does not include all the “support“ kanban boards, emails, GitHub and chat notifications and discussion threads so maintaining such a project next to a full time developer job is really time consuming.

Anyway, I guess there are also a few misunderstandings regarding the ls command the functionality of this theme for it. At first, it is important to know that the ls command has absolute nothing to do with the shell. In fact, function scope of most shells is actually very low and is almost only limited to the shell builtins and interpreter that is able to parse and understand the script code, e.g. if or while statements. However, it is important that ls is not a shell builtin but a external executable! It should also be mentioned that each shell comes with its own builtins, even when most popular shells like ZSH and Bash are almost identical to each other.

Most of the user confusion arises because of the fact that there are multiple implementation of ls. The most common ones are

1. GNU ls (part of the Linux core utils), the one mainly targeted by this theme through the dircolors command.
2. BSD ls, the one distributed by operating systems like macOS.

The main difference between both is that they use different mechanisms to colorize their output. GNU ls reads the LSCOLORS environment variable that should contains ANSI like color definitions, e.g. di=34:ln=35:so=32:pi=33:ow=30;43. BSD ls on the other side checks and reads for the LS_COLORS environment variable, but expects a totally different format like exfxcxdxbxegedabagacad. Check out tools like the LSCOLORS generator to play around with both formats.

Maybe you wonder why this theme is called dircolors and not lscolors, and the answer is quite simply: it is targeted for dircolors, a tool to simplify the composition and persistence of the value for the LSCOLORS environment variable. It reads a file (default: ~/.dir_colors) that contains statements to define which colors to use for which file types and extensions. You can run dircolors --print-database to print the currently active definitions in your shell session environment. So all the install command of this theme (eval $(dircolors ~/.dir_colors) placed in the initialization file of your shell) does is to execute the dircolors command in order to “convert“ the definitions from the file into the LSCOLORS specific format to be picked up by tools like GNU ls or other ones that respect this variable, e.g. tree or awesome (modern) tools like fd.

In summary, that means that is does not matter which shell is used but which implementation of ls. There is also a large box at the top of the Nord dircolors documentation page about supported types and information about GNU ls and dircolors in the quick start section of the repository README. An improvement might be to also include the large information box in the theme installation documentation to ensure that users are aware of it.

I hope this brings some light into this topic, but I totally feel that this complex, legacy history of shell tooling is kind of confusing :smile: Modern tools like exa, rg and fd exist to finally get things like this out of the world, but I guess the next 10+ generations will still have to deal with it until other tools replace the current default ones.