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

[Greg Wooledge]

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.

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 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.

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.