Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Problem: 2.6.b19, rsh/remsh on Ultrix 4.4
- X-seq: zsh-workers 1271
- From: Jenya <berd@xxxxxxxxxxxxxx> (Eugene B. Berdnikov)
- To: zsh-workers@xxxxxxxxxxxxxxx
- Subject: Problem: 2.6.b19, rsh/remsh on Ultrix 4.4
- Date: Thu, 6 Jun 1996 12:31:11 +0400 (GMT+3:00)
- Address: OEI UNK, IHEP, Protvino (Serpukhov district), Russia, SU 142284
- Organization: Institute for High Energy Physics, Protvino, Moscow reg., Russia
- Reply-to: berd@xxxxxxxxxxxxxx ((OO &;-))
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author