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

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?

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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