Date: Wed, 17 Sep 2025 20:04:58 +1000
From: Duncan Roe via Bug reports for the GNU Bourne Again SHell
<[email protected]>
Message-ID: <[email protected]>
| Do you by any chance have job control disabled?
I think a better question would be, which shell is being
used to run ./test0 & wait and ./test1 & wait.
The implication is that it also is bash, but I doubt bash would
act as described. If however it is some other shell (say dash)
then everything would make sense.
For test0. the -t 0 essentially tells the read command to only
do anything if it already has buffered input it can return to
the user - in any other case it will take longer than 0, so it
simply returns a timeout result.
For test1 that doesn't happen, and since the test is running in
the background any attempt to either change the tty setup, or to
read from the controlling terminal (ie: stdin) will cause the
process to stop. But unlike bash, for which the wait command
will detect the stopped process and report it as stopped, other
shells do not do that (and POSIX does not allow that) - wait waits
for the process (all child processes when run with no args) to complete.
Stopped processes never complete, they don't get signals, timers can't
make them work again, only something sending them a SIGCONT.
That is what I suspect is happening, and why the difference between
test0 & test1 - it isn't a bug in the read command, that is acting
exactly as it should (ignoring the later core dump issue that Duncan
found, that is likely to be a bug for Chet to investigate - but it isn't,
directly anyway, related to the issue complained of here.)
You could see this using other commands than read, try (not using bash
as the current shell)
stty -echo & wait
you're likely to get the exact same behaviour, stty will attempt to change
the tty settings, as it is not the foreground job, it will stop, and from
any shell that implements wait as POSIX says should be done, that wait will
just wait for the stty to complete, which won't happen until something else
makes it continue.
If these tests were to be run from a script, as in
#! /bin/sh
./test0 & wait
./test1 & wait
it will almost certainly all work. No job control involved there,
and the background job will then be run with /dev/null as stdin.
Or if the
./test0 & wait
were written in the more normal way
./test0
(also for test1) then there would also be no problem, as in that
case the command is foreground, and is permitted to alter tty settings
and read from stdin.
Other than whatever logic error caused that core dump, there is no bug
here (unless one counts bash not doing as posix expects for its wait
command as a bug.)
kre
