OK! Probiere es aus!
Gestern abend fiel mir übrigens noch etwas ein, was man immer wissen sollte, wenn man mit rsh arbeitet. Ich habe damit auch einmal gekämpft und dann festgestellt, dass ich die man-page bis zum Ende hätte durchlesen sollen. Es gibt nämlich einen "Bug" in rsh, der aus der Historie heraus in fast alle *ix-Systeme mitgenommen wurde. man rsh sagt deswegen auf Solaris:
Gestern abend fiel mir übrigens noch etwas ein, was man immer wissen sollte, wenn man mit rsh arbeitet. Ich habe damit auch einmal gekämpft und dann festgestellt, dass ich die man-page bis zum Ende hätte durchlesen sollen. Es gibt nämlich einen "Bug" in rsh, der aus der Historie heraus in fast alle *ix-Systeme mitgenommen wurde. man rsh sagt deswegen auf Solaris:
Auf Linux liest sich das ähnlich.Sometimes the -n option is needed for reasons that are less
than obvious. For example, the command:
example% rsh somehost dd if=/dev/nrmt0 bs=20b | tar xvpBf -
puts your shell into a strange state. Evidently, the tar
process terminates before the rsh process. The rsh command
then tries to write into the ``broken pipe'' and, instead of
terminating neatly, proceeds to compete with your shell for
its standard input. Invoking rsh with the -n option avoids
such incidents.
This bug occurs only when rsh is at the beginning of a pipe-
line and is not reading standard input. Do not use the -n
option if rsh actually needs to read standard input. For
example:
example% tar cf - . | rsh sundial dd of=/dev/rmt0 obs=20b
does not produce the bug. If you were to use the -n option
in a case like this, rsh would incorrectly read from
/dev/null instead of from the pipe.