libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fix testsuite errors due to shell quoted parameter expansion issue.


From: Eric Blake
Subject: Re: Fix testsuite errors due to shell quoted parameter expansion issue.
Date: Wed, 04 Aug 2010 09:27:24 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.1.1

[please don't top-post on technical lists]

On 08/04/2010 09:18 AM, John Lumby wrote:
> 
> Re the statement
> 
>     since "$e" is quoted, it must not be elided
> 
> I don't think that is correct.   In fact "$e" *must* be elided  -  because 
> you juxtaposed it with the next token.    eliding and quoting are orthogonal.

Your statement is confusing to me.  Here, in more detail, is exactly
what I meant (and what I though I implied in the first case):

The word in question is '"$e"$f' before either parameter substitution,
or word splitting, or quote elision.

After parameter substitution, you are left with '"" val', where a
portion of the string was originally quoted, but you also had a portion
of the string that was unquoted.  Only the ' val' portion of the result
is subject to word splitting.

Because "$e" is quoted, the resulting empty string must not be elided
during word splitting.

Therefore, the result after word splitting MUST be the two words '""'
and 'val'; then you apply quote elision and are left with two words: ''
and 'val'.

> 
> What you appear to be be expecting is that the effect of quoting one token 
> should somehow have some effect on interpretation of a special character 
> (blank) in a subsequent unquoted token.   I don't think that is expected 
> behaviour.      The quoting of $e has the effect of quoting any special 
> characters inside *it*, of which there are none.     your blank is unquoted.  
>   Then word-spilling proceeds.

No, what I expect is that within a single word, the quoted portion of
the word must not be elided during word splitting, except in the special
case of "$@".

> 
> What I find interesting is this
> 
> bash -c 'declare -i length; f=" val" e=;concat="$e"$f; length=${#concat}; 
> echo "length= $length"'
> 4

Why do you find that interesting?  There is NO word splitting in
assignment contexts, so the effect of
concat="$e"$f
is the same as if you had done
concat=$e$f
or
concat="$e$f"
in all three cases, concat is assigned the value ' val', which is indeed
length 4.

But it is unrelated to the bash bug at hand, which is that when "$e"$f
is in a context subject to word splitting, then it must result in the
two words '' and 'val', not the single word 'val'.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]