3 ms·
I have managed to avoid fiddling with the init hook scripts themselves, so I hadn't actually thought about this specific idea. IDK if my thoughts will be produc
by abathur 4y ago
I have managed to avoid fiddling with the init hook scripts themselves, so I hadn't actually thought about this specific idea. IDK if my thoughts will be productive/incisive.
I've definitely felt like the Nth-shell situation is untenable and that we'll either need to abstract a definition to generate the hooks from or find some other ~general/universal solution.
I like the way this suggestion sounds with respect to getting out of that maintainability problem, but I'm not sure if it'll work quite right?
Here's one crappy rabbit-hole we've gone down:
Since macOS changed its default shell to zsh, they've been overwriting /etc/zshrc with every update (this evicts Nix's hook, confuses/scares people, and makes them try to reinstall; note that they aren't using the Relocated Items treatment we'd expect from how they do this with most stuff in /etc/ including /etc/bashrc while it was still the default shell).
An enterprising zsh user PRed a fix that moves the hook to /etc/zshenv. macOS doesn't ship /etc/zshenv, so they don't overwrite it on update. It seems to work at a blush, but Nix and everything you install with Nix ends up at the end of your PATH instead of the beginning, so everything that depends on a PATH lookup will keep using your system utilities.
Why? IIRC because the /etc/zshprofile macOS ships will do "eval `/usr/libexec/path_helper -s`", and path_helper will add things from /etc/paths and /etc/paths.d to the left of the existing PATH. I suspect if we inject a binary or even a script to preconfigure this environment, the call to path_helper in the zsh init process is still going to leave everything we added at the end of the PATH. We could in theory add an /etc/paths.d/nix, but path_helper appends this after everything in /etc/paths, so it has the same problem. We could stick our Nix-related directories at the top of /etc/paths, but macOS does ship this file so we have no reason to have faith that macOS updates don't overwrite it or won't start doing so at some point.
(We might also be able to move this to /etc/zshenv and also define a `/usr/libexec/path_helper(){ ... }` function that behaves like WE want--but that could obviously have downstream effects on other code in user profile/init scripts that uses path_helper. No clue if this is common.)