ssh host echo bla | echo bla

[Michael Tokarev]

Nicolas Williams wrote:
> 
[]
> > connection attempt if e.g. stdout is closed.  That to say -- I think that
> > ssh should "reinvent" the -1 behaviour (correct from my view) to -2 variant
> > (i.e. do what it was asked for and print any error message), but NOT the
> > reverse.
> 
> Why not? I think exiting when stdout or stderr are broken is fine, as
> long as it's documented. :)

Because it is (sometimes) legal action to do -- to run ssh w/o stdout, that
is.  If ssh is transparent (i.e. it runs commands on the remote just like
if them are running on a local box), then let it be transparent.  If it is
ok to say "echo foo | echo bar" on a local box (while stupid), it should be
the same with ssh (and with the error messages and exit codes).  Remote
command may not produce anyhing -- and not having a valid stdout isn't a
reason to skip running it at all.

BTW, on linux even,

  cat /dev/zero | true

will NOT produce any error message, but

 (cat /dev/zero; echo $?) | true

also NOT prints anything -- subshell in () was killed by SIGPIPE
(if memory serves me correctly, the same will print something
sensitive/useful on solaris).  But if the same will be called from
a e.g. perl program with proper redirections, perl will be able to
detect that first process killed (by SIGPIPE) and not exited normally.

> Deadlocking is not.

Yes, obviously.

Regards,
 Michael.