I was working with a command like this:
ssh another_host <<EOF
set -x
command_a
command_b
run_framework
command_c
...
EOF
The odd thing was that only commands up to and including run_framework were echoed by -x. And appeared that command_c and onwards were not executed at all. Initially, I suspected set -e was in effect, and the run_framework command failed; but that wasn’t the case.
From searching around, my conjecture was this: the run_framework command was somehow munching the stdin, and thus, when the shell gets around to execute the following commands, the stdin was exhausted, so doesn’t run anything beyond that. To test this, I rewrote the framework command above as:
(: | run_framework)
And then it started working as I expected. I.e., I now see command_c and beyond are executed.
The said framework is a ton of Python scripts, so I couldn’t pin down what exactly was munching the stdin.
Is this an anti-pattern with ssh, to execute commands like this? To be safe, shouldn’t one run every such command in isolation in order to prevent the ill-effects of accidental stdin munching?
For some non-ssh scenario:
$ cat script
echo only this line is executed
./runs_head
echo not executed
echo not executed either
$ cat runs_head
head -n1 > /dev/null
Interestingly, there’s a difference between:
$ cat script | bash
only this line is executed
And
$ bash < script
only this line is executed
not executed either
But I wonder why there’s a difference. Can anyone explain?