[ BUG ] Parameter expansion issue on a defined as an empty string variable, using the "NO UNSET" flag.

[ BUG ] Parameter expansion issue on a defined as an empty string variable, using the "NO UNSET" flag.

[Clément BARRET]

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

Hi,

It appears there is a mix related to the colon use (which forces "set and
not empty strings") and the special ":#" expansion type when using the "set
-u" flag.

Let's consider this example :

#!/bin/zsh
set -u;

typeset youpi="";

echo "plop 1";
echo "youpi 1 ${youpi#*.cfg}";
echo "plop 2";
echo "youpi 2 ${youpi##*.cfg}";
echo "plop 3";
echo "youpi 3 ${youpi%*.cfg}";
echo "plop 4";
echo "youpi 4 ${youpi%%*.cfg}";
echo "plop 5";
echo "youpi 5 ${youpi:#*.cfg}";
echo "plop 6";


% ./test.zsh
plop 1
youpi 1
plop 2
youpi 2
plop 3
youpi 3
plop 4
youpi 4
plop 5
./test.zsh:15: youpi: parameter not set

Here is the manual part of the zshexpn "parameter expansion" section :

       ${name#pattern}
       ${name##pattern}
              If the pattern matches the beginning of the value of name,
then substitute the value of name with the matched portion  deleted;
otherwise,
              just substitute the value of name.  In the first form, the
smallest matching pattern is preferred; in the second form, the largest
matching
              pattern is preferred.

       ${name%pattern}
       ${name%%pattern}
              If the pattern matches the end of the value of name, then
substitute the value of name with the matched portion  deleted;
otherwise,  just
              substitute the value of name.  In the first form, the
smallest matching pattern is preferred; in the second form, the largest
matching pat‐
              tern is preferred.

       ${name:#pattern}
              If the pattern matches the value of name, then substitute the
empty string; otherwise, just substitute the value of name.  If  name  is
an
              array the matching array elements are removed (use the `(M)'
flag to remove the non-matched elements).



The ":#" expansion type doesn't behave like the "#" one at all. If the "#"
one matches, it can be the beginning of the string only while the ":#"
pattern must match the whole string. Hence the colon here can't be
considered as a modifier to tell whether you want or not "the emptiness" be
checked or not.

Here is another way to show this "colon" behavior :

#!/bin/zsh
set -u;

echo "plop 1";
echo "youpi 1 ${youpi+defined}";
echo "plop 2";
echo "youpi 2 ${youpi:+defined and not empty}";

typeset youpi="";

echo "plop 3";
echo "youpi 3 ${youpi+defined}";
echo "plop 4";
echo "youpi 4 ${youpi:+defined and not empty}";

echo "plop 5";
echo "youpi 5 ${(M)youpi:#matches the whole pattern}";

echo "plop 6";

% ./test2.zsh
plop 1
youpi 1
plop 2
youpi 2
plop 3
youpi 3 defined
plop 4
youpi 4
plop 5
./test2.zsh:17: youpi: parameter not set


The workaround is to embed the parameter expansions like this :

echo "${youpi:+${youpi:#my pattern here}}";

*BUT* this is really cumbersome and not documented at all in the manual.

Some technical details :

% zsh --version
zsh 5.0.2 (x86_64-redhat-linux-gnu)
% cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)


I think there should be a fix here to apply the ":#" expansion even on the
empty string and especially not raise an error while using the set -u
option on a defined variable, ever...

Regards,


                       RotoGluOn

Re: [ BUG ] Parameter expansion issue on a defined as an empty string variable, using the "NO UNSET" flag.

[Peter Stephenson]

> On 04 October 2018 at 16:44 Clément BARRET <rotogluon@gmail.com> wrote:
> It appears there is a mix related to the colon use (which forces "set and
> not empty strings") and the special ":#" expansion type when using the "set
> -u" flag.
> 
> Let's consider this example :
> 
> #!/bin/zsh
> set -u;
> 
> typeset youpi="";
> echo "youpi 5 ${youpi:#*.cfg}";

So you're getting a "parameter not set here", which is wrong.

Which version of zsh are you using and does this happen from "zsh -f"? I
haven't managed to get this to happen.

pws

Re: [ BUG ] Parameter expansion issue on a defined as an empty string variable, using the "NO UNSET" flag.

[Clément BARRET]

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

Hi,

as already stated at the end of my previous message, the zsh version is: zsh
5.0.2 (x86_64-redhat-linux-gnu) .

Same behavior with zsh -f indeed.

Regards,


              RotoGluOn



On Thu, 4 Oct 2018 at 18:09, Peter Stephenson <p.w.stephenson@ntlworld.com>
wrote:

>
> > On 04 October 2018 at 16:44 Clément BARRET <rotogluon@gmail.com> wrote:
> > It appears there is a mix related to the colon use (which forces "set and
> > not empty strings") and the special ":#" expansion type when using the
> "set
> > -u" flag.
> >
> > Let's consider this example :
> >
> > #!/bin/zsh
> > set -u;
> >
> > typeset youpi="";
> > echo "youpi 5 ${youpi:#*.cfg}";
>
> So you're getting a "parameter not set here", which is wrong.
>
> Which version of zsh are you using and does this happen from "zsh -f"? I
> haven't managed to get this to happen.
>
> pws
>

Re: [ BUG ] Parameter expansion issue on a defined as an empty string variable, using the "NO UNSET" flag.

[Peter Stephenson]

On Thu, 2018-10-04 at 18:31 +0200, Clément BARRET wrote:
> Hi,
> 
> as already stated at the end of my previous message, the zsh version
> is: zsh
> 5.0.2 (x86_64-redhat-linux-gnu) .

That's almost six years out of date: you need to upgrade.

pws

Re: [ BUG ] Parameter expansion issue on a defined as an empty string variable, using the "NO UNSET" flag.

[dana]

On 4 Oct 2018, at 11:31, Clément BARRET <rotogluon@gmail.com> wrote:
>as already stated at the end of my previous message, the zsh version is: zsh
>5.0.2 (x86_64-redhat-linux-gnu) .

I think this was fixed in workers/33118, so it would have been released with
5.0.7 or 5.0.8 probably.

dana

Re: [ BUG ] Parameter expansion issue on a defined as an empty string variable, using the "NO UNSET" flag.

[Clément BARRET]

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

Cool, thanks!

On Thu, 4 Oct 2018 at 18:46, dana <dana@dana.is> wrote:

> On 4 Oct 2018, at 11:31, Clément BARRET <rotogluon@gmail.com> wrote:
> >as already stated at the end of my previous message, the zsh version is:
> zsh
> >5.0.2 (x86_64-redhat-linux-gnu) .
>
> I think this was fixed in workers/33118, so it would have been released
> with
> 5.0.7 or 5.0.8 probably.
>
> dana
>
>