[Top][All Lists]

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

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

From: L A Walsh
Subject: unquoted expansion not working (was Re: Not missing, but very hard to see)
Date: Fri, 13 Dec 2019 10:25:15 -0800
User-agent: Thunderbird

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アルバム
Anime/Zetusen_no_Tempest OST/. Anime/supercell 3rdアルバム 「ZIGAEXPERIENTIA」/.

It seems the auto increment is unnecessarily limited.

reply via email to

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