Path: utzoo!utstat!news-server.csri.toronto.edu!math.lsa.umich.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!trantor.harris-atd.com!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del
From: del@thrush.mlb.semi.harris.com (Don Lewis)
Newsgroups: news.software.b
Subject: Re: problems with responses from utstat!c-news (really rsh bugs)
Message-ID: <1990Oct24.191235.8134@mlb.semi.harris.com>
Date: 24 Oct 90 19:12:35 GMT
References: <1990Oct23.034613.16182@mlb.semi.harris.com> <49653@olivea.atc.olivetti.com> <1990Oct24.040934.7747@utstat.uucp>
Sender: news@mlb.semi.harris.com
Organization: Harris Semiconductor, Melbourne FL
Lines: 66
Nntp-Posting-Host: thrush.mlb.semi.harris.com

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