On Darwin (Mac OS X), bash incorrectly assumed that it has been called over a network connection (such as ssh, rsh etc.), when stdin stems from the pipe() system call. This is because bash's heuristic code for determining if it's been started over a net connection is incorrect on Darwin kernels. The problem is in lib/sh/netconn.h where the call to getpeername returns ENOTCONN instead of ENOTSOCK on Darwin for pipe() created fds. I have (or rather will) attached a patch to fix this, although it should probably also be fixed upstream. I don't know if this problem exists on other systems than Darwin. Reproducible: Always Steps to Reproduce: 1. On Darwin, start bash from a program with stdin/out comming from pipe(). 2. Watch what startup files bash then loads. It will not load .bash_profile or use BASH_ENV. Actual Results: Result is: An incorrect environment for script execution. This is a big problem for programs which rely on bash for external scripting. Expected Results: It should, since it's a non-interactive shell, load whatever is in BASH_ENV.
Created attachment 49217 [details, diff] bash-isnetconn.patch Patch for bash. Apply with patch -p1 <bash-isnetconn.patch inside bash source root. Works with 2.05 and 3.
Created attachment 49220 [details, diff] bash-2.05b-r9.ebuild.patch Ebuild patch to include my isnetconn patch above.
Created attachment 49221 [details, diff] bash-2.05b-r11.ebuild.patch Ebuild patch to include my isnetconn patch above.
Created attachment 49222 [details, diff] bash-3.0-r7.ebuild.patch Ebuild patch to include my isnetconn patch above.
if you havent e-mailed this to the upstream bash maintainer already, please do so now added to bash-3.0-r10
I mailed them (bashbugs or something, from the man page) a long time ago, but I never heard anything from them, not even a confirmation. Maybe I should try submitting it again, hmm.
