henry@zoo.toronto.edu (Henry Spencer) (10/21/90)
Folks who have sent mail to our comment/complaint/bug mailing address lately and haven't seen a response might want to know :-) that there is a reason: mailer problems on utstat have prevented me from seeing most of the mail. I thought it was kind of quiet. :-) Since I've got a bigger mouth than Geoff and do most of the answering, this explains the lack of responses. The problem is believed to have been cleared up, and fortunately Geoff is one of these odd folks :-) who saves everything, so I've got a great stack of old mail messages to wade through. Stay tuned. -- The type syntax for C is essentially | Henry Spencer at U of Toronto Zoology unparsable. --Rob Pike | henry@zoo.toronto.edu utzoo!henry
geoff@utstat.uucp (Geoff Collyer) (10/21/90)
Henry writes: > mailer problems on utstat have prevented me from seeing most of the mail. To give blame where blame is due, the root problem was that rsh foo "exit 1" (for example) returns an exit status of 0 (at least in both directions between SunOS 3.5 and Irix 3.2). This is a bug, and I intend to take this up with UCB (and find out what POSIX has to say about this nasty behaviour). > Geoff is one of these odd folks :-) who saves everything Actually, I don't save everything, I've just been too busy to answer most of my mail for the last three or four months. :-) -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu
del@thrush.mlb.semi.harris.com (Don Lewis) (10/23/90)
In article <1990Oct21.090928.10961@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes: >Henry writes: >> mailer problems on utstat have prevented me from seeing most of the mail. > >To give blame where blame is due, the root problem was that > > rsh foo "exit 1" > >(for example) returns an exit status of 0 (at least in both directions >between SunOS 3.5 and Irix 3.2). This is a bug, and I intend to take >this up with UCB (and find out what POSIX has to say about this nasty >behaviour). This would take a revision of the rsh protocol, since there is no provision for returning the remote exit status. All that comes back is the stdout and stderr output from the remote command. In the few cases that I have had get the exit status of the remote command, I have added an "echo $status" to the command and captured that in a local shell variable. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
jerry@olivey.olivetti.com (Jerry Aguirre) (10/24/90)
In article <1990Oct21.090928.10961@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes: > rsh foo "exit 1" > >(for example) returns an exit status of 0 (at least in both directions >between SunOS 3.5 and Irix 3.2). This is a bug, and I intend to take I have run into this one before. It was certainly not the behavior I expected. The rsh command returns the exit status of the rsh itself, not the status of the remote command. So if the network or other system is unreachable then the status is usable but if the remote command fails then the script will proceede along untroubled by the failure. My work around is to use: rsh foo "rmtcommand && echo RSH_OK" | grep -s "RSH_OK" The rsh|grep pipeline returns the status of the grep command and it is true if the remote command is true. Jerry
geoff@utstat.uucp (Geoff Collyer) (10/24/90)
Revising the rsh protocol may be painful, but the sooner we do it, the less painful it will be. UCB has changed protocols in wide-spread use before; they changed the talk protocol and of course the telnet protocol is forever changing. The suggestion to just echo the exit status fails in the case of a failing shell built-in (e.g. cd) and is a kludgey workaround which can be even uglier if stdout must return output other than exit status. (Jerry Aguirre's suggestion would work to indicate simple success or failure, except that many shells don't return predictable status from a pipeline.) Making this kludge work in the presence of failing shell built-ins by adding another level of indirection makes the kludge worse still: rsh foo 'sh -c "cd /somewhere; cmd"; echo status $?' | tee /tmp/foo.out$$ | sed -n 's/^status //p' This is awfully circumlocutory for a simple request, which it should be possible to state as: rsh foo "cd /somewhere; cmd" It turns out that a bug report on this very subject has been filed with Sun by someone else with respect to SunOS 4.1. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu
del@thrush.mlb.semi.harris.com (Don Lewis) (10/25/90)
In article <1990Oct24.040934.7747@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes: >Revising the rsh protocol may be painful, but the sooner we do it, the >less painful it will be. UCB has changed protocols in wide-spread use >before; they changed the talk protocol and of course the telnet >protocol is forever changing. When they changed the talk protocol, they also changed the port number so both protocols can coexist. The only two ways I can think of to modify the protocol to return the exit status are to open a third connection just to return the exit status, or to return it at the end of one of the two output streams. I suspect the second scheme might cause problems at the client end if you are doing wierd things with the protocol (handshaking between client and server might be broken by the extra buffering, there might be a problem because of delayed connection closes due to the necessity of keeping the connection open to return the status). Another decision is whether to return the exact exit status, or just an indication of non-zero exit status. The former has problems when the remote command exits due to a signal and it aliases local errors (client can't contact server) with some remote errors. The latter is not as informative. You might also look at the protocol that "on" uses. It seems to return the exit status. It only has one output stream though, is very insecure (at least as of SunOS 4.0.x), and is not very widely implemented. > >The suggestion to just echo the exit status fails in the case of a >failing shell built-in (e.g. cd) and is a kludgey workaround which can >be even uglier if stdout must return output other than exit status. >(Jerry Aguirre's suggestion would work to indicate simple success or >failure, except that many shells don't return predictable status from a >pipeline.) Making this kludge work in the presence of failing shell >built-ins by adding another level of indirection makes the kludge worse >still: > > rsh foo 'sh -c "cd /somewhere; cmd"; echo status $?' | > tee /tmp/foo.out$$ | sed -n 's/^status //p' How about rsh foo 'sh -c "cd /somewhere; cmd" 2>&1; echo $? 1>&2' >/tmp/foo.out$$ \ 2>/tmp/foo.status$$ Redirect (or not) the two output streams as convenient. > >This is awfully circumlocutory for a simple request, which it should be >possible to state as: > > rsh foo "cd /somewhere; cmd" No argument, this is easier. > >It turns out that a bug report on this very subject has been filed with >Sun by someone else with respect to SunOS 4.1. That certainly doesn't mean that Sun will fix it :-( -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901