Hi,
There was a thread on stdio buffering and fork a month ago. That time I
thought shells should be rather careful with input/output handling when
spawning subprocesses.
Consider a file (ssh.sh) containing a couple of commands:
ssh localhost echo remote
echo local
Let's try to run it (assuming key-based authorization)
bash <ssh.sh
remote
One might expect to see "local" as well.
dash <ssh.sh
remote
local
Is there a document that describes shell behavior in respect to stdin in
such cases?
If the script is passed as an argument, not to stdin, then output
contains "local" in both cases. I admit that ssh (called this way) can
not avoid consuming of some stdin, so bash behavior may be considered a
bit more correct despite initial expectations.
If you are going to try strace then, to make difference more prominent,
it is better to force creation of a pipe
cat ssh.sh | strace bash
I am curious if it may be a dash bug or it is just falls into the
category of unspecified behavior.
P.S. I noticed it in a discussion whether a command not executed after
ssh is an Emacs bug. My conclusion is that "ssh -n" should be used in
scripts unless a remote command really needs stdin.
