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: zsh-3.1.5-pws-7: "$a[@]" with $a unset

[Sven Wischnowsky]

Peter Stephenson wrote:

> 
> > The same for `$a[*]' and `$a'.
> 
> That's right, surely?  Quoted variables only expand to nothing if the
> @ is present.

Yep, I wanted to write `... as for...'. Interesting, gives a
completely different sentence.

Bye
 Sven


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