Problem with 'upper' class when nocaseglob

The version number of Bash: GNU bash, version 4.4.11(1)-release The hardware and operating system: x86_64-pc-linux-gnu, Debian GNU/Linux 9 A description of the bug behaviour: When the nocaseglob option is set, the [:upper:] class in pattern does not match capital or small letters. On

bash 4.4 - (readline) regression in the behaviour of ^W in vi-mode

* Please cc me as I'm not subscribed. Hello all, this is a copy of Debian bug 838437 [0]. I'm posting it here because I failed to find it mentioned in the ml archives. Please disregard if it's been already reported. --- $ set -o vi $ echo REMOVE maintain With bash-4.3-15 I can recall and m

Re: Problem with 'upper' class when nocaseglob

On Thu, Mar 02, 2017 at 10:57:57PM +0100, Luká?? Ba??inka wrote: > A short script or ???recipe??? which exercises the bug and may be used > to reproduce it: >$ touch a A >$ echo [[:upper:]] >A >$ shopt -s nocaseglob >$ echo [[:lower:]] >a A >$ echo [[:upper:]] >[[:up

Re: bash 4.4 - (readline) regression in the behaviour of ^W in vi-mode

On 3/3/17 5:47 AM, Gian Piero Carrubba wrote: > * Please cc me as I'm not subscribed. > > Hello all, > > this is a copy of Debian bug 838437 [0]. I'm posting it here because I > failed to find it mentioned in the ml archives. Please disregard if it's > been already reported. It seems related to

default PS1 is not POSIX-compliant?

Chet, can you weigh in on http://austingroupbugs.net/view.php?id=1038 ? There is a question of whether bash's choice of setting PS1='\s-\v\$ ' is correct in --posix mode, or whether it should be merely PS1='\$ ' when started in sh mode. Allowing more than just the dollar (or hash for root) and spa

Re: Problem with 'upper' class when nocaseglob

On 3/2/17 4:57 PM, Lukáš Bařinka wrote: > A description of the bug behaviour: >When the nocaseglob option is set, the [:upper:] class in pattern >does not match capital or small letters. On the other hand, >[:lower:] works fine. Thanks for the report. Character class name matching sho

Re: default PS1 is not POSIX-compliant?

On 3/3/17 10:31 AM, Eric Blake wrote: > Chet, can you weigh in on http://austingroupbugs.net/view.php?id=1038 ? > There is a question of whether bash's choice of setting PS1='\s-\v\$ ' > is correct in --posix mode, or whether it should be merely PS1='\$ ' > when started in sh mode. Allowing more t

Re: bash 4.4 - (readline) regression in the behaviour of ^W in vi-mode

* Please cc me as I'm not subscribed. * [Fri, Mar 03, 2017 at 09:38:04AM -0500] Chet Ramey: On 3/3/17 5:47 AM, Gian Piero Carrubba wrote: Hello all, this is a copy of Debian bug 838437 [0]. I'm posting it here because I failed to find it mentioned in the ml archives. Please disregard if it's b

Full-width characters can result in an unwanted space in filenames

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

'history -c' does not reset current line to 1

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

Pipe using subshells, variables not saved

Variables are not saved when using a pipe because both sides are in a subshell environment. A common place where a user may encounter this is when dealing with multiple items: bash bug?? > > Does not change the value of $new: > > echo hi| for i in 3; do new=3; done > > > reason for piping: > echo