Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: L A Walsh Newsgroups: gnu.bash.bug Subject: Re: unquoted expansion not working (was Re: Not missing, but very hard to see) Date: Sat, 14 Dec 2019 02:48:16 -0800 Lines: 104 Approved: bug-bash@gnu.org Message-ID: References: <662e2328-f331-c554-afcf-fd3819f6beab@case.edu> <20191206055304.076d6115afa3a4f2a6a21c34@schrader-schulte.de> <5b5064a8-7175-42e7-1eb5-6374dee6c11e@redhat.com> <21761e28-c496-ff67-d7b7-628c9325085f@iki.fi> <9dd3a388-39b1-c059-de99-813f1e411764@case.edu> <5DF2987E.5000309@tlinx.org> <568aeaaa-22b3-c7b9-0e18-a92bef6d2ffb@iki.fi> <5DF2FE31.9070406@tlinx.org> <0ff3a920-94c2-b0c9-5631-0964955657aa@archlinux.org> <5DF3D78B.4090208@tlinx.org> <20191213184213.GO851@eeg.ccf.org> <5DF4BDF0.6000402@tlinx.org> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1576320507 4087 209.51.188.17 (14 Dec 2019 10:48:27 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org User-Agent: Thunderbird In-Reply-To: <20191213184213.GO851@eeg.ccf.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 173.164.175.65 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <5DF4BDF0.6000402@tlinx.org> X-Mailman-Original-References: <662e2328-f331-c554-afcf-fd3819f6beab@case.edu> <20191206055304.076d6115afa3a4f2a6a21c34@schrader-schulte.de> <5b5064a8-7175-42e7-1eb5-6374dee6c11e@redhat.com> <21761e28-c496-ff67-d7b7-628c9325085f@iki.fi> <9dd3a388-39b1-c059-de99-813f1e411764@case.edu> <5DF2987E.5000309@tlinx.org> <568aeaaa-22b3-c7b9-0e18-a92bef6d2ffb@iki.fi> <5DF2FE31.9070406@tlinx.org> <0ff3a920-94c2-b0c9-5631-0964955657aa@archlinux.org> <5DF3D78B.4090208@tlinx.org> <20191213184213.GO851@eeg.ccf.org> Xref: csiph.com gnu.bash.bug:15732 On 2019/12/13 10:42, Greg Wooledge wrote: > On Fri, Dec 13, 2019 at 10:25:15AM -0800, L A Walsh wrote: > =20 >> 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. >> =20 > > 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 increm= ent, > is an integer. When integers are supplied, the expression expand= s to > each number between x and y, inclusive. Supplied integers may be = pre=E2=80=90 > fixed with 0 to force each term to have the same width. When eith= er x > or y begins with a zero, the shell attempts to force all gener= ated > terms to contain the same number of digits, zero-padding where ne= ces=E2=80=90 > sary. When characters are supplied, the expression expands to = each > character lexicographically between x and y, inclusive, using the= de=E2=80=90 > fault C locale. > > But {x..y} does NOT work for most characters in the first place. > =20 --- Given that all characters can suggest a range of lexicographically=20 ordered characters, the fact only sequences in some limited ranges work, is indee= d unfortunate and unexpected. I mean I was surprised to see I couldn't generate a range of characte= rs, at least into an array, though the only real problem I'd thing is that me= ta 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:~$=20 > > 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. =20 > =20 ---- 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. > =20 ---- 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. > =20 ----- 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 multipl= e 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=20 working with unicode.=20 May not happen overnight, but a fix to quote meta-chars and allow all= characters, including, _eventually_ 'null' embedded in strings, since tha= t does happen in the MS world and in C++ where counts instead of zstrings a= re more frequently found, but I won't be holding my breath for that result.