Path: csiph.com!3.us.feeder.erje.net!feeder.erje.net!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: L A Walsh Newsgroups: gnu.bash.bug Subject: unquoted expansion not working (was Re: Not missing, but very hard to see) Date: Fri, 13 Dec 2019 10:25:15 -0800 Lines: 127 Approved: bug-bash@gnu.org Message-ID: References: <20191205201157.cd481936f76d95bbdfabc73c@schrader-schulte.de> <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> 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 1576261529 6784 209.51.188.17 (13 Dec 2019 18:25:29 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org To: Eli Schwartz Envelope-to: bug-bash@gnu.org User-Agent: Thunderbird In-Reply-To: <0ff3a920-94c2-b0c9-5631-0964955657aa@archlinux.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: <5DF3D78B.4090208@tlinx.org> X-Mailman-Original-References: <20191205201157.cd481936f76d95bbdfabc73c@schrader-schulte.de> <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> Xref: csiph.com gnu.bash.bug:15727 On 2019/12/12 19:03, Eli Schwartz wrote: > On 12/12/19 9:57 PM, L A Walsh wrote: > =20 >> On 2019/12/12 13:01, Ilkka Virta wrote: >> =20 >>> On 12.12. 21:43, L A Walsh wrote: >>> =20 >>> =20 >>> 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. >>> =20 >>> =20 >> ----- >> >> I'm sorry, but you are mistaken. >> =20 > > How so? > =20 At the time, I read that as the quoting problem being in '6' not in '2'. > =20 >> 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. >> =20 > > But... that's exactly what was said. > =20 ---- Indeed! Apparently, I was misreading their response. > =20 >> 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. >> =20 > > 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 t= o > the printf builtin. > =20 ----- The backslash never existed because it wasn't escaped. I.e. if it wa= s escaped properly (with a backslash before every meta character), then it = would have been safe. =20 > 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 reinterpret= s it? > =20 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=3D(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 no= t appear in the output. If the purpose of the expansion is to enumerate the characters in=20 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, =20 but the filenames generated need not exist. Patterns to be brace=20 expanded take the form of an optional preamble, followed by either a=20 series of comma-separated strings or a sequence expression between a=20 pair of braces, followed by an optional postscript. I also would have expected {$'\x01'..$'\x03'} to product and instead of {..}, 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=E3=82=A2=E3=83=AB=E3= =83=90=E3=83=A0=20 =E3=80=8CZIGAEXPERIENTIA=E3=80=8D}/. Anime/Zetusen_no_Tempest OST/. Anime/supercell 3rd=E3=82=A2=E3=83=AB=E3=83= =90=E3=83=A0=20 =E3=80=8CZIGAEXPERIENTIA=E3=80=8D/. It seems the auto increment is unnecessarily limited.