Problem: 2.6.b19, rsh/remsh on Ultrix 4.4

Problem: 2.6.b19, rsh/remsh on Ultrix 4.4

[Jenya]

   Hi, Gentlemen.

   I'm working on the DEC/MIPS stations, running Ultrix 4.4. Recently
 I have upgraded zsh from 2.6-beta2 to 2.6-beta19 and meet some problems.


 1. The rsh/remsh hangs
    -------------------

 When I want to start a process on remote machine with the command like

> rsh dxbec -l berd 'DISPLAY=forest.ihep.su:0.0 \
	/usr/bin/X11/xterm </dev/null >&/dev/null & \
	jobs -l ; echo done $$.'

 the remote shell should terminate with xterm disconnected. This works
 nice with 2.6-beta2 and other Bourne shells, but does not with 2.6-beta19.
 Instead I found zombie zsh and sleeping rshd as a parent process on a
 remote node, and local rsh/remsh hangs until xterm terminates:

2:/usr/users/berd> ps xl                                            dxbec 20:07
      F UID   PID  PPID CP PRI NI ADDR  SZ  RSS WCHAN STAT  TT  TIME COMMAND
11008401 617  4757  4756  0  30  0  c79   0    0       Z     ?   0:00 <exiting>
11008001 617  4758     1  7   1  5  c79 536  404 cc01c S N   ?   0:00 /usr/bin/X
...
2:/usr/users/berd> ps xl4756                                        dxbec 20:08
      F UID   PID  PPID CP PRI NI ADDR  SZ  RSS WCHAN STAT  TT  TIME COMMAND
11008001   0  4756   162  1   1  0  925 212  108 cc01c I     ?   0:00 rshd

 The remote zsh executes the command string after the "&", returning the
 string "done 4756.", then turns into the zombie state. I have tested this,
 running "pure" zsh-2.6-beta19, compiled with the dummy pathes to its
 resource files (zshenv, etc), and with cleared home directory. I also
 tried compilers gcc-2.7.2, gcc-2.5.8 and native ultrix cc - always with
 the same result.

 For comparison, 2.6-beta19 works fine when compiled for Linux with gcc-2.7.2,
 i486; as well as for OSF/1 v3.0 on DEC Alpha compiled with its native cc.
 So I suspect that there is something wrong with Ultrix compilers. Here is
 the full list of warnings, generated by ultrix cc:


cc -c -O2 -Olimit 1500 -I.. -I. hashtable.c
cfe: Warning: hashtable.c, line 233: Incompatible pointer type assignment
     return ztrcmp((*a)->nam, (*b)->nam);
 ----------------------^
cfe: Warning: hashtable.c, line 233: Incompatible pointer type assignment
     return ztrcmp((*a)->nam, (*b)->nam);
 ---------------------------------^

cc -c -O2 -Olimit 1500 -I.. -I. zle_hist.c
cfe: Warning: zle_hist.c, line 46: Incompatible pointer type assignment
        if (metadiffer(ent->zle_text ? ent->zle_text : ent->text, line, ll)) {
        ----------------------------------------------------------^
cfe: Warning: zle_hist.c, line 909: Incompatible pointer type assignment
        if (! metadiffer(s, line, ll))
        --------------------^

cc -c -O2 -Olimit 1500 -I.. -I. zle_main.c
cfe: Warning: zle_main.c, line 496: Incompatible pointer type assignment
        line = metafy(line, ll, 0);
        -----^
cfe: Warning: zle_main.c, line 496: Incompatible pointer type assignment
        line = metafy(line, ll, 0);
        --------------^

cc -c -O2 -Olimit 1500 -I.. -I. zle_tricky.c
cfe: Warning: zle_tricky.c, line 587: Incompatible pointer type assignment
     if (viinsbegin > ztrsub(line + wb, line))
 ---------------------------------^
cfe: Warning: zle_tricky.c, line 587: Incompatible pointer type assignment
     if (viinsbegin > ztrsub(line + wb, line))
 ---------------------------------------^
cfe: Warning: zle_tricky.c, line 588: Incompatible pointer type assignment
        viinsbegin = ztrsub(line + wb, line);
        -------------------------^
cfe: Warning: zle_tricky.c, line 588: Incompatible pointer type assignment
        viinsbegin = ztrsub(line + wb, line);
        -------------------------------^

cc -c -O2 -Olimit 1500 -I.. -I. zle_utils.c
cfe: Warning: zle_utils.c, line 181: Incompatible pointer type assignment
     unmetafy(line, &ll);
 -------------^


 2. The cd/pushd behavior
 ------------------------

 One my user complaints that when autopushd and pushdminus options are set,
 and pushdtohome is not set, then `cd' builtin without arguments in 2.6-beta19
 always returns to home, but not into the previous directory, as it was in
 2.6-beta2. However, `pushd' without argument works right.


 I have no time to study and fix these problems myself, but hope this message
 may be useful in your work for zsh.

 With best regards,
 Eugene Berdnikov

Re: Problem: 2.6.b19, rsh/remsh on Ultrix 4.4

[Anthony Heading]

>  1. The rsh/remsh hangs
>     -------------------
> 
>  When I want to start a process on remote machine with the command like
> 
> > rsh dxbec -l berd 'DISPLAY=forest.ihep.su:0.0 \
> 	/usr/bin/X11/xterm </dev/null >&/dev/null & \
> 	jobs -l ; echo done $$.'
> 
>  the remote shell should terminate with xterm disconnected.

Try defining RSH_BUG_WORKAROUND


>  2. The cd/pushd behavior
>  ------------------------
> 
>  One my user complaints that when autopushd and pushdminus options are set,
>  and pushdtohome is not set, then `cd' builtin without arguments in 2.6-beta19
>  always returns to home, but not into the previous directory, as it was in
>  2.6-beta2. However, `pushd' without argument works right.

Yes, an incompatible change.  But the new behaviour is more consistent with
what one would expect.  Maybe there's an argument for creating a new option -- 
it should have been there in the first place instead of PUSHDTOHOME.

You can, I think, emulate the old behaviour by aliasing cd=pushd

Anthony

Re: Problem: 2.6.b19, rsh/remsh on Ultrix 4.4

[Jenya]

> From: Anthony Heading <aheading@jpmorgan.com>
> Subject: Re: Problem: 2.6.b19, rsh/remsh on Ultrix 4.4
> Date: Thu, 6 Jun 1996 10:56:20 +0100 (BST)
...
> Try defining RSH_BUG_WORKAROUND

  Hi, Anthony.

  It solves the problem. Thank you. I propose to add the following text
 into the Etc/MACHINES (DEC section):

	Compile with RSH_BUG_WORKAROUND flag on DECstation with Ultrix.
	Undefine HAVE_TERMIOS_H if native DEC cc compiler is used.

 The last statement was stressed in the old zsh distributions, but I did
 not meet it in 2.6-beta19.

 Regards,
 Eugene Berdnikov