Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Yosemite breaks bash

My login shell is /bin/zsh. I found that under Yosemite, /bin/sh starts up with a default path, rather than inheriting the PATH environment. This breaks "make" (among others) as it doesn't find the programs it needs (such as latex in my case).


The bizarre fact is that once a PATH environment is explicitly set in bash, any child shell will inherit it, whether invoked directly from the shell with the manually fixed path or indirectly. I compared the environments of such a child shell with the parent and couldn't spot any difference.


The bug is probably not in bash itself, but in the exec() system call: It occurred on two versions of bash (the default 3.2.53(1) as well as the latest I upgraded to, 3.2.57(1)). I also installed 3.2.57(1) on my other machine (still running Mavericks) and it works fine.


A temporary workaround is:

- in the terminal window I'm using to run "make", which runs /bin/zsh, explicitly invoke /bin/sh

- enter "export PATH=..." in that 2nd-level /bin/sh

- inside that bash, start another zsh

- in that zsh everything works fine, including make

MacBook Air (11-inch Mid 2013), OS X Yosemite (10.10)

Posted on Oct 23, 2014 3:58 PM

Reply
8 replies

Oct 24, 2014 9:03 AM in response to microkerneldude

Slightly easier workaround:

- create ~/.bashrc, containing the "export PATH=..."

- in zsh, run /bin/bash, inside that one run another zsh

Things work normally then

This doesn't make sense as /etc/zshenv is run for all instances of zsh. Thus, the PATH set by BASH would be replaced by the PATH set by/etc/zshenv in the last instance of zsh.

Oct 24, 2014 6:25 PM in response to microkerneldude

microkerneldude wrote:


That would be another workaround, but setting the path in .zshenv affects every invocation of zsh, prevents it from inheriting a PATH and thus a bad idea, likely to break other stuff.

Not a work around but how it should be done. And have no idea what you would think adding to the PATH environment variable would somehow prevent it from keeping what was et previously.


Not sure what your background is but there seems to be a misunderstanding of how this is handled especially in OS X.


Good luck


regards


BTW the title of this thread is incorrect . Yosemite did not break bash.

Oct 24, 2014 6:55 PM in response to Frank Caggiano

Hey Frank,


I've been a Unix user for 30 years, and have a fair bit of experience with shell programming. (I'm also teaching operating systems.)

Yes, you can conditionally set paths on .rc files, but it's not the proper thing to do in system-wide rc files. This would be considered a hack.


The fundamental problem is what I described in the original posting: bash unconditionally reverts to a default path when it's invoked as a non-login shell, something I have never seen on any Unix or Linux system, including all previous versions of Mac OS X. The identical version of bash works as expected on Mavericks. All the relevant initialisation and rc files in /etc are identical on my Mavericks and Yosemite box (as are my personal init files).

Yosemite breaks bash

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.