Re: bin/53548 (here document of /bin/sh of today is broken)

[kre%NetBSD.org@localhost]

Synopsis: here document of /bin/sh of today is broken

State-Changed-From-To: open->analyzed
State-Changed-By: kre%NetBSD.org@localhost
State-Changed-When: Sat, 25 Aug 2018 02:17:28 +0000
State-Changed-Why:
Fix is coming.   I am not sure the here doc part is relevant
(it might be needed to set up the circumstances to trigger the
bug, at least in this case, I am not sure).

The actual problem is related to the short circuit shell
execution in a child shell that has vforked().   In most cases
after a vfork() the shell simply exec's something and then
the exit status of "something" becomes the exit status of
that child.  Or the exec fails, and the shell exits with an
internal shell generated exit status (usually 126 or 127).
Those are all handled.   But it is also possible that the
vfork'd shell can run other commands and wait for them and
should return the exit status from the last of those.  If
all that completes normally, it does - but when the shell
short circuits execution because it knows it has nothing
left to do, it was ignoring that exit status.

Previously (until last weekend's changes) we did none of that,
so the issue did not arise.

The FreeBSD shell, from which I copied these recent changes
(mostly) is less agressive with vfork() than we are, and only
do it when all that can possibly happen is exec() - further
they have abandoned the shell optomisation (from 7th edition
times) where if an exec() fails with ENOEXEC (exec of a file
that does not contain a binary image - and these days a #!
script counts as a binary image) the shell simply forks, resets
itself, and interprets the file as a script.  Instead of that
they simply pretend that instead of the command given having
been
	commandfile arg1 arg2 ...
it was instead
	/bin/sh commandfile arg1 arg2 ...
and exec /bin/sh to run it.   That means that after a vfork()
they always exec something (or fail with a shell error).

The fix is fairly simple, and I am testing it now.   Meanwhile
it is possible to work around the problem by simply disabling
vfork (which can be done with the -F option to sh, or "set -F"
in the script.)

kre