Re: behaviour with rsh

Re: behaviour with rsh

[Brian Dockter]

On Oct 17,  2:37pm, Carlos Carvalho wrote:
> Subject: Re: behaviour with rsh
> Zoltan Hidvegi (hzoli@cs.elte.hu) wrote on 17 October 1995 22:14:
> 
>  >> 
>  >> Zoltan wrote:
>  >> >I think this is not zsh specific.
>  >> 
>  >> I think it is.  zsh ought to be able to hide a child in a way which allows
>  >> the rsh to exit.  Maybe other shells are broken too. But so what? Also I
>  >> think, as Carlos says, that it used to work.
>  >> 
>  >> Running  rsh blaa "sh -c whatsit &"  is a horrible hack, and shouldn't be
>  >> necessary.
>  >
>  >I've just made zsh my login shell in the yp database, and tested
>  >this problem.
>  >
>  >rsh foo 'xterm -display bar:0 >&- 2>&- <&-'
>  >
>  >returned the prompt in almost all cases.  The only exception is when I rsh'd
>  >to an Ultrix machine, but only when the originating machine was not Linux.
> 
> I tested from linux to a sun 4.1.2 and it doesn't return. From the sun
> to linux it works fine, both with hzoli10.3.


I too have recently run across this problem. I have run the following
command under csh (SunOS and SCO) and zsh 2.3.1 (SunOS) for quite a
while (years) but it doesn't work under zsh 2.6-beta10 (SunOS):


    rsh -n host "env FOO=$BAR /bin/somecmd </dev/null >& /dev/null &"


Under csh and zsh 2.3.1 it returned immediately. Under zsh 2.6-beta10 it
doesn't return until the program exits (this was from SunOS 4.1.3 to
SunOS 4.1.3).



Brian

-- 
Brian Dockter   (KC7JZL)         | Email: brian@nds.com
Sr. Software Engineer            | Voice: 206-524-0014
Northwest Digital Systems        | FAX: 206-524-3440

Re: behaviour with rsh

[Duncan Sinclair]

Carlos Carvalho writes:
>
>Before zsh used to close file descriptors until 10. It was a hidden
>compile option. Why was it removed? I remember Duncan changed it a
>long time ago, but didn't suppress it, I think.
>

I can't remember my exact involvement in this, but the behaviour
of rsh and various shells is one area where I have too much
knowledge, and probably too strong opinions.

<PLUG>
Of course, the *complete* solution to this problem is to use
my "rxx" program, available from 
   ftp://ftp.dis.strath.ac.uk/pub/sinclair/rxx-4.2.2.tar.gz
</PLUG>

Now, my particular feeling was that although the "close fds 3-10"
solution fixes the problem, it is not an ideal solution in the
case when you happen to want to pass a file descriptor to zsh.
(This must have been my ammendment - the if test to see if it
is a "zsh -c" command.)

Ideally, what we want is a test to see if we are running under
rsh, and then do the close-fds.  I remember promising such a
while ago, but never got round to it.  I'll think more about it
this week.

More vague recollections on demand,


Duncan.

Re: behaviour with rsh

[Zoltan Hidvegi]

It works for me from Linux to SunOS 4.1.2.

Zoltan

Re: behaviour with rsh

[Carlos Carvalho]

Zoltan Hidvegi (hzoli@cs.elte.hu) wrote on 17 October 1995 22:14:

 >> 
 >> Zoltan wrote:
 >> >I think this is not zsh specific.
 >> 
 >> I think it is.  zsh ought to be able to hide a child in a way which allows
 >> the rsh to exit.  Maybe other shells are broken too. But so what? Also I
 >> think, as Carlos says, that it used to work.
 >> 
 >> Running  rsh blaa "sh -c whatsit &"  is a horrible hack, and shouldn't be
 >> necessary.
 >
 >I've just made zsh my login shell in the yp database, and tested
 >this problem.
 >
 >rsh foo 'xterm -display bar:0 >&- 2>&- <&-'
 >
 >returned the prompt in almost all cases.  The only exception is when I rsh'd
 >to an Ultrix machine, but only when the originating machine was not Linux.

I tested from linux to a sun 4.1.2 and it doesn't return. From the sun
to linux it works fine, both with hzoli10.3.

Before zsh used to close file descriptors until 10. It was a hidden
compile option. Why was it removed? I remember Duncan changed it a
long time ago, but didn't suppress it, I think.

Carlos

Re: behaviour with rsh

[Richard Coleman]

> Before zsh used to close file descriptors until 10. It was a hidden
> compile option. Why was it removed? I remember Duncan changed it a
> long time ago, but didn't suppress it, I think.

It probably got lost in the transition from buildzsh to autoconf.
I'll have to look through the zsh-2.5.03 sources to find out
about this.

Richard Coleman
coleman@math.gatech.edu

Re: behaviour with rsh

[Carlos Carvalho]

Zoltan Hidvegi (hzoli@cs.elte.hu) wrote on 10 October 1995 21:02:

 >I think this is not zsh specific.  My login shell is tcsh on the
 >Solaris box, and it has similar problems.  Rsh has many problems
 >which casuses processes to hang.  Just read an rsh manpage about a
 >few problems.
 >
 >I assume that the sun rshd waits for the cild and something else I
 >do not know while the linux rshd exits immediately if the child
 >closed all of the communication lines.  Both is a reasonable
 >behaviour, but if depends on the rshd and zsh has nothing to do
 >here.  Usually to start an rsh in the background, you should do
 >something like

It certainly has to do with zsh. I was using an old version in a sun
4.1.2, and the command worked, even with hzoli-3 in linux. After I
upgraded the sun version to hzoli-3 it stopped working. It may not be
a fault of zsh, but it sure depends on it.

Carlos

Re: behaviour with rsh

[Zoltan Hidvegi]

Heading, Anthony wrote:
> 
> Zoltan wrote
> > % rsh -n bolyai 'exec xterm -d :0 <&- >&- 2>&-'
> 
> This doesn't work for me on sunos4.1.3 with hzoli3 (which I've now
> accidentally upgraded to by deleting beta3).
> 
> Nor does   rsh narg 'sleep 10 & disown',  which hangs for 10 seconds,
> seemingly regardless of what I do with file descriptors.

I think this is not zsh specific.  My login shell is tcsh on the Solaris box,
and it has similar problems.  Rsh has many problems which casuses processes to
hang.  Just read an rsh manpage about a few problems.

I assume that the sun rshd waits for the cild and something else I do not know
while the linux rshd exits immediately if the child closed all of the
communication lines.  Both is a reasonable behaviour, but if depends on the
rshd and zsh has nothing to do here.  Usually to start an rsh in the
background, you should do something like

% rsh turan 'sh -c "xterm -d bolyai:0 < /dev/null > /dev/null 2>&1" &'

It may be necessary to give a fill pathname of xterm.  You can replace sh
above with any Bourne compatible shell, or with csh after a little
modification.  For a more complicated example look at the xrsh or xon
scripts.

Bye,
  Zoltan

RE: behaviour with rsh

[Heading, Anthony]

Zoltan wrote
> % rsh -n bolyai 'exec xterm -d :0 <&- >&- 2>&-'

This doesn't work for me on sunos4.1.3 with hzoli3 (which I've now
accidentally upgraded to by deleting beta3).

Nor does   rsh narg 'sleep 10 & disown',  which hangs for 10 seconds,
seemingly regardless of what I do with file descriptors.

Anthony

Re: behaviour with rsh

[Zoltan Hidvegi]

Carlos Carvalho wrote:
> 
> Hi folks,
> 
> This is with 2.6-beta10-hzoli10.3 on linux.
> 
> I used this command to open windows on other machines (line break for
> readability):
> 
> rsh -n <target machine> -- exec /usr/local/X11R5/bin/xterm
> -d <my machine>$DISPLAY -ls -T $1 '<&- >&- 2>&-'
> 
> The idea is to close the file descriptors so that rsh exits. In old
> releases this command leaves absolutely no processes in the <my
> machine>, and in the <target machine> the only ones are xterm and zsh.
> 
> With the above release the rsh now remains, and if I kill it the
> window of the <target machine> is closed. How can I get the old
> behaviour back?

It works for me.  I did an rsh from a Solaris-2.4 box to a linux-1.2.13
(Slackware-elf-beta), and the rsh command retured immediately, and there were
no processes left in either side except the xterm.  I did

% rsh -n bolyai 'exec xterm -d :0 <&- >&- 2>&-'

But it worked without the -n as well.

zsh version on the Solaris box is beta11-test7-hzoli11, and on the target (the
Linux machine) it is beta10-hzoli10.3.

I also tried rsh from one Linux to an other and it also worked.

Zoltan

behaviour with rsh

[Carlos Carvalho]

Hi folks,

This is with 2.6-beta10-hzoli10.3 on linux.

I used this command to open windows on other machines (line break for
readability):

rsh -n <target machine> -- exec /usr/local/X11R5/bin/xterm
-d <my machine>$DISPLAY -ls -T $1 '<&- >&- 2>&-'

The idea is to close the file descriptors so that rsh exits. In old
releases this command leaves absolutely no processes in the <my
machine>, and in the <target machine> the only ones are xterm and zsh.

With the above release the rsh now remains, and if I kill it the
window of the <target machine> is closed. How can I get the old
behaviour back?

Carlos