Bash incorrectly identifies pipes as network connections on Darwin.

[Sune Foldager]

Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: darwin7.0
Compiler: gcc
Compilation CFLAGS: -arch i386 -arch ppc -g -Os -pipe -no-cpp-precomp 
-arch i386 -arch ppc -pipe  -DPROGRAM='bash' 
-DCONF_HOSTTYPE='powerpc$uname output: Darwin alcar.cyanite.org 7.7.0 
Darwin Kernel Version 7.7.0: Sun Nov  7 16:06:51 PST 2004; 
root:xnu/xnu-517.9.5.obj~1/RELEASE_$Machine Type: 
powerpc-apple-darwin7.0

Bash Version: 2.05b
Patch Level: 0
Release Status: release

Description:
	The bug persists in bash 3 as well. I don't know if it exists on other 
kernels (e.g. Linux). When starting bash from within another program 
(using exec or similar) where stdin/out stem from a call to pipe(), 
bash will incorrectly think it has been started over ssh/rsh, and thus 
not setup the correct environment. The problem is in the isnetconn 
function in the lib/sh/netconn.c file. On Darwin (at least) it uses 
getpeername to check if it's a socket, and bash concludes it is NOT a 
socket if it returns EINVAL or ENOTSOCK. But on Darwin the return error 
is ENOTCONN instead, for pipe()'s.

Repeat-By:
	We spotted the problem when a Mac OS editor launched scripts using 
bash. It didn't work right, but when the editor itself has been started 
from a shell, it did. This turns out to be because of the other check 
bash makes in shell.c for shell_level < 2. When the editor was started 
from a shell, SHLVL would already be increased once. To repeat, launch 
bash from a program with stdin/out set to the fds created by pipe().

Fix:
	I have attached a patch to lib/sh/netconn.c which basically adds a 
comment about Darwin, and a check for ENOTCONN along with the others.

Sincerly,

--
Sune Foldager.
:: http://cyanite.org

bash-isnetconn.patch
Description: Binary data