in.rshd problems

[Scott Schwartz]

Paul Fox mcvax!marlow!fox at uunet asks:
>The question is why is in.rshd SO LARGE. My feelings are that someones got
>a table in the code with one or two too many 0's on the end of an array
>specifier.
>Any clues anyone ? Oh yeah, this is on Sun OS 4.0.1.

It seems that rshd allocates an array big enough to hold the maximum
number of bytes that a process can take in its argument list, and reads
the incoming command into it.  This number is NCARGS, found in
<sys/param.h>, and is 20480 in 4.3BSD, and 0x100000 in SunOS 4.0.  (Even
though csh doesn't use the new higher limit :-( )

The memory problem mentioned in the original article is an interesting and
probably avoidable side effect of an innocuous and otherwise beneficial
change that Sun made.  Just speculating, now, but I suppose people inside
Sun either have lots of memory on their machines, or they don't open many
NeWS/X windows on remote machines :-) :-) :-)

By the way, as long as your remote command is something like Xterm,
you should invoke it in the background with standard input, output and
error redirected, so that rshd will exit and not hang around at all.
i.e.
	rsh shire "xterm -display gondor:0 </dev/null >&/dev/null &"
-- 
Scott Schwartz		<schwartz at shire.cs.psu.edu>

[[ Declaring a static area for the arguments?  That's bad.  Seems that it
would be very much worth the little extra time to allocate the space as
needed.  Or perhaps a mixture of the two:  declare a reasonably sized
static area and only allocate more if you need it.  By the way:  I have
seen people locally use "rsh" merely to start an interactive login to
another host, as in simply "rsh titan".  This is a good reason to use
"rlogin" for these cases instead.  --wnl ]]