From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: bash source code block: problem after ssh commands
Date: Sat, 29 Jun 2024 22:40:41 +0700 [thread overview]
Message-ID: <v5p9tq$okf$1@ciao.gmane.io> (raw)
In-Reply-To: <uj9r7d$a2b$1@ciao.gmane.io>
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.
next prev parent reply other threads:[~2024-06-29 15:41 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 11:17 bash source code block: problem after ssh commands Alain.Cochard
2023-10-25 15:12 ` Leo Butler
2023-10-25 16:14 ` Alain.Cochard
2023-10-25 16:47 ` Leo Butler
2023-10-25 16:59 ` yaxp
2023-10-26 8:44 ` Ihor Radchenko
2023-10-26 13:23 ` Alain.Cochard
2023-10-26 13:44 ` Ihor Radchenko
2023-10-27 18:26 ` Alain.Cochard
2023-10-28 5:22 ` Max Nikulin
2023-10-30 10:50 ` Bruno Barbier
2023-11-06 13:32 ` Ihor Radchenko
2023-11-06 18:25 ` Matt
2023-11-07 8:55 ` Ihor Radchenko
2023-11-08 19:41 ` Matt
2023-11-09 12:14 ` Ihor Radchenko
2023-11-09 17:48 ` Matt
2023-11-15 16:32 ` Matt
2023-11-15 18:04 ` Matt
2023-11-16 9:32 ` Ihor Radchenko
2023-11-16 19:03 ` Matt
2023-11-16 19:46 ` Alain.Cochard
2023-11-16 20:54 ` Matt
2023-11-17 9:22 ` Ihor Radchenko
2023-11-17 9:55 ` Alain.Cochard
2023-11-17 10:17 ` Ihor Radchenko
2023-11-17 15:32 ` Leo Butler
2023-11-17 15:47 ` Bruno Barbier
2023-11-18 10:37 ` Ihor Radchenko
2023-11-21 19:01 ` Bruno Barbier
2023-11-22 17:06 ` Max Nikulin
2023-11-19 4:17 ` Non-emacs shell (Re: bash source code block: problem after ssh commands) Max Nikulin
2023-11-21 15:33 ` Bruno Barbier
2023-11-18 8:04 ` bash source code block: problem after ssh commands Max Nikulin
2023-11-18 10:43 ` Ihor Radchenko
2023-11-18 16:18 ` Max Nikulin
2024-06-29 15:40 ` Max Nikulin [this message]
2023-11-17 22:07 ` Matt
2023-11-18 3:11 ` Forget about "bash -c bash file.sh" (Re: bash source code block: problem after ssh commands) Max Nikulin
2023-11-18 8:11 ` Matt
2023-11-18 8:29 ` Bruno Barbier
2023-11-18 8:43 ` Matt
2023-11-18 8:54 ` Bruno Barbier
2023-11-18 9:09 ` Matt
2023-11-18 9:11 ` Bruno Barbier
2023-11-18 10:47 ` Ihor Radchenko
2023-11-18 8:19 ` bash source code block: problem after ssh commands Bruno Barbier
2023-11-18 9:02 ` Matt
2023-11-18 15:51 ` Matt
2024-06-30 8:57 ` Max Nikulin
2024-06-30 11:06 ` Ihor Radchenko
2024-06-30 15:19 ` Max Nikulin
2024-06-30 15:28 ` Ihor Radchenko
2024-06-30 15:48 ` Max Nikulin
2024-06-30 16:42 ` Ihor Radchenko
2024-07-01 9:41 ` Max Nikulin
2024-07-01 9:51 ` Ihor Radchenko
2024-07-01 10:54 ` Max Nikulin
2024-07-01 16:01 ` Ihor Radchenko
2024-07-03 11:06 ` Max Nikulin
2024-07-03 12:33 ` Ihor Radchenko
2023-10-26 14:44 ` Russell Adams
2023-10-27 11:47 ` Alain.Cochard
2023-11-06 18:01 ` Matt
2023-11-07 0:51 ` Alain.Cochard
2023-11-18 8:09 ` Max Nikulin
2023-11-18 8:36 ` Bruno Barbier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='v5p9tq$okf$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).