zsh 3.0/3.1 bug, zsh 3.1.4 regression

zsh 3.0/3.1 bug, zsh 3.1.4 regression

[SL Baur]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

The following problem, which exists in zsh 3.0.4 and 3.1.3 and 3.1.4
causes the cvs-1.10 regression tests to fail when /bin/sh is symlinked 
to zsh.  [this is from test `devcom3-5'.]

$ cat <<EOF
Enew    line    here
G@#$^!@#=&
EOF
Enew    line    here
G@#0@#=&

Bash produces the expected output:
Enew    line    here
G@#$^!@#=&


zsh 3.1.4 can be killed immediately:

$ Src/zsh -c "export LANG"
zsh: 23068 segmentation fault (core dumped)  Src/zsh -c export LANG

It appears Zoltan Hidvegi's patch of May 17 didn't get applied.




[-- Attachment #2: Type: message/rfc822, Size: 3768 bytes --]

From: Zoltan Hidvegi <hzoli@cs.elte.hu>
To: steve@xemacs.org (SL Baur)
Cc: zsh-workers@math.gatech.edu
Subject: Re: Another zsh 3.1 bug -- localization?
Date: Mon, 18 May 1998 01:53:33 -0500 (CDT)
Message-ID: <199805180653.BAA15526@hzoli.home>

SL Baur wrote:
> I've tested this now on zsh 3.1.2 and zsh 3.1.3 Linux libc5 and GNU
> libc.  It does not occur in zsh 3.0.4 or zsh 3.0.5.  It reproduces
> reliably for me in a new zsh-3.1.3 (without the `unset CDPATH'
> bugfix).  The machine I'm running on is localizable to the extent that
> `LANG=ja' is able to programs that need Japanese input and display
> Japanese output.
> 
> $ Src/zsh
> $ LC_ALL=C; export LC_ALL; LANC=C; export LANG; date
> zsh: 30841 segmentation fault (core dumped)  Src/zsh

A simple export LANG is enough for the coredump.  Any unset special
parameter will do, but LANG is unset by default.  The patch below fixes
this, but it introduces a slightly inconsistent behavior.  export LANG
will not set LANG, but if it is set later, it will be exported.  This is
similar to ksh, but inconsistent with zsh, which creates the parameter
with empty value when export used on a previously unset parameter.

An alternative fix would change the big if statement near line 1557,
which is now

if ((pm = (Param)paramtab->getnode(paramtab, asg->name)) &&
    (((pm->flags & PM_SPECIAL) && pm->level == locallevel) ||
     (!(pm->flags & PM_UNSET) &&
      ((locallevel == pm->level) || func == BIN_EXPORT) &&
      !(bit = ((off & pm->flags) | (on & ~pm->flags)) & PM_INTEGER))))

If the condition is changed to always be false when pm->flags & PM_UNSET
and createparam is changed to reset the unset flag and return the
parameter, it would probably work, and that's how it works in 3.0.5.
This has been changed since 3.0.5 by patch 3048 from Zefram which allowd
local parameters to hide special parameters.  I do not completely
understand this, but someone hopefully knows better.

Note that in the patch below addenv is not called when asg->value is
non-null (i.e. when a value is given in the typeset/export statement),
because in this case the later setsparm call does the addenv.

Zoltan


*** Src/builtin.c.orig	Fri May  8 01:24:52 1998
--- Src/builtin.c	Mon May 18 01:37:59 1998
*************** bin_typeset(char *name, char **argv, cha
*** 1585,1592 ****
  		pm->ct = auxlen;
  	    if (PM_TYPE(pm->flags) != PM_ARRAY) {
  		if (pm->flags & PM_EXPORTED) {
! 		    if (!pm->env)
! 			pm->env = addenv(asg->name, (asg->value) ? asg->value : getsparam(asg->name));
  		} else if (pm->env) {
  		    delenv(pm->env);
  		    zsfree(pm->env);
--- 1585,1592 ----
  		pm->ct = auxlen;
  	    if (PM_TYPE(pm->flags) != PM_ARRAY) {
  		if (pm->flags & PM_EXPORTED) {
! 		    if (!(pm->flags & PM_UNSET) && !pm->env && !asg->value)
! 			pm->env = addenv(asg->name, getsparam(asg->name));
  		} else if (pm->env) {
  		    delenv(pm->env);
  		    zsfree(pm->env);

Re: zsh 3.0/3.1 bug, zsh 3.1.4 regression

[Bart Schaefer]

On Aug 18, 11:19am, SL Baur wrote:
> Subject: zsh 3.0/3.1 bug, zsh 3.1.4 regression
> 
> The following problem, which exists in zsh 3.0.4 and 3.1.3 and 3.1.4
> causes the cvs-1.10 regression tests to fail when /bin/sh is symlinked 
> to zsh.  [this is from test `devcom3-5'.]
> 
> $ cat <<EOF
> Enew    line    here
> G@#$^!@#=&
> EOF
> Enew    line    here
> G@#0@#=&

$^! is $! with the RC_EXPAND_PARAM option turned on.  Try this:

$ sleep 10 &
$ cat <<EOF
Enew    line    here
G@#$^!@#=&
EOF
Enew    line    here
G@#24108@#=&
   ^^^^^
   Note process ID here

It might be possible for zsh to special-case use of the ^ modifier, but
really the cvs test should be using a quoted here-document, like so:

cat <<'EOF'
Enew    line    here
G@#$^!@#=&
EOF

This should work correctly in bash, ksh, and sh, as well as zsh.

Re: zsh 3.0/3.1 bug, zsh 3.1.4 regression

[SL Baur]

Bart Schaefer <schaefer@brasslantern.com> writes:

> On Aug 18, 11:19am, SL Baur wrote:
>> Subject: zsh 3.0/3.1 bug, zsh 3.1.4 regression
>> 
>> The following problem, which exists in zsh 3.0.4 and 3.1.3 and 3.1.4
>> causes the cvs-1.10 regression tests to fail when /bin/sh is symlinked 
>> to zsh.  [this is from test `devcom3-5'.]
>> 
>> $ cat <<EOF
>> Enew    line    here
>> G@#$^!@#=&
>> EOF
>> Enew    line    here
>> G@#0@#=&

> $^! is $! with the RC_EXPAND_PARAM option turned on.  Try this:

Why should this option be turned on when zsh is executed as /bin/sh?

 ...
> It might be possible for zsh to special-case use of the ^ modifier,

Why should it be using a csh abomination when it is invoked as /bin/sh?

Please do not condemn those of us without true Bourne shells to
running bash as /bin/sh.  Things worked better in zsh-3.1.2 than they
do in either 3.1.3 or 3.1.4.

> but really the cvs test should be using a quoted here-document, like
> so:

Agreed.

Re: zsh 3.0/3.1 bug, zsh 3.1.4 regression

[Bart Schaefer]

On Aug 18, 11:42pm, SL Baur wrote:
} Subject: Re: zsh 3.0/3.1 bug, zsh 3.1.4 regression
}
} Bart Schaefer <schaefer@brasslantern.com> writes:
} 
} > $^! is $! with the RC_EXPAND_PARAM option turned on.  Try this:
} 
} Why should this option be turned on when zsh is executed as /bin/sh?

Er, no, you misunderstand.  Placing a ^ after the $ *means* "turn on
the option for this one expansion only."  The option *is* off, under
all other circumstances, when emulating sh or ksh.

Zsh does not alter its parameter expansion (variable) syntax, except
for using 0-based vs. 1-based arrays, even when emulating.

} > It might be possible for zsh to special-case use of the ^ modifier,
} 
} Why should it be using a csh abomination when it is invoked as /bin/sh?

This is not "a csh abomination."  Csh does nothing of the kind.  It's
been standard zsh syntax for quite a long while now, and only zsh has it
that I know of.

} > but really the cvs test should be using a quoted here-document, like
} > so:
} 
} Agreed.

Then let's not bother info-cvs with any more of this thread.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh 3.0/3.1 bug, zsh 3.1.4 regression

[Bart Schaefer]

On Aug 18, 11:42pm, SL Baur wrote:
} Subject: Re: zsh 3.0/3.1 bug, zsh 3.1.4 regression
}
} Please do not condemn those of us without true Bourne shells to
} running bash as /bin/sh.  Things worked better in zsh-3.1.2 than they
} do in either 3.1.3 or 3.1.4.

You may think that, and may even have evidence of it, though I find
3.1.4 (plus a few recent patches) preferable to anything since 3.1 went
off on its own development branch. However, this particular detail
($^whatever) has been around since zsh 2.x, with the only change being
that before 3.0 it used to mean "toggle the option," which only made
sense if you knew how the option was set to begin with.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh 3.0/3.1 bug, zsh 3.1.4 regression

[SL Baur]

Bart Schaefer <schaefer@brasslantern.com> writes:

> On Aug 18, 11:42pm, SL Baur wrote:
> } Subject: Re: zsh 3.0/3.1 bug, zsh 3.1.4 regression
> }
> } Please do not condemn those of us without true Bourne shells to
> } running bash as /bin/sh.  Things worked better in zsh-3.1.2 than they
> } do in either 3.1.3 or 3.1.4.

To be fair, I only tested 3.1.4 far enough to see that the $LANG
problem wasn't fixed, then didn't install it.  I'm running 3.1.3
(patched for the $LANG problem) as $SHELL and 3.1.2 as /bin/sh.

> You may think that, and may even have evidence of it, though I find
> 3.1.4 (plus a few recent patches) preferable to anything since 3.1 went
> off on its own development branch.

O.K.

> However, this particular detail ($^whatever) has been around since
> zsh 2.x,

Right.  I later recalled having older binaries laying around and found
2.6-beta20 exhibited the same behavior.

> with the only change being that before 3.0 it used to mean "toggle
> the option," which only made sense if you knew how the option was
> set to begin with.

I didn't know that.  O.K.

I didn't intend any criticism of the One True Shell, or of its
developers.  You've created a remarkable program I can't live
without and I'm only trying to help.

Re: zsh 3.0/3.1 bug, zsh 3.1.4 regression

[Bart Schaefer]

On Aug 19,  4:58am, SL Baur wrote:
} Subject: Re: zsh 3.0/3.1 bug, zsh 3.1.4 regression
}
} I didn't intend any criticism of the One True Shell, or of its
} developers.  You've created a remarkable program I can't live
} without and I'm only trying to help.

Please don't anyone ever take anything I say as intending to discourage
criticism.  Criticism is indeed what makes things get better.  (I surely
spend enough of my own time griping.)  I was making a point about $^!,
and nothing more; sorry if my tone was misinterpreted.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com