Re: bash source code block: problem after ssh commands

[Max Nikulin <manikulin@gmail.com>]

On 17/11/2023 17:17, Ihor Radchenko wrote:
> I was only able to reproduce your problem with ssh asking a password.
> We are discussing the reproduced case.

I see bash vs. dash difference with public key authorization, so no need 
for password prompts. I have not figured out how to construct an example 
without ssh since this command *may* read stdin, but does not do it in a 
same way as e.g. cat(1). Perhaps a small program performing single 
non-blocking read will allow it. The following behavior observed for a 
regular shell prompt, Emacs is not involved. Debian 12 bookworm.

cat ssh-script.sh
ssh -p 2222 127.0.0.1 'echo foo>/tmp/foo'
echo done

Read commands from a script file:

dash ssh-script.sh
done

bash ssh-script.sh
done

Read commands from stdin

dash <ssh-script.sh
done

bash <ssh-script.sh
# no output

I have not expected this difference.

dash reads a block from stdin (whole file in this case) and interprets 
commands.

BASH reads just the ssh command and executes it. SSH reads "echo done" 
from stdin, so when control is returned to bash, stdin is exhausted and 
no commands remain to execute by BASH. SSH can not "unread" part of 
input not consumed by the remote command despite it might be possible in 
the case of the regular file as stdin.

Actually bash reads the whole script file as well when called as it is 
shown above, but it calls lseek before executing ssh. To make difference 
more apparent (e.g. for strace), force creation of pipe(7) for which 
lseek is not supported

cat ssh-script.sh | strace -o /tmp/bash.strace bash

I am unsure if POSIX specifies exact behavior of shell when commands are 
read from stdin. I think, the suggested earlier "-n" ssh option (or 
</dev/null) should be used to make intentions clear: ssh should not read 
stdin. There is too much room for heuristics: interactive vs. 
non-interactive shell, a terminal vs. a regular file vs. a pipe as 
standard input. Be explicit to get reliable behavior.

ssh -n user@host 'command'

or

tar cvf - . | ssh user@host 'tar xvf -'

without "-n" when ssh needs stdin and it is explicitly specified.

I do not think it is an Org or an Emacs bug. It is rather POSIX vs. bash 
vs. dash issue.