Re: && operator prevents backgrounding over ssh
It closes stdin, not stdout or stderr..
On Thu, Sep 26, 2013 at 9:14 PM, Hinrik Örn Sigurðsson wrote:
> On Thu, Sep 26, 2013 at 8:07 PM, Bob Proulx wrote:
> > Just a reminder that ssh reads from stdin unless explicitly told to
> > avoid reading from stdin. If stdin isn't going to be used then the -n
> > option should be used.
> > [...]
> > Regardless of the resolution of the above question about bash the
> > usage of ssh in the above should use 'ssh -n'.
>
> I'm not sure how that is helpful. 'ssh -n' closes stdin prematurely,
> which means that any error from the first command ("cd /tmp") will not
> be propagated to the originating host, e.g. when the directory doesn't
> exist.
>
>
--
--
bill duncan at beachnet
Re: && operator prevents backgrounding over ssh
Hinrik Örn Sigurðsson wrote:
> Bob Proulx wrote:
> > Just a reminder that ssh reads from stdin unless explicitly told to
> > avoid reading from stdin. If stdin isn't going to be used then the -n
> > option should be used.
> > [...]
> > Regardless of the resolution of the above question about bash the
> > usage of ssh in the above should use 'ssh -n'.
>
> I'm not sure how that is helpful. 'ssh -n' closes stdin prematurely,
> which means that any error from the first command ("cd /tmp") will not
> be propagated to the originating host, e.g. when the directory doesn't
> exist.
Any errors would be reported to stderr. Any other output would to to
stdout. Closing stdin has no affect on either stderr or stdout.
In order to connect stdin up to the remote command ssh needs to
actively read any input and then write it off to the remote process
over the socket connection. Here is an illustration of the difference.
$ echo foo | { ssh localhost echo bar ; cat ;}
bar
Where did "foo" go? It was eaten by ssh and then lost when ssh exited.
$ echo foo | { ssh -n localhost echo bar ; cat ;}
bar
foo
There it is. Now with -n ssh did not consume it. That left it for
the next process to consume.
Bob
Re: && operator prevents backgrounding over ssh
On Thu, Sep 26, 2013 at 8:07 PM, Bob Proulx wrote:
> Just a reminder that ssh reads from stdin unless explicitly told to
> avoid reading from stdin. If stdin isn't going to be used then the -n
> option should be used.
> [...]
> Regardless of the resolution of the above question about bash the
> usage of ssh in the above should use 'ssh -n'.
I'm not sure how that is helpful. 'ssh -n' closes stdin prematurely,
which means that any error from the first command ("cd /tmp") will not
be propagated to the originating host, e.g. when the directory doesn't
exist.
Re: && operator prevents backgrounding over ssh
On 9/26/13 11:44 AM, Geir Hauge wrote:
> 2013/9/26 Hinrik Örn Sigurðsson
>
>> The "&&" operator in bash seems to inhibit backgrounding when run over
>> ssh. You can try it with the following:
>>
>> ssh localhost "cd /tmp && nohup sleep 10 >/dev/null 2>&1 &"
>>
>> The above command will wait for sleep(1) to finish before returning.
>> If it is run without ssh, it returns immediately. Furthermore, other
>> shells such as dash and zsh will return immediately regardless of
>> whether ssh is used.
>>
>
> Probably because it's equivalent to
>
> { cd /tmp && nohup sleep 10 >/dev/null 2>&1; } &
This is correct. The shell started in the background to run the compound
command also has to stick around to report the exit status back to its
parent, so it will exit when the sleep exits.
Maybe zsh and dash have optimized this case, since the exit status of
nohup/sleep will be the exit status of the backgrounded shell, but bash
has not.
> so the backgrounded process still have stdout and stderr connected to ssh.
Exactly.
> This should do what you want:
>
> cd /tmp && { nohup sleep 10 >/dev/null 2>&2 & }
This will do the same thing and might be simpler:
cd /tmp && exec nohup sleep 10 >/dev/null 2>&1 &
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: && operator prevents backgrounding over ssh
Hinrik Örn Sigurðsson wrote: > The "&&" operator in bash seems to inhibit backgrounding when run over > ssh. You can try it with the following: > > ssh localhost "cd /tmp && nohup sleep 10 >/dev/null 2>&1 &" Just a reminder that ssh reads from stdin unless explicitly told to avoid reading from stdin. If stdin isn't going to be used then the -n option should be used. -n Redirects stdin from /dev/null (actually, prevents reading from stdin). This must be used when ssh is run in the background. A common trick is to use this to run X11 programs on a remote machine. For example, ssh -n shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, and the X11 connection will be automatically forwarded over an encrypted channel. The ssh program will be put in the background. (This does not work if ssh needs to ask for a password or passphrase; see also the -f option.) Regardless of the resolution of the above question about bash the usage of ssh in the above should use 'ssh -n'. Bob
Re: && operator prevents backgrounding over ssh
On 9/26/13 10:52 AM, Greg Wooledge wrote: > On Thu, Sep 26, 2013 at 06:27:10AM +, Hinrik Örn Sigurðsson wrote: >> The "&&" operator in bash seems to inhibit backgrounding when run over >> ssh. You can try it with the following: >> >> ssh localhost "cd /tmp && nohup sleep 10 >/dev/null 2>&1 &" >> >> The above command will wait for sleep(1) to finish before returning. > > Confirmed on HP-UX 10.20 with bash 4.2.37. Changing && to ; causes > an immediate return. Those two are not equivalent; `&&' and `;' have different precedence. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: && operator prevents backgrounding over ssh
2013/9/26 Hinrik Örn Sigurðsson
> The "&&" operator in bash seems to inhibit backgrounding when run over
> ssh. You can try it with the following:
>
> ssh localhost "cd /tmp && nohup sleep 10 >/dev/null 2>&1 &"
>
> The above command will wait for sleep(1) to finish before returning.
> If it is run without ssh, it returns immediately. Furthermore, other
> shells such as dash and zsh will return immediately regardless of
> whether ssh is used.
>
Probably because it's equivalent to
{ cd /tmp && nohup sleep 10 >/dev/null 2>&1; } &
so the backgrounded process still have stdout and stderr connected to ssh.
This should do what you want:
cd /tmp && { nohup sleep 10 >/dev/null 2>&2 & }
--
Geir Hauge
Re: && operator prevents backgrounding over ssh
On Thu, Sep 26, 2013 at 06:27:10AM +, Hinrik Örn Sigurðsson wrote: > The "&&" operator in bash seems to inhibit backgrounding when run over > ssh. You can try it with the following: > > ssh localhost "cd /tmp && nohup sleep 10 >/dev/null 2>&1 &" > > The above command will wait for sleep(1) to finish before returning. Confirmed on HP-UX 10.20 with bash 4.2.37. Changing && to ; causes an immediate return.
&& operator prevents backgrounding over ssh
The "&&" operator in bash seems to inhibit backgrounding when run over ssh. You can try it with the following: ssh localhost "cd /tmp && nohup sleep 10 >/dev/null 2>&1 &" The above command will wait for sleep(1) to finish before returning. If it is run without ssh, it returns immediately. Furthermore, other shells such as dash and zsh will return immediately regardless of whether ssh is used. A workaround in this case is to use "|| exit 1;" instead of "&&".
