Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #263778 > unrolled thread

bash vs. dash and stdin

Started byMax Nikulin <manikulin@gmail.com>
First post2023-11-22 13:10 +0100
Last post2023-11-22 13:20 +0100
Articles 4 — 3 participants

Back to article view | Back to linux.debian.user


Contents

  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

#263778 — bash vs. dash and stdin

FromMax Nikulin <manikulin@gmail.com>
Date2023-11-22 13:10 +0100
Subjectbash 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]


#263779

FromGreg Wooledge <greg@wooledge.org>
Date2023-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]


#263792

FromMax Nikulin <manikulin@gmail.com>
Date2023-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]


#263780

FromNicolas George <george@nsup.org>
Date2023-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