4 ms·
> sendenv also writes to "~/.bash_profile", "~/.zshrc", which is fraught (i.e. on my system they're read-only files). > If you want them to persist system-wide
by chrisfinazzo 3y ago
> sendenv also writes to "~/.bash_profile", "~/.zshrc", which is fraught (i.e. on my system they're read-only files).
> If you want them to persist system-wide, use ansible or some other configuration management.
I kind of understand not wanting to give other people the ability to mess with your shell, but why are these read-only?
Also, curious about the choice of Ansible...symlinks are a thing and the setup is really only as complicated as you make it. Building a mansion when you might only "need" a house with 1 or 2 bedrooms seems like an odd decision.
- TheDong 3y agoThey're read-only because I use a dotfile manager for them, and that manager owns the contents of those files, so it doesn't want external changes to mess with them. I'm specifically using home-manager [0], but various other profile managers will also make them read-only... Especially since any changes to them will just be over-written next time you apply your dotfiles, right? I think 'direnv' is really the way to go here for most cases you want to share environment variables between developer machines, but if you're managing user's shell rc files, then you might as well use proper configuration management, because ad-hoc appending strings to those rc files is the stuff of nightmares. [0]: https://github.com/nix-community/home-manager https://github.com/nix-community/home-manager
- chrisfinazzo 3y agoAh, now I see... The thing that really made dotfiles click for me was the switch to zsh in macOS + Armin Briegel's (of Scripting OS X) book, which laid out exactly how the transition was going to work. I'd done some basic things in `.bash_profile`, but this took it to another level entirely. Tl;dr `zsh-newuser-install` is pretty idiot-proof, but it helps to know what the options are if you've never seen them before.