On Wed, Sep 17, 2025 at 19:16:21 +0700, Robert Elz wrote: > 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.
Here's what I get, running the code in question from bash: hobbit:~$ ./test1 & wait [1] 1348820 RUNNING. [1]+ Stopped ./test1 bash: wait: warning: job 1[1348820] stopped hobbit:~$ hobbit:~$ jobs [1]+ Stopped ./test1 *snip* > 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.) What I find most interesting here is that adding -d "" to the read options changes the behavior so dramatically. Whether that's a bug or not, it's certainly surprising (to me). I get the same result if I use -d "q", so it's not the NUL byte that's special here. Apparently it's changing the delimiter to anything other than newline that triggers the change. I'm not sure exactly what bash is doing here, but I'm guessing it has something to do with switching the terminal from canonical mode to raw mode...? The implication being that if the read delimiter is a newline, you can do normal line editing stuff like backspacing, but if the delimiter is anything else, then the backspace (etc.) becomes a raw input byte. (In fact, I can confirm that this happens with "read -r -d q" in an interactive shell.)
