[Top][All Lists]

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

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

From: L A Walsh
Subject: Re: unquoted expansion not working (was Re: Not missing, but very hard to see)
Date: Sat, 14 Dec 2019 02:48:16 -0800
User-agent: Thunderbird

On 2019/12/13 10:42, Greg Wooledge wrote:
On Fri, Dec 13, 2019 at 10:25:15AM -0800, L A Walsh wrote:
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.

There's a larger issue to be addressed first.  The man page says,

    A  sequence expression takes the form {x..y[..incr]}, where x and y are
    either integers or single characters, and incr, an optional  increment,
    is  an  integer.  When integers are supplied, the expression expands to
    each number between x and y, inclusive.  Supplied integers may be  pre‐
    fixed  with 0 to force each term to have the same width.  When either x
    or y begins with a zero, the shell  attempts  to  force  all  generated
    terms  to  contain the same number of digits, zero-padding where neces‐
    sary.  When characters are supplied, the  expression  expands  to  each
    character  lexicographically  between x and y, inclusive, using the de‐
    fault C locale.

But {x..y} does NOT work for most characters in the first place.
Given that all characters can suggest a range of lexicographically ordered
characters, the fact only sequences in some limited ranges work, is indeed
unfortunate and unexpected.

   I mean I was surprised to see I couldn't generate a range of characters,
at least into an array, though the only real problem I'd thing is that meta
characters aren't quoted.  No reason not to fix that.
wooledg:~$ echo {<..>}
wooledg:~$ echo {:..?}
wooledg:~$ echo {^..|}
bash: syntax error near unexpected token `}'
wooledg:~$ cat }
wooledg:~$ rm }
So, the first issue to be addressed is whether the man page is wrong,
and should say "letters" rather than "characters", or whether the man
page is correct, and the shell should be generating these punctuation
characters as output.
   If it says letters that lends stronger support to including
unicode ranges of letters and numbers since the shell handles unicode and
brace expansions with unicode filenames works just fine.  That ranges don't
seems a bit of a wart.
If Chet decides that the man page's wording is correct, then I agree
with you here.  The generated punctuation characters should be usable
in the same way that generated digits or letters are usable.
That would support not just unicode ranges of letters and numbers, but
the full set.
If on the other hand Chet decides that the man page's wording is not
accurate, then the issue about whether to quote punctuation characters
becomes irrelevant.  The generation of punctuation characters is an
unexpected consequence, and the answer is Don't Do That.
   No -- you don't go backwards -- it could break existing scripts that
use that for one, but two -- are you going to limit it only to every
range of letters and numbers in unicode?  It seems allowing it to work
generally would be easier than trying to only have it work on the multiple
ranges of unicode -- which I'd point out is consistent with bash growing to
be able to use unicode (when it used to not be so), and most features working with unicode.
   May not happen overnight, but a fix to quote meta-chars and allow all
characters, including, _eventually_ 'null' embedded in strings, since that
does happen in the MS world and in C++ where counts instead of zstrings are
more frequently found, but I won't be holding my breath for that result.

reply via email to

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