Re: . and .. are included where they were excluded before

2021-01-26 Thread
On 27/01/2021 07:38, pepa65 wrote: On 27/01/2021 14.30, k...@plushkava.net wrote: Note that declare -p BASH_VERSION would report the version of bash that you're currently running interactively. $ declare -p BASH_VERSION declare -- BASH_VERSION="5.0.17(1)-release" Does declare -p GLOBIGNORE s

Re: . and .. are included where they were excluded before

2021-01-26 Thread pepa65
On 27/01/2021 14.30, k...@plushkava.net wrote: > Note that declare -p BASH_VERSION would report the version of bash that > you're currently running interactively. $ declare -p BASH_VERSION declare -- BASH_VERSION="5.0.17(1)-release" > Does declare -p GLOBIGNORE show that the variable is set? Does

Re: . and .. are included where they were excluded before

2021-01-26 Thread
On 27/01/2021 06:50, pepa65 wrote: On 27/01/2021 04.00, k...@plushkava.net wrote: One example is that gregrwm claims the following outcome for 5.0.17(1) in Ubuntu 20.04:-   $   echo @(?|.?)  #. and .. are included . .. a .b $ cat /etc/issue Ubuntu 20.04.1 LTS \n \l $ bash --version GNU

Re: RFE: new syntax for command substitution to keep trailing newlines?

2021-01-26 Thread pepa65
On 27/01/2021 12.57, Koichi Murase wrote: > There was already a discussion to use ${ command } for no-fork command > substitutions as ksh does. I would find that syntax very confusing, as ${var} is used to access variables, so then only the starting space (and the ending semicolon) would distingui

Re: . and .. are included where they were excluded before

2021-01-26 Thread pepa65
On 27/01/2021 04.00, k...@plushkava.net wrote: > One example is that gregrwm claims the following outcome for 5.0.17(1) > in Ubuntu 20.04:- > >   $   echo @(?|.?)  #. and .. are included > . .. a .b $ cat /etc/issue Ubuntu 20.04.1 LTS \n \l $ bash --version GNU bash, version 5.0.17(1)-releas

Re: RFE: new syntax for command substitution to keep trailing newlines?

2021-01-26 Thread Koichi Murase
2021年1月27日(水) 12:15 Clark Wang : > For example, we can use ${( ... )} which is now wrong syntax. There was already a discussion to use ${ command } for no-fork command substitutions as ksh does. > From https://lists.gnu.org/archive/html/help-bash/2020-05/msg00077.html > > > According to Eli Schwa

Re: RFE: new syntax for command substitution to keep trailing newlines?

2021-01-26 Thread Oğuz
What's wrong with printing an `x' at the end and removing it later? -- Oğuz

Re: RFE: new syntax for command substitution to keep trailing newlines?

2021-01-26 Thread Alex fxmbsw7 Ratchev
$(( is math output as (( <( and >( keep data On Wed, Jan 27, 2021, 05:15 Clark Wang wrote: > For example, we can use ${( ... )} which is now wrong syntax. > > $ v=${( command ... )} > bash: ${( command ... )}: bad substitution >

RFE: new syntax for command substitution to keep trailing newlines?

2021-01-26 Thread Clark Wang
For example, we can use ${( ... )} which is now wrong syntax. $ v=${( command ... )} bash: ${( command ... )}: bad substitution

Re: . and .. are included where they were excluded before

2021-01-26 Thread L A Walsh
On 2021/01/26 09:08, Chet Ramey wrote: That's the real question: whether or not `.' should match @(?|.?), even when dotglob is enabled (and yes, both patterns have to be in there). There isn't really any other. Since it doesn't match ? when dotglob is enabled, there's an obvious inconsistency th

Re: . and .. are included where they were excluded before

2021-01-26 Thread Chet Ramey
On 1/26/21 4:00 PM, k...@plushkava.net wrote: One example is that gregrwm claims the following outcome for 5.0.17(1) in Ubuntu 20.04:-   $   echo @(?|.?)  #. and .. are included . .. a .b Note that '.' is said to be among the pathnames matched. I don't see how this can possibly be the c

Re: . and .. are included where they were excluded before

2021-01-26 Thread
On 26/01/2021 21:13, Chet Ramey wrote: On 1/26/21 4:00 PM, k...@plushkava.net wrote: One example is that gregrwm claims the following outcome for 5.0.17(1) in Ubuntu 20.04:-    $   echo @(?|.?)  #. and .. are included . .. a .b Note that '.' is said to be among the pathnames matched. I d

Re: . and .. are included where they were excluded before

2021-01-26 Thread
On 26/01/2021 20:49, Chet Ramey wrote: On 1/26/21 3:27 PM, k...@plushkava.net wrote: I'm still worried about some of the curious results shown by your original post but I haven't had a chance to test the same platforms yet. Don't be. CentOS is running a version of bash-4.2 (without even all o

Re: . and .. are included where they were excluded before

2021-01-26 Thread Chet Ramey
On 1/26/21 2:34 PM, gregrwm wrote: you're calling .. an explicit match to .? Yes: the leading `.' is explicitly included. i'd interpret explicit match to mean .. wouldn't match anything other than itself (notwithstanding it's been otherwise for over a decade) That's not a glob pattern. The

Re: . and .. are included where they were excluded before

2021-01-26 Thread Chet Ramey
On 1/26/21 3:27 PM, k...@plushkava.net wrote: I'm still worried about some of the curious results shown by your original post but I haven't had a chance to test the same platforms yet. Don't be. CentOS is running a version of bash-4.2 (without even all of the patches applied); that version wa

Re: . and .. are included where they were excluded before

2021-01-26 Thread
On 26/01/2021 19:34, gregrwm wrote: . and .. are excluded from @(?|.?) in bash 4.2.46(2)-release (CentOS 7.8), but are included in bash 4.4.19(1)-release (CentOS 8.2) and bash 5.0.17(1)-release (Ubuntu 20.04/focal). According to the manual, "[t]he fil

Re: . and .. are included where they were excluded before

2021-01-26 Thread gregrwm
> > > . and .. are excluded from @(?|.?) in > > bash 4.2.46(2)-release (CentOS 7.8), but are included in > > bash 4.4.19(1)-release (CentOS 8.2) and > > bash 5.0.17(1)-release (Ubuntu 20.04/focal). > According to the manual, "[t]he filenames ‘.’ and ‘..’ must al

Re: . and .. are included where they were excluded before

2021-01-26 Thread Chet Ramey
On 1/25/21 4:36 PM, gregrwm wrote: Bash Version: 5.0 Patch Level: 17 Release Status: release Description: . and .. are excluded from @(?|.?) in bash 4.2.46(2)-release (CentOS 7.8), but are included in bash 4.4.19(1)-release (CentOS 8.2) and bash 5.0.17(1)-rel

Re: . and .. are included where they were excluded before

2021-01-26 Thread
On 26/01/2021 13:04, Lawrence Velázquez wrote: On Jan 26, 2021, at 12:51 AM, "" wrote: On 25/01/2021 21:36, gregrwm wrote: is this change in functionality a regression, a "fix", or a new feature? is there any option to exclude them? in all 3, .. is included in .?

Re: readline crash with custom .inputrc

2021-01-26 Thread Chet Ramey
On 1/26/21 7:33 AM, Matthias Klose wrote: This was reported for Debian in https://bugs.debian.org/968703 for the interactive Python interpreter, however I also see it with gdb, e.g. trying to run ls in gdb. readline 8.1 is in use. This one has been around ever since the callback code came in in

Re: readline crash with custom .inputrc

2021-01-26 Thread Koichi Murase
2021年1月26日(火) 20:34 Matthias Klose : > This was reported for Debian in https://bugs.debian.org/968703 for the > interactive Python interpreter, > [...] > just hitting return in interactive mode triggers the segfault. Reduced-Case: $ cat .inputrc "\ra": self-insert $ python3 Python 3.7.7 (default,

Re: . and .. are included where they were excluded before

2021-01-26 Thread Lawrence Velázquez
> On Jan 26, 2021, at 12:51 AM, "" > wrote: > >> On 25/01/2021 21:36, gregrwm wrote: >> >> is this change in functionality a regression, a "fix", or a new >> feature? >> is there any option to exclude them? >> in all 3, .. is included in .? > > This seems to be as expe

readline crash with custom .inputrc

2021-01-26 Thread Matthias Klose
This was reported for Debian in https://bugs.debian.org/968703 for the interactive Python interpreter, however I also see it with gdb, e.g. trying to run ls in gdb. readline 8.1 is in use. $ cat .inputrc # Based on Brendan Miller's initial bash .inputrc # INSTALL # to install, rename this file to

Re: Feature Request: scanf-like parsing

2021-01-26 Thread Oğuz
25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı: > On 1/25/21 12:58 PM, Oğuz wrote: > > I rarely use eval, but when I do, it works just fine. >> > > Someone should create a meme with this text superimposed on an image of the > Dos Equis most interesting man in the world. > Heh. Made it my avat