Re: bash source code block: problem after ssh commands

[Max Nikulin <manikulin@gmail.com>]

On 18/11/2023 15:04, Max Nikulin wrote:
> On 17/11/2023 17:17, Ihor Radchenko wrote:
> 
> 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).

I expect the following couple of lines simulates ssh behavior fairly 
well (besides maybe macOS with its old GPLv2 bash).

bash -c 'read -t 0.5 -r line; printf "read: %s\n" "$line"'
printf 'printf\n'

> cat ssh-script.sh
> ssh -p 2222 127.0.0.1 'echo foo>/tmp/foo'
> echo done
[...]
> dash <ssh-script.sh
> done
> 
> bash <ssh-script.sh
> # no output
> 
> I have not expected this difference.
[...]
> I am unsure if POSIX specifies exact behavior of shell when commands are 
> read from stdin.

It is a bug in dash that should be fixed in next version. Behavior of 
bash is correct despite some users may expect "done" printed.

<https://lore.kernel.org/dash/20221213221732.6mvv22u7ktdozrbx@tarta.nabijaczleweli.xyz/t/>
наб <nabijaczleweli@nabijaczleweli.xyz> to dash@vger.kernel.org
[PATCH] input: preadfd: read standard input byte-wise
Tue, 13 Dec 2022 23:17:32 +0100

<https://bugs.debian.org/862907>
"dash: Incorrectly slurps script from stdin (POSIX compliance issue)"

And curiously ssh command was involved as well
<https://michael-prokop.at/blog/2017/05/18/debugging-a-mystery-ssh-causing-strange-exit-codes/>
"Debugging a mystery: ssh causing strange exit codes?"

A citation from POSIX (XCU):

<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_06>
STDIN in /sh - shell, the standard command language interpreter/
> When the shell is using standard input and it invokes a command that
> also uses standard input, the shell shall ensure that the standard
> input file pointer points directly after the command it has read when
> the command begins execution. It shall not read ahead in such a manner
> that any characters intended to be read by the invoked command are
> consumed by the shell (whether interpreted by the shell or not) or
> that characters that are not read by the invoked command are not seen
> by the shell. When the command expecting to read standard input is
> started asynchronously by an interactive shell, it is unspecified
> whether characters are read by the command or interpreted by the
> shell.

I do not think any script should rely on this behavior, it is better to 
explicitly use "here documents"

cat <<EOF
$PATH
EOF

or to prevent various kinds of expansion

cat <<"EOF"
$PATH
EOF

Just a reminder: reading from stdin in shell scripts may interfere with 
various commands

<https://mywiki.wooledge.org/BashFAQ/089>
"I'm reading a file line by line and running ssh or ffmpeg, only the 
first line gets processed!"

So either "ssh -n" or "ssh </dev/null" should be used to avoid the pitfall.

I agree with Ihor that ob-shell should not feed scripts to shell stdin 
(maybe besides the case when it is explicitly requested by the user 
through some header arguments).

It seems, shell sessions
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67259>
is a different case unrelated to script files.