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


Groups > gnu.bash.bug > #15702

Re: Backslash missing in brace expansion

From Eric Blake <eblake@redhat.com>
Newsgroups gnu.bash.bug
Subject Re: Backslash missing in brace expansion
Date 2019-12-06 13:36 -0600
Organization Red Hat, Inc.
Message-ID <mailman.429.1575660997.1979.bug-bash@gnu.org> (permalink)
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>

Show all headers | View raw


On 12/5/19 10:53 PM, Martin Schulte wrote:

>>> (2019-11-11) x86_64 GNU/Linux $ echo ${BASH_VERSINFO[@]}
>>> 4 4 12 1 release x86_64-pc-linux-gnu
>>> $ set -x
>>> $ echo {Z..a}
>>> + echo Z '[' '' ']' '^' _ '`' a
>>> Z [  ] ^ _ ` a
>>>
>>> It looks as if the backslash (between [ and ] in ASCII code) is
>>> missing in brace expansion. The same behaviour seems to be found in
>>> bash 5.0.
>>
>> It's an unquoted backslash, which is removed by quote removal when the
>> words are expanded. Look at the extra space between `[' and `]'; that's
>> the null argument resulting from the unquoted backslash.
> 
> Yes - sure. But then I'm wondering why the unquoted backtick doesn't
> start command substitution:

It may be version dependent:

$ echo ${BASH_VERSINFO[@]}
5 0 7 1 release x86_64-redhat-linux-gnu

$ echo b{Z..a}d
bash: bad substitution: no closing "`" in `d

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread


Thread

Re: Backslash missing in brace expansion Eric Blake <eblake@redhat.com> - 2019-12-06 13:36 -0600

csiph-web