From: Jenya <berd@desert.ihep.su> (Eugene B. Berdnikov)
To: zsh-workers@math.gatech.edu
Subject: Problem: 2.6.b19, rsh/remsh on Ultrix 4.4
Date: Thu, 6 Jun 1996 12:31:11 +0400 (GMT+3:00) [thread overview]
Message-ID: <199606060831.MAA08686@desert.ihep.su> (raw)
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
next reply other threads:[~1996-06-06 8:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-06-06 8:31 Jenya [this message]
1996-06-06 9:56 ` Anthony Heading
1996-06-06 14:19 ` Jenya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199606060831.MAA08686@desert.ihep.su \
--to=berd@desert.ihep.su \
--cc=zsh-workers@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).