I had these set up in the first place mostly because GNU ls supports
--color=auto and the BSD ls provided with MacOS didn't, causing problems
if I aliased ls to ls --color=auto.
And I don't really need that any more, especially since I prefer to use
lsd-rs/lsd in place of the coreutils ls nowadays. Additionally, the BSD
ls that comes with MacOS now *does* support that flag, so in a pinch it
can do what I need.
Defaulting to the natively installed coreutils should help my usage of
these tools more portable too, rather than always relying on GNU-isms.
Given my huge reliance on Zsh-specific features that's not something I'm
doing super well anyway, but still.
It's not ideal to set XDG_RUNTIME_DIR in your shell environment,
rather than from your session manager (or systemd, or whatever), since
then you can't reliably provide the same lifetime guarantees that
XDG_RUNTIME_DIR is supposed to have? But this is still preferable to not
having an XDG_RUNTIME_DIR at all, so I'm gonna go with it.
We want to store the Node REPL history in XDG_DATA_HOME, and we also
want to make sure we always have an npm config file that sets up npm
with its appropriate XDG paths. (By default, lots of stuff ends up in
~/.npm if no configuration is provided.)
As I mention in the diff, we can't simply commit the npm config file to
version control, because it contains things like authorisation tokens
that shouldn't be committed. We can however generate a default config
file that sets up the XDG paths we need, allowing the user to then go
ahead and add tokens to the generated file later on, like so.
An XDG runtime directory cannot be provided reliably by the shell,
because it's supposed to have the same lifetime as the user's login
session, and the shell doesn't have a reliable way to keep track of that
lifetime. There are probably nonportable ways to get a conforming
directory, such as making a request to PAM, but PAM is supposed to set
XDG_RUNTIME_DIR itself anyway and also doesn't exist on Macs, which I
use most of the time.
My configuration isn't actually using XDG_RUNTIME_DIR anyway, so I don't
want to provide the misleading impression that a runtime directory with
proper behaviour conforming to the specification is definitely
available.
