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

Groups > gnu.bash.bug > #15732 > unrolled thread

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

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

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

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

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 }
> wooledg:~$ 
>
> 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.

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web