I wonder why some similar bash commands behave the way they do.
I have a bash script
#!/usr/bin/env bash while true do echo "reading" read data echo $data echo "stderr msg" >&2 sleep 1 done
It's an infinite loop which reads one line at a time from stdin and outputs that same line. I also have a bash script
#!/usr/bin/env bash ./foo &
The following commands were run in
bash (v. 4.4.19) in a terminal on Ubuntu 18.04 (let's assume the scripts reside in the working directory):
Stops when it tries to read from stdin, in accordance with this answer.
Killed when controlling terminal is killed, as expected.
Appears to be automagically continuously fed with new input from stdin. Shouldn't it too stop when attempting to read from stdin? Whatever it's getting it doesn't show when echoed, thus I'm guessing it's EOF characters.
Continues running even after the controlling terminal is killed. Looking at the output of
ps, the controlling terminal changes from pts/x to ?. How did this happen without the use of either
nohup? (However, after killing the originally controlling terminal, it yields a "write error: Input/output error" on every write, which I suppose is because its stdout was tied to the now closed terminal. Correct?)
bash -c "./foo &"
Appears to behave exactly like 2).
Appears to behave exactly like 2) and 3).
bash -c "~/foo" (no
&) as a startup application
Behaves similarly to 2), 3) and 4), with the differences:
- Its controlling terminal is the desktop ttyx.
- You can't (can you?) kill its controlling terminal.
None of those differences seem odd to me, just the fact that it's continuously fed with new input.
My guess is that 2) - 5) all use a subshell of sorts whose stdin is redirected to something like
/dev/null, though I'm very unsure and seek a more exact answer.