GNU Bash Manual bug: inconsistent definitions

[George Gallo]

Hi GNU,

There appears to be a logical bug in the Bash Manual
.

It claims that an operator is:

"a control operator or a redirection operator. [...] Operators contain at
> least one unquoted metacharacter."


Neat! It also says that a metacharacter "is a blank or one of the following
characters: ‘|’, ‘&’, ‘;’, ‘(’, ‘)’, ‘<’, or ‘>’." Performing parameter
expansion on blank, we see the definition is most completely:

"a space or tab character or one of the following characters: ‘|’, ‘&’, ‘;’,
> ‘(’, ‘)’, ‘<’, or ‘>’."


This creates a problem with the definition of control operator, which is

"a newline or one of the following: ‘||’, ‘&&’, ‘&’, ‘;’, ‘;;’, ‘|’, ‘|&’, ‘
> (’, or ‘)’".


In short, the definition of operator incorrectly implies that, because
newline is a control operator, newline is also a metacharacter.

A proper fix could be to change the definition of operator to be "a control
operator or a redirection operator. [...] Operators contain at least one
unquoted metacharacter or an unquoted newline character."

Thanks for your time,
George Gallo

problem with {Z..a} and backticks

[Stephane Chazelas]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../. -I.././include -I.././lib  -D_FORTIFY_SOURCE=2 -g 
-O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -Wall
uname output: Linux host 3.13.0-55-generic #94-Ubuntu SMP Thu Jun 18 00:27:10 
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.3
Patch Level: 11
Release Status: release

Also reproduced with git head from a couple of weeks ago.

Description:

As {Z..a} includes the ` character, that seems to cause
confusion and can even cause commands to be executed:

$ bash -xc 'echo {Z..a}'
+ echo Z '[' '' ']' '^' _ '`' a
Z [  ] ^ _ ` a

OK (well, see how the backslash between [ and ] was removed), but:

$ bash -xc 'echo {Z..a}x'
bash: bad substitution: no closing "`" in `x

$ bash -xc 'echo {Z..a}uname`id -u`'
++ id -u
++ id -u
++ id -u
++ id -u
++ id -u
++ id -u
++ uname
++ id -u
+ echo Zuname1000 '[uname1000' uname1000 ']uname1000' '^uname1000' _uname1000 
'Linuxid -u`' auname1000
Zuname1000 [uname1000 uname1000 ]uname1000 ^uname1000 _uname1000 Linuxid -u` 
auname1000

See how for `, uname was executed, but not id -u.

Since like ksh93, bash only allows ASCII a-zA-Z for the range
boundaries, it may be better to reject mixed-case ranges like
ksh93 does, or do like zsh and accept any character and sort by
codepoint (may not be possible/desirable the way braces are
expanded early in bash).

-- 
Stephane