because /bin/sh needs a different syntax than ksh (and bash, etc).
Use a more obvious and less error prone method. (This complicated
use of ${:+} was only used to build the su command when running as
a separate user, but could always cause problems.)
Problem noted by Hubert Feyrer in conjunction with /etc/rc.d/sshd.
argument prefrobbing, in particular, it computes max(addr, __minbrk)
and uses that. The code is like this even in the ancient libc/i386 tree,
back to the earliest rev 1.2. I did not see it Lite 1, but I'm not totally
sure what the random site I found was serving up.
*
* However, I do know that it should use jb and not jl.
*
flag.
EMUL_BSD_ASYNCIO_PIPE notes that the emulated binaries expect the original
BSD pipe behavior for asynchronous I/O, which is to fire SIGIO on read() and
write(). OSes without this flag do not expect any SIGIO to be fired on
read() and write() for pipes, even when async I/O was requested. As far as
we know, the OSes that need EMUL_BSD_ASYNCIO_PIPE are NetBSD, OSF/1 and
Darwin.
EMUL_BSD_ASYNCIO_PIPE notes that the emulated binaries expect the original
BSD pipe behavior for asynchronous I/O, which is to fire SIGIO on read() and
write(). OSes without this flag do not expect any SIGIO to be fired on
read() and write() for pipes, even when async I/O was requested. As far as
we know, the OSes that need EMUL_BSD_ASYNCIO_PIPE are NetBSD, OSF/1 and
Darwin.
EMUL_NO_SIGIO_ON_READ notes that the emulated binaries that requested
asynchrnous I/O expect the reader process to be notified by a SIGIO, but
not the writer process. OSes without this flag expect the reader and the
writer to be notified when some data has arrived or when some data have been
read. As far as we know, the OSes that need EMUL_NO_SIGIO_ON_READ are Linux
and SunOS.
lukem