Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #263778 > unrolled thread
| Started by | Max Nikulin <manikulin@gmail.com> |
|---|---|
| First post | 2023-11-22 13:10 +0100 |
| Last post | 2023-11-22 13:20 +0100 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.debian.user
bash vs. dash and stdin Max Nikulin <manikulin@gmail.com> - 2023-11-22 13:10 +0100
Re: bash vs. dash and stdin Greg Wooledge <greg@wooledge.org> - 2023-11-22 13:20 +0100
Re: bash vs. dash and stdin Max Nikulin <manikulin@gmail.com> - 2023-11-23 12:10 +0100
Re: bash vs. dash and stdin Nicolas George <george@nsup.org> - 2023-11-22 13:20 +0100
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-11-22 13:10 +0100 |
| Subject | bash vs. dash and stdin |
| Message-ID | <HCUdk-7des-11@gated-at.bofh.it> |
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.
[toc] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-11-22 13:20 +0100 |
| Message-ID | <HCUmZ-7dhz-5@gated-at.bofh.it> |
| In reply to | #263778 |
On Wed, Nov 22, 2023 at 07:06:58PM +0700, Max Nikulin wrote: > 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 You're trying to use stdin twice at the same time. You've got bash reading stdin to fetch commands, and you've got ssh reading stdin because that's just what ssh does. This is like <https://mywiki.wooledge.org/BashFAQ/089>. ssh grabs all of the stdin (until EOF) and leaves none for bash. > One might expect to see "local" as well. > > dash <ssh.sh > remote > local I don't know dash's internals. Maybe dash reads an entire buffer's worth of stdin at a time, instead of a command at a time as bash does. > If the script is passed as an argument, not to stdin, then output contains > "local" in both cases. Yes. In that case, bash is not competing with ssh for stdin.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-11-23 12:10 +0100 |
| Message-ID | <HDfKO-7v51-15@gated-at.bofh.it> |
| In reply to | #263779 |
On 22/11/2023 19:17, Greg Wooledge wrote: > On Wed, Nov 22, 2023 at 07:06:58PM +0700, Max Nikulin wrote: >> >> ssh localhost echo remote >> echo local > > This is like <https://mywiki.wooledge.org/BashFAQ/089>. ssh grabs > all of the stdin (until EOF) and leaves none for bash. Thanks. I expected to find it among pitfalls. > I don't know dash's internals. Maybe dash reads an entire buffer's > worth of stdin at a time, instead of a command at a time as bash does. It seems dash reads a block from stdin (and does not lseek back even for regular files) only for commands. I do not see significant difference when commands reading stdin are placed into a script cmd='seq 1000000 | while read -r var ; do printf "%s\n" "$var" ; ssh localhost echo remote ; done' bash -c "$cmd" dash -c "$cmd" >> If the script is passed as an argument, not to stdin, then output contains >> "local" in both cases. > > Yes. In that case, bash is not competing with ssh for stdin. I have found an attempt to report it: https://lore.kernel.org/dash/6640a8ee-eda0-1e35-df1a-c8b303440ca1@mail.de/ stdin should be consumed line by line. Fri, 22 Oct 2021 13:11:43 +0200 No response.
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2023-11-22 13:20 +0100 |
| Message-ID | <HCUmZ-7dhz-7@gated-at.bofh.it> |
| In reply to | #263778 |
Max Nikulin (12023-11-22): > Is there a document that describes shell behavior in respect to stdin in > such cases? The shell did not eat your stdin here, ssh did. Regards, -- Nicolas George
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web