Re: . and .. are included where they were excluded before
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 show that the variable is set? Does echo $- show the letter 'f' anywhere? $ declare -p GLOBIGNORE declare -x GLOBIGNORE=".." That's why your .? glob doesn't match the .. pathname. Normally, GLOBIGNORE isn't set. echo $- himBs No f, and GLOBIGNORE stays the same whether I do `shopt -s extglob` or `shopt -u extglob`... So probably ignore my results. But I would like to know what could be wrong with this system/install. You may use the unset builtin to unset the GLOBIGNORE variable, or run bash with the --norc option to obtain the standard behaviour. I find it unlikely that Ubuntu would have chosen to interfere with this variable by default. At any rate, the following command may help you to track down where it's coming from. $ PS4='+$BASH_SOURCE:$LINENO: ' bash -ixlc '' |& less -- Kerin Millar
Re: . and .. are included where they were excluded before
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 echo $- > show the letter 'f' anywhere? $ declare -p GLOBIGNORE declare -x GLOBIGNORE=".." echo $- himBs No f, and GLOBIGNORE stays the same whether I do `shopt -s extglob` or `shopt -u extglob`... So probably ignore my results. But I would like to know what could be wrong with this system/install. Thanks, Peter
Re: . and .. are included where they were excluded before
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 bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) [...] Note that declare -p BASH_VERSION would report the version of bash that you're currently running interactively. $ shopt -s extglob $ echo @(?|.?) @(?|.?) (I don't know, is there something wrong with my bash? Do I have to set other options??) Does declare -p GLOBIGNORE show that the variable is set? Does echo $- show the letter 'f' anywhere? -- Kerin Millar
Re: RFE: new syntax for command substitution to keep trailing newlines?
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 distinguish this as a command instead of a variable.
> In ksh, ${( ... )} is a valid construct of this kind (though it seems
> equivalent to $(...)), so your suggestion actually conflicts with this
> possible future syntax.
Anything using ( ) would suggest something involving a subshell. Maybe
$[{ ... }] or even ${{ ... }} would be clearer?
Peter
Re: . and .. are included where they were excluded before
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)-release (x86_64-pc-linux-gnu) [...] $ shopt -s extglob $ echo @(?|.?) @(?|.?) (I don't know, is there something wrong with my bash? Do I have to set other options??) Peter
Re: RFE: new syntax for command substitution to keep trailing newlines?
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 Schwartz, ksh supports `var=${ listcmd; }`. Sine ksh
> > can do it, this features should be doable in bash?
> [...]
> It's a low priority; if someone wants to take a shot at implementing it
> before I get to looking at it, I'd be happy to merge it in.
In ksh, ${( ... )} is a valid construct of this kind (though it seems
equivalent to $(...)), so your suggestion actually conflicts with this
possible future syntax.
--
Koichi
Re: RFE: new syntax for command substitution to keep trailing newlines?
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?
$(( 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?
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
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 there, and that's what I'll look at. I don't see it as being inconsistent, since shopt -u dotglob will match the literal 1st byte (dot). From there we are no longer looking at "default behavior for "." to match '?' but at normal "glob-RE" rules. .foo won't be match by , but will be matched by .??? Note, it's not just about . and .., all files starting with 1 or 2 dots.
Re: . and .. are included where they were excluded before
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 case. I'm hoping that it was merely a case of making a mistake in the course of performing the tests and assembling the results. That's the thing I said I would look at in my initial message. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: . and .. are included where they were excluded before
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 don't see how this can possibly be the case. I'm hoping that it was merely a case of making a mistake in the course of performing the tests and assembling the results. That's the thing I said I would look at in my initial message. Ah, I see. I'll stop fretting over it then. -- Kerin Millar
Re: . and .. are included where they were excluded before
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 of the patches applied); that version was released more than ten years ago and the changes we're talking about here came in between bash-4.2 and bash-4.3. Thanks, Chet. Still, the original post mentions an anomaly or two that supposedly apply to more recent versions (4.4.19 and 5.0.17) and it is those that have been bothering me especially. I called them out in my original reply. 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 case. I'm hoping that it was merely a case of making a mistake in the course of performing the tests and assembling the results. -- Kerin Millar
Re: . and .. are included where they were excluded before
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. There are patterns that can match `.' and `..'; `.*' still matches both, for instance. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: . and .. are included where they were excluded before
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 was released more than ten years ago and the changes we're talking about here came in between bash-4.2 and bash-4.3. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: . and .. are included where they were excluded before
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 filenames ‘.’ and ‘..’ must always be matched explicitly even if dotglob is set." I don't see any subsequent text that overrules this for extended globs. https://www.gnu.org/software/bash/manual/html_node/Filename-Expansion.html vq Indeed, nor should you... @(?|.?) should never ignore '..', owing to the presence of the .? pattern which explictly matches... -- Kerin Millar you're calling .. an explicit match to .? Yes, I am. It's in line with the various sh(1) implementations also. What makes the pathnames . and .. special is that a glob must begin with a literal dot to match them by way of pathname expansion. That much, I think, is explained adequately by the manual. Enabling dotglob doesn't affect this constraint. 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. I can easily imagine CentOS 7.2 being buggy; not so much in the case of the other two operating systems that you mention. i'd interpret explicit match to mean .. wouldn't match anything other than itself (notwithstanding it's been otherwise for over a decade) In isolation, .. isn't a glob. It won't be subjected to pathname expansion and thus, there's nothing to even 'match'. Rather, it will always be taken literally. Still, I can see how the import of the present wording might not be fully understood upon first reading. Perhaps it could be tweaked a little. but that's a bit askew from what actually interests me. if i had my druthers, there would be an option to set so . and .. would never match any (sub)glob other than their literal selves (even with dotglob set). As Kerin Millar said, you can use GLOBIGNORE for this. indeed that's exactly what i was looking for, thank you lawrence, kerin, and chet -- Kerin Millar
Re: . and .. are included where they were excluded before
> > > . 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 always be >> matched explicitly even if dotglob is set." I don't see any subsequent >> text that overrules this for extended globs. >> https://www.gnu.org/software/bash/manual/html_node/Filename-Expansion.html >> >> vq >> >> > Indeed, nor should you... @(?|.?) should never ignore '..', owing to the > presence of the .? pattern which explictly matches... > > -- > Kerin Millar > > you're calling .. an explicit match to .? i'd interpret explicit match to mean .. wouldn't match anything other than itself (notwithstanding it's been otherwise for over a decade) > but that's a bit askew from what actually interests me. if i had > > my druthers, there would be an option to set so . and .. would never > match > > any (sub)glob other than their literal selves (even with dotglob set). > > As Kerin Millar said, you can use GLOBIGNORE for this. > indeed that's exactly what i was looking for, thank you lawrence, kerin, and chet
Re: . and .. are included where they were excluded before
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)-release (Ubuntu 20.04/focal). is this change in functionality a regression, a "fix", or a new feature? is there any option to exclude them? We're talking about behavior that changed around ten years ago, so there's probably no going back. in all 3, .. is included in .? Yes, basically every shell except mksh does this. The leading dot is matched explicitly. so oddly in centos7 .. is included in .? but excluded from @(?|.?) CentOS is using a version of bash that's over ten years old. and in the more recent versions it's a different inconsistency, . is excluded from ? ?? but included in @(?|.?) 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 there, and that's what I'll look at. but that's a bit askew from what actually interests me. if i had my druthers, there would be an option to set so . and .. would never match any (sub)glob other than their literal selves (even with dotglob set). As Kerin Millar said, you can use GLOBIGNORE for this. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: . and .. are included where they were excluded before
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 .? This seems to be as expected. The pattern must begin with a literal dot in order to match either of the pathnames '.' and '..'. This holds true, irrespective of whether or not dotglob is enabled. Ergo, a pattern of ? should not match the pathname '.', whereas a pattern of .? can - and will - match the pathname '..'. Similarly, a pattern of .* would match both '.' and '..'. According to the manual, "[t]he filenames ‘.’ and ‘..’ must always be matched explicitly even if dotglob is set." I don't see any subsequent text that overrules this for extended globs. https://www.gnu.org/software/bash/manual/html_node/Filename-Expansion.html vq Indeed, nor should you. I would summarise the implications of the report as follows. Firstly, ? should never match '.' because of the constraint described by the sentence preceding the one you quoted. Secondly, the matter of whether a given pattern is contained by a @(pattern-list) should not influence the behaviour of said pattern. In particular, @(?|.?) should never ignore '..', owing to the presence of the .? pattern which explictly matches. The OP has indicated that these two assurances do not collectively hold for the systems on which he is testing (they do for all the systems that I have). Therein lies the rub. -- Kerin Millar
Re: readline crash with custom .inputrc
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 2005. These are the problem key bindings (thanks to Koichi Murase for isolating them): "\C-M-b": backward-word "\C-M-f": forward-word This gives you two multi-character key sequences beginning with ^M (RET), which turns out to matter. just hitting return in interactive mode triggers the segfault. It takes two returns. The sequences of events goes something like this. 1. The user hits return. It's ambiguous, so readline waits for another character to decide what to do. 2. The user hits return. At this point, readline knows that the first ^M means a RET, and, since it's bound to accept-line, cleans things up and returns the (empty) line to the application by calling the line function. 3. As part of its ine processing, the application unregisters the line callback function. 4. Readline notes there is pending input (the second newline), collects it, calls accept-line again, and goes through the process of cleaning up and calling the line handler. Unfortunately, this time, the application has already removed the line handler, and readline attempts to call through a NULL function pointer. This is where the core dump happens. The obvious quick fix is to correct the bad keybindings. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: readline crash with custom .inputrc
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, Mar 13 2020, 21:39:43) [GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>>/*** < Here, hit RET (\C-m) twice ***/ Segmentation fault (core dumped) -- By the way, the key sequence format used in your .inputrc is incorrect. > "\C-M-f": forward-word > "\C-M-b": backward-word Those lines are interpreted as [\C-m (RET)] + ["-" key] + ["f"/"b" key]. They must be "\C-\M-f": forward-word "\C-\M-b": backward-word > "\": kill-line > "\": kill-region > "\": yank Those lines won't be interpreted as you expect. There is no such a way to specify the key by the string "". You need directly specify the corresponding escape sequence that your terminal sends. -- Koichi
Re: . and .. are included where they were excluded before
> 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 expected. The pattern must begin with a literal dot in > order to match either of the pathnames '.' and '..'. This holds true, > irrespective of whether or not dotglob is enabled. > > Ergo, a pattern of ? should not match the pathname '.', whereas a pattern of > .? can - and will - match the pathname '..'. Similarly, a pattern of .* would > match both '.' and '..'. According to the manual, "[t]he filenames ‘.’ and ‘..’ must always be matched explicitly even if dotglob is set." I don't see any subsequent text that overrules this for extended globs. https://www.gnu.org/software/bash/manual/html_node/Filename-Expansion.html vq
readline crash with custom .inputrc
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 just ".inputrc" # place this file in your home dir. e.g. ~/.inputrc # restart your terminal. Then, bash's keybinding for editing # should be like ErgoEmacs. # If no key works, try replace all \e to \M-. That's means change Esc to Meta key. set editing-mode emacs "\M-j": backward-char "\M-l": forward-char "\M-u": backward-word "\C-M-b": backward-word "\M-o": forward-word "\C-M-f": forward-word "\M-g": kill-line "\": kill-line "\M-e": backward-kill-word "\M-r": kill-word "\M-f": delete-char "\C-z": undo "\": kill-region "\M-c": copy-region-as-kill "\": yank "\C-v": yank "\C-f": forward-search-history "\M-:": reverse-search-history just hitting return in interactive mode triggers the segfault.
Re: Feature Request: scanf-like parsing
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 avatar > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > -- Oğuz
