Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15727

unquoted expansion not working (was Re: Not missing, but very hard to see)

Show all headers | View raw

On 2019/12/12 19:03, Eli Schwartz wrote:
> On 12/12/19 9:57 PM, L A Walsh wrote:
>   
>> On 2019/12/12 13:01, Ilkka Virta wrote:
>>     
>>> On 12.12. 21:43, L A Walsh wrote:
>>>  
>>>       
>>> The backquote is in [6], and the backslash disappears, you just get
>>> the pair of quotes in [2] because that's how printf %q outputs an
>>> empty string.
>>>   
>>>       
>> -----
>>
>>    I'm sorry, but you are mistaken.
>>     
>
> How so?
>   
    At the time, I read that as the quoting problem being in '6' not
in '2'.
>   
>>    The characters from 'Z' (0x5A) through 'z' (0x61) are:
>> 0x5A 0x5B 0x5C 0x5D 0x5E 0x5F 0x60 0x61
>> Z    [    \    ]     ^   _     `    a
>> the backslash comes between the two square brackets.
>> Position [6] is the "Grave Accent" (or backquote).
>> It is quoted properly.
>>     
>
> But... that's exactly what was said.
>   
----
    Indeed!  Apparently, I was misreading their response.
>   
>> As for %q printing an empty string for 0x5C
>>         "%q" causes  printf to output the corresponding argument in a
>>         format that can be reused as shell input.
>>    For that string to be empty would mean there is no character at hex
>> value 0x5C (unicode U+005C), which isn't so.
>>     
>
> But there isn't. An empty string was passed as an argument to printf,
> because the backslash was *converted* via escaping, into an empty
> string, *before* it was passed on the command line as an argv element to
> the printf builtin.
>   
-----
    The backslash never existed because it wasn't escaped.  I.e. if it was
escaped properly (with a backslash before every meta character), then it 
would
have been safe.
   
> Do you think that because printf is a builtin, and you didn't use
> /bin/printf, that somehow means it is exempt from the usual rule of how
> shells work, and gets to see its own argv before the parser reinterprets it?
>   
The problem starts when the range is expanded.  Bash doesn't quote meta
characters in the expansion.  That guarantees that they will be unusable.


    In order for the expansion "{Z..a}" to be usable, the meta characters
need to be quoted in the expansion:

chars=(Z    \[    \\    \]     ^   _     \`    a)


I would assert that for the characters returned by a range that has
metacharacters in it, the metacharacters SHOULD be quoted or they will not
appear in the output.

    If the purpose of the expansion is to enumerate the characters in 
the range,
that is failing because some characters need quoting.

    Having read the first part of brace expansion:

       Brace  expansion is a mechanism by which arbitrary strings may be 
gen-
       erated.  This mechanism is similar  to  pathname  expansion,  
but  the
       filenames  generated  need  not  exist.  Patterns to be brace 
expanded
       take the form of an optional preamble, followed by either a 
series  of
       comma-separated  strings  or  a  sequence expression between a 
pair of
       braces, followed by an optional postscript.

I also would have expected {$'\x01'..$'\x03'} to product
<C-A> <C-B> and <C-C> instead of {<C-A>..<C-C>}, which isn't the case.

I thought it would expand unicode ranges as well, but am not sure.
Unicode in the filenames does work:

>  echo Anime/{Zetusen_no_Tempest\ OST,supercell\ 3rdアルバム 
「ZIGAEXPERIENTIA」}/.
Anime/Zetusen_no_Tempest OST/. Anime/supercell 3rdアルバム 
「ZIGAEXPERIENTIA」/.

It seems the auto increment is unnecessarily limited.

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

unquoted expansion not working (was Re: Not missing, but very hard to see) L A Walsh <bash@tlinx.org> - 2019-12-13 10:25 -0800

csiph-web