Re: Tar file and Re: Bad interaction between -iprefix and -string

Re: Tar file and Re: Bad interaction between -iprefix and -string

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 11,  6:08pm, Peter Stephenson wrote:
> } Subject: Re: Tar file and Re: Bad interaction between -iprefix and -string
> }
> } [...]  for some reason
> } 
> } for i in "$patcomps[@]"; do
> } 
> } was being called when patcomps was empty (should it really do that?)
> 
> Hmm.  You mean the for loop, looped?  Obviously it shouldn't do that.
> How was patcomps initialized up to that point?

The array isn't initialised at all, look:

  % foo() { echo $# }
  % unset a
  % foo $a[@]
  0                    # fine
  % foo "$a[@]"
  1                    # oops

The same for `$a[*]' and `$a'.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset

[Peter Stephenson]

Sven Wischnowsky wrote:
>   % foo() { echo $# }
>   % unset a
>   % foo $a[@]
>   0                    # fine
>   % foo "$a[@]"
>   1                    # oops

The code's a little murky (as in `hell is murky' --- or'ing with
something is a pretty shoddy way of making a value negative,
particularly when the SCANPM_ISVAR_AT flag is never seen again), but
the following seems to do the trick.  Note that putting `a=()' before
would have been a workaround.

> The same for `$a[*]' and `$a'.

That's right, surely?  Quoted variables only expand to nothing if the
@ is present.

--- Src/params.c.isarr	Mon Feb  1 09:52:30 1999
+++ Src/params.c	Fri Feb 12 10:14:14 1999
@@ -966,7 +966,7 @@
     if (*tbrack == Outbrack)
 	*tbrack = ']';
     if ((s[0] == '*' || s[0] == '@') && s[1] == ']') {
-	if (v->isarr && s[0] == '@')
+	if ((v->isarr || !v->pm || !*v->pm->nam) && s[0] == '@')
 	    v->isarr |= SCANPM_ISVAR_AT;
 	v->a = 0;
 	v->b = -1;

-- 
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

Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset

[Bart Schaefer]

On Feb 12, 10:28am, Peter Stephenson wrote:
} Subject: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset
}
} Sven Wischnowsky wrote:
} >   % foo() { echo $# }
} >   % unset a
} >   % foo $a[@]
} >   0                    # fine
} >   % foo "$a[@]"
} >   1                    # oops

That's not an "oops".  That's the way it's supposed to work.  Try the
equivalent code in bash.

[schaefer@zagzig zsh-3.1.5-work]$ unset f
[schaefer@zagzig zsh-3.1.5-work]$ foo() { echo $#; echo "$@"; }
[schaefer@zagzig zsh-3.1.5-work]$ foo "$f[@]"
1
[@]

c[1] ksh
$ unset f
$ foo() { echo $#; echo "$@"; }  
$ foo "$f[@]"
1
[@]

(I had to ssh to my old grad school account to get that ksh example.)

zagzig[32] ARGV0=ksh zsh
zagzig% unset f
zagzig% foo() { echo $#; echo "$@"; }
zagzig% foo "$f[@]"
1
[@]

} Note that putting `a=()' before would have been a workaround.

That's The Right Thing To Do, not a workaround.

} Quoted variables only expand to nothing if the @ is present.

On a scalar -- which is what `a' is if you've never done `a=()' -- the
string $a[@] expands to all the characters in the value of $a; it's the
same as just "$a".  The quoted-@ magic doesn't apply when slicing a
scalar.

I don't think we want this patch.

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

Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset

[Peter Stephenson]

> } Sven Wischnowsky wrote:
> } >   % foo() { echo $# }
> } >   % unset a
> } >   % foo $a[@]
> } >   0                    # fine
> } >   % foo "$a[@]"
> } >   1                    # oops
> 
> That's not an "oops".  That's the way it's supposed to work.  Try the
> equivalent code in bash.

Bash doesn't even have arrays, apart from "$@", of course.  Try it in
ksh, and remember you need "${f[@]}" because the bracing rules are
more strict, and you'll find it elides the whole thing as with the
patch.

Taking a @ subscript was never a well-defined thing to do on a scalar,
whether or not it happens to be so with a zsh extension; its essential
purpose is to provide word splitting for arrays in strings, so zero
elements gives zero words.  (And if it leaves a null argument on the
line for an empty scalar, I would argue that's inconsistently
implemented.)

> I don't think we want this patch.

It seems pretty clear to me the shell is just plain broken without it.

-- 
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

Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset

[Bart Schaefer]

On Feb 12,  4:45pm, Peter Stephenson wrote:
} Subject: Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset
}
} Try it in ksh, and remember you need "${f[@]}"

OK, I concur.  3.0.5 is broken in the same way, then.

However, with your patch, I get this:

zagzig% foo() { echo $# "$@" }
zagzig% foo "$unset[@]"
zsh: segmentation fault (core dumped)  Src/zsh -f


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

PATCH: Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset

[Bart Schaefer]

On Feb 12,  9:33am, Bart Schaefer wrote:
} Subject: Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset
} 
} zagzig% foo() { echo $# "$@" }
} zagzig% foo "$unset[@]"
} zsh: segmentation fault (core dumped)  Src/zsh -f

Here's a fix.  I don't think this can possibly cause anything else to go
wrong, but ...

The first two hunks go on top of PWS's patch and simply expand a bit more
on the test he changed, to be sure no null pointers are dereferenced.

I'm not sure the test of the PM_UNSET flag is necessary, but it seemed
to fit the semantics.

The third hunk (still params.c) causes getarrvalue() to return an empty
array rather than NULL for an unset parameter.  There are just too many
uses of the result in paramsubst() to be sure they're all prepared to
handle a NULL.  Note that `nular' is an array consisting of one empty
element, which may be the wrong thing to return in the pre-existing (!v)
branch, but I'm not prepared to muck with that.

It bugs me a little that the code in paramsubst() seems to "accidentally"
do the right thing given this return value.  It really should explictly
check (isarr < 0) and (vunset) -- which combined mean an unset variable
that was subscripted with [@] -- rather than stumbling into the correct
branch because (aval[0] == 0), which is what happens now.  However ...

Index: Src/params.c
===================================================================
--- params.c	1999/02/12 17:10:43	1.27
+++ params.c	1999/02/13 06:55:01
@@ -246,6 +246,10 @@
 };
 #undef BR
 
+#define IS_UNSET_VALUE(V) \
+	((V) && (!(V)->pm || ((V)->pm->flags & PM_UNSET) || \
+		 !(V)->pm->nam || !*(V)->pm->nam))
+
 static Param argvparam;
 
 /* hash table containing the parameters */
@@ -966,7 +970,7 @@
     if (*tbrack == Outbrack)
 	*tbrack = ']';
     if ((s[0] == '*' || s[0] == '@') && s[1] == ']') {
-	if ((v->isarr || !v->pm || !*v->pm->nam) && s[0] == '@')
+	if ((v->isarr || IS_UNSET_VALUE(v)) && s[0] == '@')
 	    v->isarr |= SCANPM_ISVAR_AT;
 	v->a = 0;
 	v->b = -1;
@@ -1205,6 +1209,8 @@
 
     if (!v)
 	return arrdup(nular);
+    else if (IS_UNSET_VALUE(v))
+	return arrdup(&nular[1]);
     if (v->inv) {
 	char buf[DIGBUFSIZE];
 

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

Re: PATCH: Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 12,  9:33am, Bart Schaefer wrote:
> } Subject: Re: PATCH: zsh-3.1.5-pws-7: "$a[@]" with $a unset
> } 
> } zagzig% foo() { echo $# "$@" }
> } zagzig% foo "$unset[@]"
> } zsh: segmentation fault (core dumped)  Src/zsh -f
> 
> Here's a fix.  I don't think this can possibly cause anything else to go
> wrong, but ...

...it broke multiple subscripts. The patch below fixes this in a way
that hopefully will not cause anything else to go wrong, but...

Seriously, the problem was that for multiple subscripts a temporary
pm-struct was created with a NULL nam. The patch makes such a
temporary get a nam equal to nulstring. Since such a temporary is
created only in one place this should not affect other uses (of
createparam() and getarrvalue()).

I found this while trying to `fix' the problem I mentioned in 7328:

Given an array `a=(a b b c d e f g)' an expression like this

  ${${a[1,4]}[(I)b]}

gives `3' (the offset of the last `b' in the first four
elements). But if the expression is used inside a subscript:

  ${a[${${a[1,4]}[(I)b]},-1]}

this returns the whole string because the first expression expands to
`0' (zero). This is caused by the call to parsestr() in getarg() which
makes the subscript be tokenized as if it where in double quotes. With
that the code in paramsubst() and friends turns ${a[1,4]} into one
string, making the [(I)b] fail. To get this to work one will have to
use ${a[${${(@)a[1,4]}[(I)b]},-1]}.

I don't want to change this now because I think that there are reasons
to use parsestr() instead of parse_subst_string() (which solves the
problem), but I think that this difference between using the same
expression outside of an subscript and inside one is quite irritating.
So, does anyone know of a case where we need the behavior parsestr()
gives?


Bye
 Sven

--- os/params.c	Mon Feb 15 12:51:43 1999
+++ Src/params.c	Thu Feb 18 11:20:15 1999
@@ -568,8 +568,10 @@
 
 	if (isset(ALLEXPORT) && !oldpm)
 	    flags |= PM_EXPORTED;
-    } else
+    } else {
 	pm = (Param) alloc(sizeof *pm);
+	pm->nam = nulstring;
+    }
     pm->flags = flags;
 
     if(!(pm->flags & PM_SPECIAL))

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de