Hi SSH, I have put the ssh command in `script.sh`, with the code: ~~~ #!/usr/bin/env bash ssh -q server date ~~~ And I have one `main.sh` to call `script.sh` as below. ~~~ #!/usr/bin/env bash # vim: set noexpandtab tabstop=2: while read -r run do ./script.sh done < <(seq 10) ~~~ The `script.sh` can be called only once, say ~~~ $ ./main.sh Tue Oct 18 12:26:05 CDT 2016 ~~~ But 10 runs are expected. If I modify the stdin when calling, like `main1.sh` as below. ~~~ #!/usr/bin/env bash # vim: set noexpandtab tabstop=2: while read -r run do ./script.sh < /dev/null done < <(seq 10) ~~~ It will return the right 10 calling. ~~~ $ ./main1.sh Tue Oct 18 12:28:24 CDT 2016 Tue Oct 18 12:28:24 CDT 2016 Tue Oct 18 12:28:25 CDT 2016 Tue Oct 18 12:28:25 CDT 2016 Tue Oct 18 12:28:26 CDT 2016 Tue Oct 18 12:28:26 CDT 2016 Tue Oct 18 12:28:27 CDT 2016 Tue Oct 18 12:28:27 CDT 2016 Tue Oct 18 12:28:28 CDT 2016 Tue Oct 18 12:28:29 CDT 2016 ~~~ Could you tell me why `stdin` needs to be overwritten in SSH? Thanks. My machine info is as below. ~~~ $ bash --version GNU bash, version 4.3.42(1)-release (x86_64-apple-darwin15.0.0) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ ssh -V OpenSSH_6.9p1, LibreSSL 2.1.8 ~~~ Best regards, Jin
On Tue, Oct 18, 2016 at 10:34 AM, Jin Li <lijin.abc at gmail.com> wrote:> Could you tell me why `stdin` needs to be overwritten in SSH? Thanks.Consider this (almost) equivalent simplified script: while read -r run do ssh localhost date done < <(seq 10) What's happening is that the remaining 9 lines are being read by ssh and sent to the remote server where the "date" command ignores them and they are discarded (but ssh doesn't know that the remote "date" is going to do that). If you replace the "date" with "cat" you can see this: $ cat t while read -r run do cat done < <(seq 10) $ bash t 2 3 4 5 6 7 8 9 10 This doesn't happen with a local "date" command because it never reads its stdin. When you redirect ssh's stdin to /dev/null the ssh no longer consumes the output from "seq". ssh also has a "-n" option that does this. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Hi Darren, I got it. Many thanks for your excellent explanations. Best regards, Jin On Tue, Oct 18, 2016 at 2:04 PM, Darren Tucker <dtucker at zip.com.au> wrote:> On Tue, Oct 18, 2016 at 10:34 AM, Jin Li <lijin.abc at gmail.com> wrote: >> Could you tell me why `stdin` needs to be overwritten in SSH? Thanks. > > Consider this (almost) equivalent simplified script: > > while read -r run > do > ssh localhost date > done < <(seq 10) > > What's happening is that the remaining 9 lines are being read by ssh > and sent to the remote server where the "date" command ignores them > and they are discarded (but ssh doesn't know that the remote "date" is > going to do that). If you replace the "date" with "cat" you can see > this: > > $ cat t > while read -r run > do > cat > done < <(seq 10) > > $ bash t > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > 10 > > This doesn't happen with a local "date" command because it never reads > its stdin. > > When you redirect ssh's stdin to /dev/null the ssh no longer consumes > the output from "seq". ssh also has a "-n" option that does this. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement.