zsh bug

zsh bug

[Arnon Kanfi]

Hi,

I have discovered a bug in zsh 3.1.4 when used on SunOs. when doing an "su"
zsh will not read any of the global RC files. After tracking the problem I
have found out that su on SunOs 4.1.4 sets argv[0] to "-su" which causes zsh
to do "sh" emulation and not read the RC files. Enclosed is a small patch
that fixes the problem on SunOs (I use the "SHELL" env variable which is set
correctly to /usr/bin/zsh)

In addition to that I ran into another problem on AIX 4.3 with EGCS. Were
the
generated executable could not be loaded because of alignment problems, See
below:

      0509-036 Cannot load program ./zsh because of the following errors:
      0509-029 Alignment of text does not match required alignment.
      0509-025 The ./zsh file is not executable or not in correct XCOFF
format.
      0509-026 System error: Cannot run a file that does not have a valid
form

Adding -H512 to the linker flags in the gcc specs file fixed the above
problem.

Hope that helps.
Arnon

diff -ubw /usr2/misc/tools/zsh-3.1.4/Src/main.c\~
/usr2/misc/tools/zsh-3.1.4/Src/main.c
--- /usr2/misc/tools/zsh-3.1.4/Src/main.c~	Wed Apr 29 17:42:50 1998
+++ /usr2/misc/tools/zsh-3.1.4/Src/main.c	Sun May 16 17:35:02 1999
@@ -43,6 +43,9 @@

     init_hackzero(argv, environ);

+    if (strcmp(argv[0], "-su") == 0)
+        argv[0] = getenv("SHELL");
+
     for (t = argv; *t; *t = metafy(*t, -1, META_ALLOC), t++);

     if (!(zsh_name = strrchr(argv[0], '/')))

Diff finished at Sun May 16 17:38:39

PATCH: 3.1.5-pws-18: Re: zsh bug

[Peter Stephenson]

"Arnon Kanfi" wrote:
> I have discovered a bug in zsh 3.1.4 when used on SunOs. when doing an "su"
> zsh will not read any of the global RC files. After tracking the problem I
> have found out that su on SunOs 4.1.4 sets argv[0] to "-su" which causes zsh
> to do "sh" emulation and not read the RC files. Enclosed is a small patch
> that fixes the problem on SunOs (I use the "SHELL" env variable which is set
> correctly to /usr/bin/zsh)

There was a discussion on this back in zsh-workers/3221 and follow-ups,
although it concentrated more on whether su itself was broken.  The real
problem here is that zsh can't actually know what it should be emulating;
su might have exec'd an `sh' which happened to be zsh in disguise.
Nonetheless, I would agree that the best bet is to do native emulation in
this case.

If it had been up to me, I would have restricted the cases when zsh did
emulation to a fixed set of names rather than the first letter.  But now
the current behaviour is well established, although as far as I can see
undocumented, the simplest fix is to check if the name begins `su' and if
so ignore it for emulation purposes.  This leaves zsh_name as su, but I
think that's the right thing to do if that's how the shell was called.

The following patch also documents the algorithm for choosing emulation for
the first time (unless I've failed to locate something in Doc/Zsh).

Or has somebody got a better suggestion?

--- Doc/Zsh/compat.yo.su	Thu Dec 17 17:10:13 1998
+++ Doc/Zsh/compat.yo	Mon May 17 11:13:36 1999
@@ -7,7 +7,18 @@
 cindex(sh, compatibility)
 cindex(ksh, compatibility)
 Zsh tries to emulate bf(sh) or bf(ksh) when it is invoked as
-tt(sh) or tt(ksh) respectively.  In this mode the following
+tt(sh) or tt(ksh) respectively.  More precisely, it looks at the first
+letter of the name passed to it, which may not necessarily be the
+name of the executable file, ignoring any initial `tt(-)' as well as
+`tt(r)' (for restricted); an `tt(s)' or `tt(b)' will force
+bf(sh) compatibility, while `tt(k)' will force bf(ksh) compatibility.  An
+exception is if the first two letters excluding any `tt(-)' are tt(su), in
+which case no emulation will be performed; this is to workaround a problem
+under some operating systems where the tt(su) command does not change the
+name when executing a user shell.  Note that, from within zsh itself, this
+mechanism can be invoked by `tt(ARGV0=sh zsh ...)'.
+
+In this emulation mode, the following
 parameters are not special and not initialized by the shell:
 tt(ARGC),
 tt(argv),
--- Src/options.c.su	Thu May 13 17:45:43 1999
+++ Src/options.c	Mon May 17 10:53:26 1999
@@ -446,7 +446,7 @@
 	emulation = EMULATE_CSH;
     else if (ch == 'k')
 	emulation = EMULATE_KSH;
-    else if (ch == 's' || ch == 'b')
+    else if ((ch == 's' && zsh_name[1] != 'u') || ch == 'b')
 	emulation = EMULATE_SH;
     else
 	emulation = EMULATE_ZSH;

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

PATCH: 3.1.5-pws-18: Re: zsh bug, again

[Peter Stephenson]

Peter Stephenson wrote:
> "Arnon Kanfi" wrote:
> > I have discovered a bug in zsh 3.1.4 when used on SunOs. when doing an "su"
>
> The real
> problem here is that zsh can't actually know what it should be emulating;
> su might have exec'd an `sh' which happened to be zsh in disguise.

Arnon pointed out you might as well use $SHELL to find out what's what,
since su probably did to get the shell in the first place.  So this does
that.  I'm still loath to change the $ZSH_NAME parameter from what it's
been exec'd as.  It depends if you think it should reflect the execution
environment or the emulation; in most cases it reflects the former, and the
emulation is just a side effect.  But I'm not madly fixed on this.

--- Doc/Zsh/compat.yo.su2	Mon May 17 11:13:36 1999
+++ Doc/Zsh/compat.yo	Wed May 19 10:50:13 1999
@@ -12,11 +12,12 @@
 name of the executable file, ignoring any initial `tt(-)' as well as
 `tt(r)' (for restricted); an `tt(s)' or `tt(b)' will force
 bf(sh) compatibility, while `tt(k)' will force bf(ksh) compatibility.  An
-exception is if the first two letters excluding any `tt(-)' are tt(su), in
-which case no emulation will be performed; this is to workaround a problem
-under some operating systems where the tt(su) command does not change the
-name when executing a user shell.  Note that, from within zsh itself, this
-mechanism can be invoked by `tt(ARGV0=sh zsh ...)'.
+exception is if the name excluding any `tt(-)' is tt(su), in which case
+the environment variable tt(SHELL) will be used to test the emulation;
+this is to workaround a problem under some operating systems where the
+tt(su) command does not change the name when executing a user shell.  Note
+that, from within zsh itself, this mechanism can be invoked by `tt(ARGV0=sh
+zsh ...)'.
 
 In this emulation mode, the following
 parameters are not special and not initialized by the shell:
--- Src/options.c.su2	Mon May 17 10:53:26 1999
+++ Src/options.c	Wed May 19 10:48:47 1999
@@ -438,6 +438,17 @@
 {
     char ch = *zsh_name;
 
+    if (!strcmp("su", zsh_name)) {
+	/* We haven't set up the paramtable yet, so just use zgetenv */
+	char *ptr = zgetenv("SHELL");
+	if (ptr && *ptr) {
+	    zsh_name = ptr;
+	    if ((ptr = strrchr(zsh_name, '/')))
+		zsh_name = ptr+1;
+	    ch = *zsh_name;
+	} else
+	    ch = 'z';
+    }
     if (ch == 'r')
 	ch = zsh_name[1];
 
@@ -446,7 +457,7 @@
 	emulation = EMULATE_CSH;
     else if (ch == 'k')
 	emulation = EMULATE_KSH;
-    else if ((ch == 's' && zsh_name[1] != 'u') || ch == 'b')
+    else if (ch == 's' || ch == 'b')
 	emulation = EMULATE_SH;
     else
 	emulation = EMULATE_ZSH;

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

zsh bug

[Glenn Trigg]

Hello,

Greg Badros suggested I send a mail to this list to inform you
of a bug I'm experiencing in zsh.

Firstly though, I'll just mention that I've been using zsh for a
couple of weeks and I really like it. Previously I was a long-term
tcsh user.

The version of zsh I'm using is 3.0.6-pre-2 with gjb's "color-n-editing"
patch applied.

The wierd behaviour happens when I do the following:

kill -1 $(cat /var/run/ine

when I hit tab there, the line completes as:

kill -1 $(cat /var/run/ineetd.pid

I.e I get the extra letter which is the letter at the end when I hit
tab.

I haven't subscribed to this mailing list so if anyone has something to
tell me please cc me directly.

Regards,

Glenn Trigg

Re: zsh bug

[Geoff Wing]

Glenn Trigg <glenn@aus.compgen.com> typed:
:The version of zsh I'm using is 3.0.6-pre-2 with gjb's "color-n-editing"
:patch applied.
:
:The wierd behaviour happens when I do the following:
:kill -1 $(cat /var/run/ine
:when I hit tab there, the line completes as:
:kill -1 $(cat /var/run/ineetd.pid
:I.e I get the extra letter which is the letter at the end when I hit
:tab.

And it's reproducible with "zsh -f" (vanilla 3.0.6-pre-2)
-- 
Geoff Wing   <gcw@pobox.com>     NEW>>>>Mobile : (Australia) 0413 431 874
Work URL: http://www.primenet.com.au/   Ego URL: http://pobox.com/~gcw/

zsh bug

[Drew Middlesworth]

I've been able to reproduce this bug on Ubuntu Dapper (zsh
4.2.5-23ubuntu3), Ubuntu Edgy (zsh 4.3.2-13ubuntu1), Ubuntu Gusty (zsh
4.3.4-14ubuntu2),CentOS5 (zsh-4.2.6-1) and also in the latest
development (zsh 4.3.4) on multiple operating systems. This issue
doesn't seem to exist in zsh version 4.1.1 that we also tested. The
steps to reproduce this are below.

Could you also reply CC my address too? Thanks,

Drew


Steps to reproduce (on dapper, with vi bindings):
 - enter some commands (echo foo ...)
 - hit esc to go into command mode
 - do a backward search: hit [the ?/ key] to get a '?' char indicating
  a backward search. search for something you typed a few lines
  back.
 - the search is successful, you're now a few lines back in the history
 - repeat:
  - shift-[the ?/ key] to get a '/' char indicating a forward-search
    (yes, normally you'd press [?/] without shift to get this char, but
     they invert it, since normally you want to search backwards
     through history)
  - backspace: don't search
  - scroll up or down in the history

After a few tries, pressing shift-[?/], when a '/' char should appear will
crash zsh:

Here, I searched backwards for 'echo c', then it crashed (after a few
tries) when I'd scrolled back to the 'echo a' line and tried a
forward-search:

epizzi@epizzi:~$ zsh
[epizzi:~]$ echo a
a
[epizzi:~]$ echo b
b
[epizzi:~]$ echo c
c
[epizzi:~]$ echo d
d
[epizzi:~]$ echo e
e
[epizzi:~]$ echo *** glibc detected *** double free or corruption
(fasttop): 0x080dfea8 ***
Aborted

Re: zsh bug

[Peter Stephenson]

"Drew Middlesworth" wrote:
> I've been able to reproduce this bug on Ubuntu Dapper (zsh
> 4.2.5-23ubuntu3), Ubuntu Edgy (zsh 4.3.2-13ubuntu1), Ubuntu Gusty (zsh
> 4.3.4-14ubuntu2),CentOS5 (zsh-4.2.6-1) and also in the latest
> development (zsh 4.3.4) on multiple operating systems.

You might find it was fixed by the following patch
http://www.zsh.org/mla/workers/2007/msg00735.html

2007-09-13  Clint Adams  <clint@zsh.org>

	* 23813: Src/Zle/zle_hist.c: set vipenultsrchstr to NULL
	after freeing it to avoid vi-mode history search segfaults.


-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070