Re: Script ends prematurely when fed into bash's stdin

[Bob Proulx]

Thank you for your report.  But I do not believe what you are seeing
is a bug in bash.  This looks like normal 'ssh' (and 'rsh') behavior to me.

nick@zk3.dec.com wrote:
>         Consider a script that invokes ssh to execute a remote command
>         (I've set up public key authentication, so no passwords are needed):
> 
>                  ssh remote date
>                  date
>                  ssh remote date
>                  date
>                  exit 0

Sounds good.  A nice simple test case.

>         If I invoke bash and give it the script filename as argument,
>         it works fine.

In this case the stdin is your terminal.  Since you never send it any
data the read does not read anything.

>         But if I pipe the script file into bash or
>         redirect bash's stdin so that it comes from the script file,
>         bash quits immediately after the (first) ssh command is finished.

The problem is that the first ssh command is reading stdin and reads
up and gobbles up all of the other commands coming into stdin.  The
shell never gets a chance to read that later input.  The first ssh
eats the input and rest of the script is never seen.  As your strace
shows the shell got EOF.  I assume the strace shows the ssh has read
the other lines from stdin.

This has actually been a common problem reported with rsh in the past
too.  Since ssh is functionally based on rsh it has the same behavior.
There is no other way because ssh/rsh need to pass on any stdin to the
remote shell.

  echo echo hello | ssh remote sh

>         stracing the bash invocation shows that bash gets an EOF on
>         the read after the ssh command is done. Although ssh is
>         essential to this behavior, I cannot see how ssh could fiddle
>         with bash's stdin, so I decided to submit is as a bash bug -
>         but I may be wrong.

I remember this as one of those rsh gotchas from well before the
current ssh incarnation.  It is not a shell bug.  It is just a
behavior of ssh/rsh.

>         My current workaround is to redirect ssh's stdin from /dev/null:
> 
>                  ssh remote date </dev/null
>                  date
>                  ssh remote date </dev/null
>                  date
>                  exit 0

That is actually the correct thing to do.  But I prefer to use the -n
option to close stdin.  This is what you really need to be doing.

    ssh -n remote date
    date
    ssh -n remote date
    date
    exit 0

The classic rsh man page from HP-UX explains things fairly well and
says this:

      man rsh

      By default, rsh reads its standard input and sends it to the remote
      command because rsh has no way to determine whether the remote command
      requires input.  The -n option redirects standard input to rsh from
      /dev/null.  This is useful when running a shell script containing a
      rsh command, since otherwise rsh may use input not intended for it.
      The -n option is also useful when running rsh in the background from a
      job control shell, /usr/bin/csh or /usr/bin/ksh.  Otherwise, rsh stops
      and waits for input from the terminal keyboard for the remote command.
      /usr/bin/sh automatically redirects its input from /dev/null when jobs
      are run in the background.

Hope this helps,
Bob