shaw@paralogics.UUCP (Guy Shaw) (12/06/89)
Rsh does not seem to pass back the return code from the command executed on another machine. I tried this little shell script: #! /bin/sh NEIGHBOR=<some other machine on the local network> rsh $NEIGHBOR /bin/false echo "'rsh $NEIGHBOR /bin/false' => $?" exit 0 It confirms my suspicion that no matter what happens on the remote machine, rsh succeeds. The only non-zero return codes that come from rsh are for things that can go wrong before the remote command is executed, such as invalid hostname. It seems to be pretty common practice to do things like tape backups with commands like: rsh tapeless /usr/etc/dump ... | dd of=/dev/localtape ... and just hope that nothing goes wrong with the dump. Ugh! I often have the situation where a diskless workstation wants to do a grep or a sort or some such command where at least the input and possibly both input and output are files residing on a fileserver. Especially in the case of selection commands, it would be a lot cheaper to run the command on the fileserver, rather than ship the program over via NFS, then read the entire file via NFS, only to select out most of the lines. I would do this using rsh, except that rsh ignores error return codes. Either some other method must be used to determine the success or failure of work assigned to another machine, or I need to get a version of rsh or something similar that passes back the remote machine's return code. Before I spend time rolling my own reliable rsh equivalent, I would like to know if this has already been done. You need not bother telling me about special arrangements made between clients and servers that know about each other, such as client/server model database products; I am aware of their existence and assume that they have solved the problem for themselves. But, what about the good old Unix(TM)-philosophy tool-building approach? You know, small general tools that do one job well, and all that. Replies to the effect that ignoring return codes is also part of the Unix philosophy will be noted and filed in this big archive I have for information that may contain some truth but but serves no constructive purpose. I have RTFM, but I would be most happy if someone wants to tell me how dense I am and point out the method that is already in there. Thanks in advance -- -- Guy Shaw Paralogics paralogics!shaw@uunet.uu.net or uunet!paralogics!shaw
gaynor@busboys.rutgers.edu (Silver) (12/06/89)
shaw@paralogics.uucp writes: > [rsh's return code is simply indicates whether a connection could be > established or not?!] As far as I can tell, you are essentially correct. Tremendous pain in the ass. You really have to bend over backwards to get the return value - perhaps put it on the last line of stdout or stderr, and take it from there locally. Regards, [Ag]
parker@zaphod.mpr.ca (Ross Parker) (12/07/89)
> It seems to be pretty common practice to do things like tape backups with > > rsh tapeless /usr/etc/dump ... | dd of=/dev/localtape ... > > and just hope that nothing goes wrong with the dump. Ugh! > If anyone is interested in this specific application (running remote dumps remotely), I have a a program (rrdump) and associated daemon (rrdumpd) that will accomplish this. I can package it up and either post it or mail it to those that are interested. Disclaimer... it has been tested only on Ultrix and Sun systems. Ross Parker parker@mpre.mpr.ca (604)293-5495 uunet!ubc-cs!mpre!parker