Bug Using Brackets

[Harry Lee]

Hi,

I found a bug when bash parsing brackets with version 5.0.3. Here are some 
outputs:

root@server:~# bash -version
GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
root@server:~# echo [0-1]
1
root@server:~# echo [208174hkjdfsglh0-13984jf0]
1

When I use a old version bash, it's ok:

root@server2:~# bash -version
GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
root@server2:~# echo [0-1]
[0-1]
root@server2:~# echo [208174hkjdfsglh0-13984jf0]
[208174hkjdfsglh0-13984jf0]

Best regards,
Harry Lee

Re: Bug Using Brackets

[Oğuz]

6 Ocak 2021 Çarşamba tarihinde Harry Lee  yazdı:

> Hi,
>
> I found a bug when bash parsing brackets with version 5.0.3. Here are some
> outputs:
>
> root@server:~# bash -version
> GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
> Copyright (C) 2019 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  html>
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> root@server:~# echo [0-1]
> 1
> root@server:~# echo [208174hkjdfsglh0-13984jf0]
> 1
>
> When I use a old version bash, it's ok:
>
> root@server2:~# bash -version
> GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  html>
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> root@server2:~# echo [0-1]
> [0-1]
> root@server2:~# echo [208174hkjdfsglh0-13984jf0]
> [208174hkjdfsglh0-13984jf0]
>

This is not a bug but a feature, namely, _pathname expansion_. Observe:

$ echo [1] 1]
[1] 1]
$
$ touch 1
$ echo [1] 1]
1 1

Best regards,
> Harry Lee



-- 
Oğuz

Re: Bug Using Brackets

[felix]

Hi,

On Wed, Jan 06, 2021 at 11:32:49PM +0800, Harry Lee wrote:

> root@server:~# bash -version
> GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
> Copyright (C) 2019 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> 
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> root@server:~# echo [0-1]
> 1
> root@server:~# echo [208174hkjdfsglh0-13984jf0]
> 1
I use near same version, but can't reproduce:

  $ echo $BASH_VERSION 
  5.0.3(1)-release

  $ echo [0-1]
  [0-1]

Please try this:

  $ LANG=C bash -norc -c 'echo [0-1]'


-- 
 Félix Hauri  --  http://www.f-hauri.ch

Re: Bug Using Brackets

[Harry Lee]

Hi,
On Wed, Jan 06, 2021 at 17:16:26PM +0100, felix wrote:
> I use near same version, but can't reproduce:
> 
>   $ echo $BASH_VERSION 
>   5.0.3(1)-release
> 
>   $ echo [0-1]
>   [0-1]
> 
> Please try this:
> 
>   $ LANG=C bash -norc -c 'echo [0-1]'
It returns the same:

root@server:~# LANG=C bash -norc -c 'echo [0-1]'
1

Thanks for Oğuz, I found that there is a file name `1` in this directory. After 
I removed it, it shows normally:

root@server:~# rm 1
root@server:~# echo [0-1]
[0-1]

On server2 there is no such a file, so it just echo what I input.

This problem doesn't related to the version.

Here's the document: 
https://www.gnu.org/software/bash/manual/bash.html#index-pathname-expansion 


> After word splitting, unless the -f option has been set (see The Set Builtin 
> ), Bash 
> scans each word for the characters ‘*’, ‘?’, and ‘[’. If one of these 
> characters appears, and is not quoted, then the word is regarded as a 
> pattern, and replaced with an alphabetically sorted list of filenames 
> matching the pattern (see Pattern Matching 
> ). If no 
> matching filenames are found, and the shell option nullglob is disabled, the 
> word is left unchanged. If the nullglob option is set, and no matches are 
> found, the word is removed. If the failglob shell option is set, and no 
> matches are found, an error message is printed and the command is not 
> executed. If the shell option nocaseglob is enabled, the match is performed 
> without regard to the case of alphabetic characters.

--
Harry Lee

Re: SIGSEGV in GNU bash, version 5.1.4(1)-release (sparc-sun-solaris2.10)

[Dennis Clarke]

On 1/4/21 7:40 PM, Chet Ramey wrote:
> On 1/4/21 12:07 PM, Vladimir Marek wrote:
>> Hi,
>>
>> As a Solaris bash maintainer this interests me very much. I haven't yet
>> tried to upgrade bash to 5.1.x as there is no immediate need, sorry :)
> 
> You might take a look at the changelog.
> 
>> I'll try to test the new bash on latest Solaris (11.4). What did you
>> do > to observe the issue? Just execute the binary?

Yes. Nothing else required.  However you may run bash --version which is
fine but any attempt to just run "bash" will result in the segfault.

Also, Chet has no access to the real hardware and thus looking at this
on x86 is like looking at the problem with a Raspberry Pi.  Not the same
at all. Perhaps a nightly buildbot would help here? It certainly is a
trivial matter to setup a small zone on an Oracle box here and then let
it run.

Dennis

Re: Bug Using Brackets

[Greg Wooledge]

On Wed, Jan 06, 2021 at 05:16:26PM +0100, felix wrote:
> I use near same version, but can't reproduce:
> 
>   $ echo $BASH_VERSION 
>   5.0.3(1)-release
> 
>   $ echo [0-1]
>   [0-1]

You need to create a file named "1" in the working directory first.
For different results, you could create a file named "0", or create
both of them.