* PSA: Mac OS X El Capitan upgrade might break your $PATH @ 2015-07-31 16:35 Kurtis Rader 2015-07-31 17:22 ` Bart Schaefer 2015-07-31 18:53 ` Mikael Magnusson 0 siblings, 2 replies; 8+ messages in thread From: Kurtis Rader @ 2015-07-31 16:35 UTC (permalink / raw) To: Zsh Users [-- Attachment #1: Type: text/plain, Size: 904 bytes --] A public service announcement for those running Zsh on Mac OS X. Upgrading to El Capitan (OS X 10.11) will install a /etc/zprofile that contains # system-wide environment settings for zsh(1) if [ -x /usr/libexec/path_helper ]; then eval `/usr/libexec/path_helper -s` fi On a new login shell that will be sourced after your $HOME/.zshenv. If you set your $PATH in your .zshenv the /usr/libexec/path_helper program will alter the order of the directories. The order appears random so it's probably using a hashed set to avoid having the same directory appear more than once in the result. You can't remove /usr/libexec/path_helper due to the new security mechanisms (at least not without booting from a recovery disk) but you can remove /etc/zprofile which is what I did to keep my $PATH from being mucked with. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PSA: Mac OS X El Capitan upgrade might break your $PATH 2015-07-31 16:35 PSA: Mac OS X El Capitan upgrade might break your $PATH Kurtis Rader @ 2015-07-31 17:22 ` Bart Schaefer 2015-07-31 18:53 ` Mikael Magnusson 1 sibling, 0 replies; 8+ messages in thread From: Bart Schaefer @ 2015-07-31 17:22 UTC (permalink / raw) To: Kurtis Rader, Zsh Users On Jul 31, 9:35am, Kurtis Rader wrote: } } On a new login shell that will be sourced after your $HOME/.zshenv. } If you set your $PATH in your .zshenv the /usr/libexec/path_helper } program will alter the order of the directories. } } You can't remove /usr/libexec/path_helper due to the new security } mechanisms (at least not without booting from a recovery disk) but you can } remove /etc/zprofile which is what I did Another option is to add to your ~/.zshenv the line: setopt no_global_rcs And then if desired in your ~/.zprofile add: setopt global_rcs This pair of commands placed in these two files will disable reading of /etc/zprofile and then re-enable reading of /etc/zshrc and /etc/zlogin, without needing to remove system files (which might re-appear on an update anyway). ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PSA: Mac OS X El Capitan upgrade might break your $PATH 2015-07-31 16:35 PSA: Mac OS X El Capitan upgrade might break your $PATH Kurtis Rader 2015-07-31 17:22 ` Bart Schaefer @ 2015-07-31 18:53 ` Mikael Magnusson 2015-07-31 21:05 ` Andrew Janke 2015-07-31 22:10 ` Kurtis Rader 1 sibling, 2 replies; 8+ messages in thread From: Mikael Magnusson @ 2015-07-31 18:53 UTC (permalink / raw) To: Kurtis Rader; +Cc: Zsh Users On Fri, Jul 31, 2015 at 6:35 PM, Kurtis Rader <krader@skepticism.us> wrote: > A public service announcement for those running Zsh on Mac OS X. > > Upgrading to El Capitan (OS X 10.11) will install a /etc/zprofile that > contains > > # system-wide environment settings for zsh(1) > if [ -x /usr/libexec/path_helper ]; then > eval `/usr/libexec/path_helper -s` > fi > > On a new login shell that will be sourced after your $HOME/.zshenv. If you > set your $PATH in your .zshenv the /usr/libexec/path_helper program will > alter the order of the directories. The order appears random so it's > probably using a hashed set to avoid having the same directory appear more > than once in the result. > > You can't remove /usr/libexec/path_helper due to the new security > mechanisms (at least not without booting from a recovery disk) but you can > remove /etc/zprofile which is what I did to keep my $PATH from being mucked > with. That's good news, they used to have that code in /etc/zshenv which meant you had _no_ way to override it. It only took them a few years to fix this. As a sidenote, it's not a great idea to set your path in .zshenv, you should probably move those settings to your .zprofile. (Otherwise, running a script that uses zsh will not use the $PATH from the environment, which can break things in some situations). -- Mikael Magnusson ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PSA: Mac OS X El Capitan upgrade might break your $PATH 2015-07-31 18:53 ` Mikael Magnusson @ 2015-07-31 21:05 ` Andrew Janke 2015-07-31 22:01 ` Kurtis Rader 2015-07-31 22:10 ` Kurtis Rader 1 sibling, 1 reply; 8+ messages in thread From: Andrew Janke @ 2015-07-31 21:05 UTC (permalink / raw) To: Mikael Magnusson, Kurtis Rader; +Cc: Zsh Users On 7/31/15 2:53 PM, Mikael Magnusson wrote: > On Fri, Jul 31, 2015 at 6:35 PM, Kurtis Rader <krader@skepticism.us> wrote: >> A public service announcement for those running Zsh on Mac OS X. >> >> Upgrading to El Capitan (OS X 10.11) will install a /etc/zprofile that >> contains >> >> # system-wide environment settings for zsh(1) >> if [ -x /usr/libexec/path_helper ]; then >> eval `/usr/libexec/path_helper -s` >> fi >> >> On a new login shell that will be sourced after your $HOME/.zshenv. If you >> set your $PATH in your .zshenv the /usr/libexec/path_helper program will >> alter the order of the directories. The order appears random so it's >> probably using a hashed set to avoid having the same directory appear more >> than once in the result. >> >> You can't remove /usr/libexec/path_helper due to the new security >> mechanisms (at least not without booting from a recovery disk) but you can >> remove /etc/zprofile which is what I did to keep my $PATH from being mucked >> with. > That's good news, they used to have that code in /etc/zshenv which > meant you had _no_ way to override it. It only took them a few years > to fix this. > > As a sidenote, it's not a great idea to set your path in .zshenv, you > should probably move those settings to your .zprofile. (Otherwise, > running a script that uses zsh will not use the $PATH from the > environment, which can break things in some situations). > I suspect the order of entries in path_helper is determined by alphabetical ordering of the filenames in /etc/paths.d, where path_helper locates the files that come after the default system paths. That "40-" in XQuartz looks like an rcdir-style technique to enforce ordering, and I think the XQuartz folks know what they're doing with the OS X system stuff. (This is on 10.9.) $ ls -l /etc/paths.d total 16 -rw-r--r-- 1 root wheel 13 Aug 11 2014 40-XQuartz -rw-r--r-- 1 root wheel 12 May 7 21:06 TeX Playing around with this seems to support that theory. Files read in order, duplicate entries removed after the first occurrence. #/bin/sh # install-hello-paths - script to test path_helper behavior echo /hello/world > /etc/paths.d/01-hello echo /hello/world > /etc/paths.d/99-hello One other El Capitan change: the system-supplied zsh (5.0.8) appears to be compiled with /usr/local/share/zsh/site-functions in the default $fpath, which was not the case for earlier versions of OS X. This is probably related to the "rootless" stuff that locks down /usr outside /usr/local/. Cheers, Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PSA: Mac OS X El Capitan upgrade might break your $PATH 2015-07-31 21:05 ` Andrew Janke @ 2015-07-31 22:01 ` Kurtis Rader 2015-07-31 22:29 ` Andrew Janke 0 siblings, 1 reply; 8+ messages in thread From: Kurtis Rader @ 2015-07-31 22:01 UTC (permalink / raw) To: Andrew Janke; +Cc: Mikael Magnusson, Zsh Users [-- Attachment #1: Type: text/plain, Size: 1920 bytes --] On Fri, Jul 31, 2015 at 2:05 PM, Andrew Janke <andrew@apjanke.net> wrote: > > > I suspect the order of entries in path_helper is determined by > alphabetical ordering of the filenames in /etc/paths.d, where path_helper > locates the files that come after the default system paths. That "40-" in > XQuartz looks like an rcdir-style technique to enforce ordering, and I > think the XQuartz folks know what they're doing with the OS X system stuff. > (This is on 10.9.) > That would be fine if it simply appended those directories in that order to the existing PATH as the man page claims. But it is clearly using a hash based ordering and ignoring even the apparent ordering implied by the file names in /etc/paths.d. From my system: 14:45 macbook coff ~ ls /etc/paths.d 40-XQuartz go 14:50 macbook coff ~ cat /etc/paths.d/* /opt/X11/bin /usr/local/go/bin 14:52 macbook coff ~ /usr/libexec/path_helper -s PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/go/bin:/Users/krader/bin:/Users/krader/sbin:/Users/krader/symlinks:/usr/local/sbin"; export PATH; 14:52 macbook coff ~ echo $PATH /Users/krader/bin:/Users/krader/sbin:/Users/krader/symlinks:/usr/local/bin:/usr/local/go/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/opt/X11/bin One other El Capitan change: the system-supplied zsh (5.0.8) appears to be > compiled with /usr/local/share/zsh/site-functions in the default $fpath, > which was not the case for earlier versions of OS X. This is probably > related to the "rootless" stuff that locks down /usr outside /usr/local/. > Yes, I noticed that as well and should have mentioned it as it causes zsh running as root to complain about "compinit: insecure files" since those files are managed by HomeBrew and owned by me. Computer Security: If it isn't getting in your way you're doing it wrong :-) -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PSA: Mac OS X El Capitan upgrade might break your $PATH 2015-07-31 22:01 ` Kurtis Rader @ 2015-07-31 22:29 ` Andrew Janke 2015-07-31 22:49 ` Kurtis Rader 0 siblings, 1 reply; 8+ messages in thread From: Andrew Janke @ 2015-07-31 22:29 UTC (permalink / raw) To: Kurtis Rader; +Cc: Mikael Magnusson, Zsh Users [-- Attachment #1: Type: text/plain, Size: 3151 bytes --] On 7/31/15 6:01 PM, Kurtis Rader wrote: > On Fri, Jul 31, 2015 at 2:05 PM, Andrew Janke <andrew@apjanke.net > <mailto:andrew@apjanke.net>> wrote: > > > I suspect the order of entries in path_helper is determined by > alphabetical ordering of the filenames in /etc/paths.d, where > path_helper locates the files that come after the default system > paths. That "40-" in XQuartz looks like an rcdir-style technique > to enforce ordering, and I think the XQuartz folks know what > they're doing with the OS X system stuff. (This is on 10.9.) > > > That would be fine if it simply appended those directories in that > order to the existing PATH as the man page claims. But it is clearly > using a hash based ordering and ignoring even the apparent ordering > implied by the file names in /etc/paths.d. From my system: > > 14:45 macbook coff ~ ls /etc/paths.d > 40-XQuartzgo > 14:50 macbook coff ~ cat /etc/paths.d/* > /opt/X11/bin > /usr/local/go/bin > 14:52 macbook coff ~ /usr/libexec/path_helper -s > PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/go/bin:/Users/krader/bin:/Users/krader/sbin:/Users/krader/symlinks:/usr/local/sbin"; > export PATH; > 14:52 macbook coff ~ echo $PATH > /Users/krader/bin:/Users/krader/sbin:/Users/krader/symlinks:/usr/local/bin:/usr/local/go/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/opt/X11/bin > That path_helper output doesn't look random or hash based. That looks like: - the system default paths (from /etc/paths) come first, in the order specified in /etc/paths /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin: - then the stuff from /etc/paths.d, in filename alphabetical order /opt/X11/bin:/usr/local/go/bin: - then any other item it found in $PATH at the time of its invocation, in the order in which they appeared in $PATH. /Users/krader/bin:/Users/krader/sbin:/Users/krader/symlinks:/usr/local/sbin That lastpart isn't documented in `man path_helper`, but it behaved this way consistently when I was testing it with various $PATH values. (on 10.9) The man page could stand tobe more thorough and clear, but I don't think it's randomly rearranging your path. And the `man path_helper` page does indicate where the default paths come from, though it's buried a few paragraphs down. Prior to reading these directories, default PATH and MANPATH values are obtained from the files /etc/paths and /etc/manpaths respectively. > > One other El Capitan change: the system-supplied zsh (5.0.8) > appears to be compiled with /usr/local/share/zsh/site-functions in > the default $fpath, which was not the case for earlier versions of > OS X. This is probably related to the "rootless" stuff that locks > down /usr outside /usr/local/. > > > Yes, I noticed that as well and should have mentioned it as it causes > zsh running as root to complain about "compinit: insecure files" since > those files are managed by HomeBrew and owned by me. > Computer Security: If it isn't getting in your way you're doing it > wrong :-) > -- > Kurtis Rader > Caretaker of the exceptional canines Junior and Hank ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PSA: Mac OS X El Capitan upgrade might break your $PATH 2015-07-31 22:29 ` Andrew Janke @ 2015-07-31 22:49 ` Kurtis Rader 0 siblings, 0 replies; 8+ messages in thread From: Kurtis Rader @ 2015-07-31 22:49 UTC (permalink / raw) To: Andrew Janke; +Cc: Mikael Magnusson, Zsh Users [-- Attachment #1: Type: text/plain, Size: 1159 bytes --] On Fri, Jul 31, 2015 at 3:29 PM, Andrew Janke <andrew@apjanke.net> wrote: > That path_helper output doesn't look random or hash based. That looks like: > [snip] > The man page could stand to be more thorough and clear, but I don't think > it's randomly rearranging your path. And the `man path_helper` page does > indicate where the default paths come from, though it's buried a few > paragraphs down. > Yes, your analysis appears correct. In all likelihood the program is working as intended. Clearly the man page does not match the actual behavior as the very first sentence says "...appends their contents to the PATH...". The man page says nothing at all about the sequence the directories appear being changed. And while the man page goes on to explain that the "default PATH ... values are obtained from /etc/paths..." that is misleading. The use of the word "default" implies to me that if the current PATH already contains those directories the existing PATH will be used as is. Yet I think we can all agree that the man page is crap and the design of path_helper is crap :-) -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PSA: Mac OS X El Capitan upgrade might break your $PATH 2015-07-31 18:53 ` Mikael Magnusson 2015-07-31 21:05 ` Andrew Janke @ 2015-07-31 22:10 ` Kurtis Rader 1 sibling, 0 replies; 8+ messages in thread From: Kurtis Rader @ 2015-07-31 22:10 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Zsh Users [-- Attachment #1: Type: text/plain, Size: 1481 bytes --] On Fri, Jul 31, 2015 at 11:53 AM, Mikael Magnusson <mikachu@gmail.com> wrote: > That's good news, they used to have that code in /etc/zshenv which > meant you had _no_ way to override it. It only took them a few years > to fix this. > > As a sidenote, it's not a great idea to set your path in .zshenv, you > should probably move those settings to your .zprofile. (Otherwise, > running a script that uses zsh will not use the $PATH from the > environment, which can break things in some situations). > It's a trade-off. Back when ksh93 was my primary shell I had a ~/.environ file where I put such things. Then I sourced that from ~/.profile and my crontab entries. That way my cron jobs would have an environment consistent with my interactive shells. Zsh's .zshenv makes things much easier. It also means that when I do something like ssh home "some_command" that command gets the same environment it would have if I had gotten an interactive shell and run the command. I protect against the problem you mention by checking if PATH contains $HOME/bin. If it does I assume it's already been initialized to a reasonable value and leave it alone. If not I install my own PATH. Of course this is only a problem if you shadow commands -- something most people don't do. In my case I have wrappers around things like ssh in my ~/bin directory that I want to have precedence over the system supplied version. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-07-31 22:49 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-07-31 16:35 PSA: Mac OS X El Capitan upgrade might break your $PATH Kurtis Rader 2015-07-31 17:22 ` Bart Schaefer 2015-07-31 18:53 ` Mikael Magnusson 2015-07-31 21:05 ` Andrew Janke 2015-07-31 22:01 ` Kurtis Rader 2015-07-31 22:29 ` Andrew Janke 2015-07-31 22:49 ` Kurtis Rader 2015-07-31 22:10 ` Kurtis Rader
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).