Ryan Schmidt wrote:
On May 2, 2022, at 23:49, Sriranga Veeraraghavan wrote:
>/I am not a zsh user, but according to zsh's documentation,
~/.zprofile is run only when zsh is used as a login shell, whereas
~/.zshenv is read for nearly every instance of zsh (including scripts): />//>/https://zsh.sourceforge.io/Guide/zshguide02.html#l9 />//>/Because of this, it is possible that if /opt/local/bin, etc., are
only added to PATH in ~/.zprofile, then in some instances zsh would
use the Apple standard programs in /bin, /sbin, /usr/bin, etc., while
in other instances zsh would use, for example, the MacPorts versions
in /opt/local/bin, etc. This might lead to inconsistencies or hard to
detect bugs in shell scripts, etc. /
MacPorts has been modifying ~/.zprofile when the shell is zsh ever since zsh
support was added to MacPorts 2.5 years ago. If it is a problem, nobody has
reported it so far.
https://github.com/macports/macports-base/commit/f9a3b2d5bcc27a1a279184c496a095f31b5d85a2
All shells on macOS are login shells.
Not all shells are login shells, but non-login shells are commonly child
processes of a login shell that already executed the startup files. So
non-login shells will usually inherit any variables exported in
zprofile. Also, any shell can (and often does) run another shell. That
means that all code in zshenv and zshrc needs to behave correctly when
executed multiple times. Unconditionally appending to PATH will result
in the value being added multiple times, once per "layer" of shell. So
that's one reason why we don't use zshenv.
The other is that Apple's /etc/zprofile overwrites PATH, so any changes
made to it before that file is read don't stick.
- Josh
