[bug #67045] bash parsing error, when using readline, backslashes, and

URL: <https://savannah.gnu.org/bugs/?67045> Summary: bash parsing error, when using readline, backslashes, and Group: The GNU Bourne-Again SHell Submitter: None Submitted: Tue 22 Apr 2025 08:41:19 PM UTC Ca

Re: 5.3.0-beta: readline mishandles prompt with inivisible characters that wraps around

e leftmost screen column. Thanks for the report. The cursor positioning bug is fixed, but the prompt rendering issue is not, and probably won't be for a while. The reason for that is the readline redisplay algorithm doesn't reprint the entire multiline prompt on each input character, and

Re: [PATCH 9/9] doc/bash.1: Resync w/ lib/readline/doc/readline.3.

On 12/31/24 8:33 PM, G. Branden Robinson wrote: At 2024-12-31T13:05:30-0500, Chet Ramey wrote: On 12/30/24 8:16 PM, G. Branden Robinson wrote: Since I maintain six separate documents, the style I choose usually depends on the style for the document where a particular piece of text originates.

5.3.0-beta: readline mishandles prompt with inivisible characters that wraps around

$ PS1="\[$(tput bold)\]\w\\\$\[$(tput sgr0)\] " $ cd /tmp $ for i in 1 2 3 4 5 6 7 8; do mkdir 1234567890; cd 1234567890; done The second line of the prompt is not rendered in bold, and as the edited line gets longer the cursor jumps to the leftmost screen column. -- Andreas Schwab, sch...@linux

Re: [PATCH 9/9] doc/bash.1: Resync w/ lib/readline/doc/readline.3.

At 2024-12-31T13:05:30-0500, Chet Ramey wrote: > On 12/30/24 8:16 PM, G. Branden Robinson wrote: > Since I maintain six separate documents, the style I choose usually > depends on the style for the document where a particular piece of text > originates. Fair, but having different line breaking pra

Re: [PATCH 9/9] doc/bash.1: Resync w/ lib/readline/doc/readline.3.

On 12/30/24 8:16 PM, G. Branden Robinson wrote: Hi Chet, At 2024-12-30T11:23:06-0500, Chet Ramey wrote: On 12/16/24 12:48 PM, G. Branden Robinson wrote: Favor man(7) font selection/alternation macros over roff(7) font selection escape sequences. In general, I don't do this when it makes the

Re: [PATCH 9/9] doc/bash.1: Resync w/ lib/readline/doc/readline.3.

Hi Chet, At 2024-12-30T11:23:06-0500, Chet Ramey wrote: > On 12/16/24 12:48 PM, G. Branden Robinson wrote: > > > Favor man(7) font selection/alternation macros over roff(7) font > > selection escape sequences. > > In general, I don't do this when it makes the man page source and the > texinfo so

Re: [PATCH 9/9] doc/bash.1: Resync w/ lib/readline/doc/readline.3.

On 12/16/24 12:48 PM, G. Branden Robinson wrote: Favor man(7) font selection/alternation macros over roff(7) font selection escape sequences. In general, I don't do this when it makes the man page source and the texinfo source lines align better. There are exceptions. -- ``The lyf so short, t

[PATCH 9/9] doc/bash.1: Resync w/ lib/readline/doc/readline.3.

| 15 ++- lib/readline/doc/readline.3 | 15 ++- 2 files changed, 20 insertions(+), 10 deletions(-) diff --git a/doc/bash.1 b/doc/bash.1 index e82c5329..fc4e054b 100644 --- a/doc/bash.1 +++ b/doc/bash.1 @@ -7537,13 +7537,18 @@ .SS "Readline Command Names" \fBset\-mark\fP com

[PATCH 15/25] lib/readline/doc/*.3: Use local `Q` macro for quotation.

--- lib/readline/doc/history.3 | 8 ++-- lib/readline/doc/readline.3 | 4 +++- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/lib/readline/doc/history.3 b/lib/readline/doc/history.3 index e236bb15..381d1fb5 100644 --- a/lib/readline/doc/history.3 +++ b/lib/readline/doc

[PATCH 13/25] lib/readline/doc/history.3: Use consistent style.

Set `struct _hist_entry` declaration in a constant-width face on typesetters as is already done with `struct _hist_state`. --- lib/readline/doc/history.3 | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/readline/doc/history.3 b/lib/readline/doc/history.3 index 09d5ee21..e236bb15 100644

[PATCH 12/25] lib/readline/doc/history.3: Silence groff warning.

...without interfering with the test for DWB man(7) we do subsequently. Fixes: $ nroff -ww -z -man ./lib/readline/doc/history.3 troff:./lib/readline/doc/history.3:29: warning: register ')Y' not defined --- lib/readline/doc/history.3 | 1 + 1 file changed, 1 insertion(+) diff -

[PATCH 06/25] doc/bash.1: Resync with lib/readline/doc/readline.3.

00644 --- a/doc/bash.1 +++ b/doc/bash.1 @@ -7232,9 +7232,9 @@ .SS "Readline Command Names" The text between the point and mark is referred to as the \fIregion\fP. .B Readline has the concept of an \fIactive region\fP: -when the region is active, \fBreadline\fP redisplay uses the -value o

Re: [PATCH] lib/readline/doc makefiles clean targets

On 11/18/24 10:28 PM, Grisha Levit wrote: This is one of the differences between the distributions and the devel branch. y.tab.h is always in $(srcdir) in distributions, and the Makefiles accommodate them in favor of the devel branch. Could we install INSTALLED_HEADERS the same way as CREATED_

Re: [PATCH] lib/readline/doc makefiles clean targets

On Wed, Nov 13, 2024 at 11:13 AM Chet Ramey wrote: > > On 11/12/24 7:18 PM, Grisha Levit wrote: > > > The latest change, > > > > +Makefile.in > > + - y.tab.h: move from CREATED_HEADERS to INSTALLED_HEADERS so we don't > > + clean it > > > > makes the install-headers target fail for an out-of-tree

Re: [PATCH] lib/readline/doc makefiles clean targets

On 11/14/24 4:23 AM, Mike Jonkmans wrote: On Mon, Nov 11, 2024 at 03:30:53PM -0500, Chet Ramey wrote: 6) There is redundancy/duplication in the actions of various rules; OK. 6) Same for the definitions of variables. Examples? There is duplication in the top Makefile on the various lib sou

Re: [PATCH] lib/readline/doc makefiles clean targets

On Mon, Nov 11, 2024 at 03:30:53PM -0500, Chet Ramey wrote: > On 11/8/24 4:15 PM, Mike Jonkmans wrote: > > > > 2) The use of recursive make, makes it harder to do dependencies right; > > > It's the best way to build using optional components and subdirectories. > > I have my doubts here. There are

Re: [PATCH] lib/readline/doc makefiles clean targets

On Thu, 7 Nov 2024, Chet Ramey wrote: > y.tab.h isn't part of the devel branch, you need bison to build it, and > it is included in the bash distributions. I see the problem here, though. > I'll figure out a way to fix it that's compatible with it being included > and not without too many releas

Re: [PATCH] lib/readline/doc makefiles clean targets

On 11/12/24 7:18 PM, Grisha Levit wrote: The latest change, +Makefile.in + - y.tab.h: move from CREATED_HEADERS to INSTALLED_HEADERS so we don't + clean it makes the install-headers target fail for an out-of-tree build since y.tab.h is in $(BUILD_DIR) but INSTALLED_HEADERS are only looked for

Re: [PATCH] lib/readline/doc makefiles clean targets

On Thu, Nov 7, 2024 at 6:06 PM Chet Ramey wrote: > > On 11/4/24 9:44 AM, Mike Jonkmans wrote: > > > There are some issues though. Some less important. > > 1) After 'make distclean', it doesn't build: some .o files need y.tab.h. > > y.tab.h isn't part of the devel branch, you need bison to build it

Re: [PATCH] lib/readline/doc makefiles clean targets

On Thu, Nov 7, 2024 at 6:06 PM Chet Ramey wrote: > > If you find yourself in this sitution, it's easy enough to remove > parser-built and y.tab.c and run make again before I fix it. $ git clean -xfdq In MSYS2 on Windows, all the generated executables end in ".exe", which of course the .gitignore

Re: [PATCH] lib/readline/doc makefiles clean targets

restore . ./configure make mostlyclean git status Shows several lines of 'deleted: doc/bashref.*' Those are the files resulting from texinfo creating the dvi files from the texinfo source. They are not part of the bash distribution. We talked about them earlier.

Re: [PATCH] lib/readline/doc makefiles clean targets

ng some problems with building outside the source. I shall give that another try. > > Misc notes > > - examples/loadables/Makefile(.in) has no mostlyclean target. > >The error is ignored, but clutters the output. > ? > $ grep mostlyclean examples/loadables/Makefile.in > m

Re: [PATCH] lib/readline/doc makefiles clean targets

On 11/4/24 9:44 AM, Mike Jonkmans wrote: According to info (make)Standard Targets, we should have: mostlyclean < clean < distclean < maintainer-clean That hierarchy isn't gospel. Agreed, but... The current Makefile rules are fine. There are some issues though. Some less important. 1)

Re: [PATCH] lib/readline/doc makefiles clean targets

> > > > > If I run, on devel (4917f285): > > > > - ./configure > > > > - make > > > > - make clean > > > > - git status > > > > > > > > I would expect to see nothing special. > > > > Instead: > > > >

Re: [PATCH] lib/readline/doc makefiles clean targets

whole bunch of files got deleted in lib/readline/doc. Yeah. Those files aren't part of the bash distribution, and so they get cleaned. I left them there the last couple of pushes because I wanted people to get a look at the documentation updates I made. It was easier for me than splitting the

Re: [PATCH] lib/readline/doc makefiles clean targets

ould expect to see nothing special. > > Instead: > > a) a whole bunch of files got deleted in lib/readline/doc. > > Yeah. Those files aren't part of the bash distribution, and so they get > cleaned. I left them there the last couple of pushes because I wanted > people to

Re: [PATCH] lib/readline/doc makefiles clean targets

On 10/29/24 1:04 PM, Mike Jonkmans wrote: Hi Chet et al., If I run, on devel (4917f285): - ./configure - make - make clean - git status I would expect to see nothing special. Instead: a) a whole bunch of files got deleted in lib/readline/doc. Yeah. Those files aren't part of the

[PATCH] lib/readline/doc makefiles clean targets

Hi Chet et al., If I run, on devel (4917f285): - ./configure - make - make clean - git status I would expect to see nothing special. Instead: a) a whole bunch of files got deleted in lib/readline/doc. b) an untracked file appears: buildconf.h The patch addresses a). Not sure what to do about b

Re: Signal handling by readline

On 9/30/24 4:43 PM, Elad Lahav wrote: Applications that don't want readline to do this can disable it, at a cost. But it is still the case that bash makes many redundant system calls on every line entered. Is setting rl_catch_signals to 0 in bash going to have any adverse effects? That

Re: Signal handling by readline

Thanks for taking the time to respond. On Mon, Sep 30, 2024 at 4:19 PM Chet Ramey wrote: > Bash isn't the only application using readline. Most applications using > it don't do anything special with the job control signals. Bash, being > a job control shell, is of c

Re: Signal handling by readline

On 9/29/24 2:36 PM, Elad Lahav wrote: Hello, I was chasing an issue with bash signal handling on QNX, when I noticed that, whenever you hit enter, the readline library does the following for a few signals: 1. Install a new signal handler via sigaction() 2. Check the previous handler, as

Signal handling by readline

Hello, I was chasing an issue with bash signal handling on QNX, when I noticed that, whenever you hit enter, the readline library does the following for a few signals: 1. Install a new signal handler via sigaction() 2. Check the previous handler, as returned by this call 3. If it is SIG_IGN

Re: Readline Documentation

On Fri, Sep 13, 2024 at 3:24 PM Chet Ramey wrote: > > > I considered that maybe it > > would only do this in response to being set directly, but neither > > ~/.bashrc nor /etc/bash.bashrc on my system include it, nor any other > > file I can find. Unless this has been changed between that version

Re: Readline Documentation

On 9/14/24 2:45 PM, G. Branden Robinson wrote: At 2024-09-13T15:24:15-0400, Chet Ramey wrote: It has no effects in its default state. If you don't change it, nothing happens. If you change it, you change `bell-style' instead. The fact that its usage continues suggests documenting it as depreca

Re: Readline Documentation

At 2024-09-13T15:24:15-0400, Chet Ramey wrote: > It has no effects in its default state. If you don't change it, nothing > happens. If you change it, you change `bell-style' instead. > > > The fact that its usage continues suggests documenting it as > > deprecated would be beneficial. > > Maybe.

Re: Readline Documentation

On 9/13/24 11:00 AM, John Devin wrote: As you said, it's been deprecated -- and undocumented -- for over 30 years (and remains only for backwards compatibility). There's no reason to document it. I understand it's been superseded, but I do want to point this out: running `bind -v` in bash 5.2

Re: Readline Documentation

'. It took me some time looking into this > > before finding out it was deprecated in favor of 'bell-style' about 20 > > years ago, per: > > https://lists.gnu.org/archive/html/bug-bash/2016-02/msg00186.html. > > As the last line in that message says, it was never docu

Re: Readline Documentation

It took me some time looking into this before finding out it was deprecated in favor of 'bell-style' about 20 years ago, per: https://lists.gnu.org/archive/html/bug-bash/2016-02/msg00186.html. As the last line in that message says, it was never documented. Readline didn't reall

Readline Documentation

Hello all, Sorry in advance if this is poorly formatted; I used plain-text mode in gmail but who knows if that works properly. While hunting down some problems on a terminal, I ran across the option 'prefer-visible-bell'. It took me some time looking into this before finding out it was deprecated

Re: return from trap while reading with readline breaks completion

On 8/6/24 4:19 AM, Oğuz wrote: See: $ ls foo s $ cat s trap return INT read -e $ source s I press Ctrl-C here and bash prompts me for the next command. Then I press F and Tab; instead of producing the bell sound bash completes f to foo. If I press Ctrl-C again it prints "bash: return: can only

return from trap while reading with readline breaks completion

See: $ ls foo s $ cat s trap return INT read -e $ source s I press Ctrl-C here and bash prompts me for the next command. Then I press F and Tab; instead of producing the bell sound bash completes f to foo. If I press Ctrl-C again it prints "bash: return: can only `return' from a function or sour

Re: [PATCH 06/13] lib/readline/doc/history.3: Drop microtypography.

On 4/2/24 4:33 AM, G. Branden Robinson wrote: At 2024-04-01T09:27:27-0400, Chet Ramey wrote: On 3/28/24 5:11 PM, G. Branden Robinson wrote: Now that we're using a correct caret/circumflex/hat glyph on modern typesetters (and terminals with a Unicode repertoire), drop the thicket of partial-line

Re: [PATCH 06/13] lib/readline/doc/history.3: Drop microtypography.

At 2024-04-01T09:27:27-0400, Chet Ramey wrote: > On 3/28/24 5:11 PM, G. Branden Robinson wrote: > > Now that we're using a correct caret/circumflex/hat glyph on > > modern typesetters (and terminals with a Unicode repertoire), drop the > > thicket of partial-line motion and type size-altering escap

Re: [PATCH 06/13] lib/readline/doc/history.3: Drop microtypography.

On 3/28/24 5:11 PM, G. Branden Robinson wrote: Now that we're using a correct caret/circumflex/hat glyph on modern typesetters (and terminals with a Unicode repertoire), drop the thicket of partial-line motion and type size-altering escape sequences, certain to frighten and confuse any unfrozen c

[PATCH 10/13] lib/readline/doc/history.3: Make `EX` and `EE` man(7) macros usable on DWB troff.

ot;\eb\"\ef\"" - $endif + $if Bash + # Quote the current or previous word + "\C-xq": "\eb\"\ef\"" + $endif variable --- lib/rea

[PATCH 07/13] lib/readline/doc/history.3: Fix hyphen-minus signs.

Use a *roff minus sign for minus signs and the `-` character in email addresses. --- lib/readline/doc/history.3 | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/readline/doc/history.3 b/lib/readline/doc/history.3 index 30b4d7be..40b85b20 100644 --- a/lib/readline

[PATCH 09/13] lib/readline/doc/history.3: Revise inline struct.

platforms supporting this Ninth Edition Unix/groff man(7) extension, and does nothing elsewhere. --- lib/readline/doc/history.3 | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/lib/readline/doc/history.3 b/lib/readline/doc/history.3 index 7b6ab73b..d36c454d 100644

[PATCH 04/13] lib/readline/doc/history.3: Replace blank lines with macro calls.

n.tmac:lib/readline/doc/history.3:xxx: style: blank line in input --- lib/readline/doc/history.3 | 93 +++--- 1 file changed, 46 insertions(+), 47 deletions(-) diff --git a/lib/readline/doc/history.3 b/lib/readline/doc/history.3 index 266d91f6..76703833 100644 --- a/lib/re

[PATCH 08/13] lib/readline/doc/history.3: Fix font thinko.

Replace no-op font selection escape sequence with what appears to have been intended. --- lib/readline/doc/history.3 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/readline/doc/history.3 b/lib/readline/doc/history.3 index 40b85b20..7b6ab73b 100644 --- a/lib/readline/doc

[PATCH 05/13] lib/readline/doc/history.3: Fix style minutia.

the event line. + G Apply the following “s” or “&” modifier once to each word in the +event line. Fixes (from "nroff -rCHECKSTYLE=3 -man" using groff 1.23.0): an.tmac:lib/readline/doc/history.3:73: style: .BR expects at least 2 arguments, got 1 an.tmac:lib/read

[PATCH 06/13] lib/readline/doc/history.3: Drop microtypography.

ghtly regress the quality of output on AT&T nroff and troff (DWB and Solaris 10) when sending output to a line printer or other device capable of half-line motions, and to typesetters. The dropped escape sequences have never had effect on character-cell video terminals. --- lib/readline/doc/

[PATCH 01/13] lib/readline/doc/history.3: Fix failure to render on DWB and Solaris 10 troff.

iers are only two characters maximum in AT&T roff. Because a macro named `1` was never subsequently called, the entire remainder of the page got scooped into a never-ending macro definition and would not render. --- lib/readline/doc/history.3 | 74 +++--- 1 file

[PATCH 03/13] lib/readline/doc/history.3: Drop spacing around (sub)section headings.

space after a (sub)section heading is nonidiomatic. Fixes numerous style warnings from "nroff -rCHECKSTYLE=3 -man" in groff 1.23.0 of the following form. an.tmac:lib/readline/doc/history.3:xxx: style: blank line in input --- lib/readline/doc/history.3 | 13 - 1 file changed, 13

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On Tue, Feb 6, 2024 at 3:07 PM Chet Ramey wrote: > This is more like sourcing a file with `set -v' temporarily enabled (in > fact, it's very close to that). > Can't imagine POSIX would be amenable to all the 'set -v' output lines being prepended with PS2s, but that actually suffers from the same

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

mands when the first line is changed. Ah, I see: you want any "lines" that readline returns that contain embedded newlines to be parsed as a compound_list instead of a series of newline- terminated commands (what bash calls a simple_list). Kind of like they had been enclosed in braces.

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On 2/3/24 10:18 PM, Zachary Santer wrote: While I'm making feature requests. I hit C-x C-e and enter the following into my editor: var='duck' declare -p var (   var='squirrel'   declare -p var ) declare -p var I save that and exit my editor, and this is what I get in the terminal: zsant@Za

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On Tuesday, February 6, 2024, Chet Ramey wrote: > > What's the specific request here? > That bash interpret multiline commands retrieved from command history as a whole and not run the rest of the lines as separate commands when the first line is changed. Try it yourself; run a multiline command,

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On 2/3/24 10:43 PM, Oğuz wrote: I want to make one too. Multiline commands retrieved from history can be short-circuited like this: $ ls x y $ echo ' > rm * > ' >z $ $ ls x y z $ echo '' rm * ' >z > ^C $ ls $ After the second invocation of `ls' I a

Re: Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On Sunday, February 4, 2024, Zachary Santer wrote: > > While I'm making feature requests. > I want to make one too. Multiline commands retrieved from history can be short-circuited like this: $ ls x y $ echo ' > rm * > ' >z $ $ ls x y z $ echo '' rm * ' >z > ^C $ ls

Feature request: prompt strings in output from edit-and-execute-command readline function ( was About `M-C-e` expand result `'` failed )

On Fri, Feb 2, 2024 at 4:21 PM Chet Ramey wrote: > OK, I'll take that as a feature request for a future version. > While I'm making feature requests. I hit C-x C-e and enter the following into my editor: var='duck' declare -p var ( var='squirrel' declare -p var ) declare -p var I save tha

Re: Add example of bind readline-command-line

On 12/12/23 9:06 AM, Dan Jacobson wrote: bash man page says -v Display readline variable names and values in such a way that they can be re-read. Perhaps add an example of rereading via the bind command: $ bind 'set bell-style visible' els

Re: Add example of bind readline-command-line

On Tue, Dec 12, 2023 at 10:06:49PM +0800, Dan Jacobson wrote: > bash man page says > -v Display readline variable names and values in such a way > that they can be re-read. > Perhaps add an example of rereading via the bind command: The m

Add example of bind readline-command-line

bash man page says -v Display readline variable names and values in such a way that they can be re-read. Perhaps add an example of rereading via the bind command: $ bind 'set bell-style visible' else the user might try: $ echo set bell-style visibl

Re: Bug in readline when readline-colored-completion-prefix is set

On 11/29/23 11:32 AM, raphaal wrote: Hi all, My version of bash is: GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu) When the .inputrc contains: > colored-completion-prefix on and LS_COLORS="*.readline-colored-completion-prefix=01;30" then readline ignores the set

Bug in readline when readline-colored-completion-prefix is set

Hi all, My version of bash is: GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu) When the .inputrc contains: > colored-completion-prefix on and LS_COLORS="*.readline-colored-completion-prefix=01;30" then readline ignores the setting and uses default CYAN color. After

Re: readline: double free when using PageDown

On 11/25/23 8:19 PM, Grisha Levit wrote: On Sat, Nov 25, 2023, 14:03 Chet Ramey > wrote: On 11/25/23 11:41 AM, Matthias Klose wrote: > [forwarded from https://bugs.debian.org/1056314 ] > > """ > I am gett

Re: readline: double free when using PageDown

On 26.11.23 02:19, Grisha Levit wrote: On Sat, Nov 25, 2023, 14:03 Chet Ramey wrote: On 11/25/23 11:41 AM, Matthias Klose wrote: [forwarded from https://bugs.debian.org/1056314] """ I am getting a crash in the Python REPL in this scenario: 1. start "python3" in a terminal 2. type "2+2", ent

Re: readline: double free when using PageDown

On Sat, Nov 25, 2023, 14:03 Chet Ramey wrote: > On 11/25/23 11:41 AM, Matthias Klose wrote: > > [forwarded from https://bugs.debian.org/1056314] > > > > """ > > I am getting a crash in the Python REPL in this scenario: > > > > 1. start "python3" in a terminal > > 2. type "2+2", enter > > 3. type

Re: readline: double free when using PageDown

On 11/25/23 11:41 AM, Matthias Klose wrote: [forwarded from https://bugs.debian.org/1056314] """ I am getting a crash in the Python REPL in this scenario: 1. start "python3" in a terminal 2. type "2+2", enter 3. type (or copy-paste) "1234+5678", enter 4. arrow-up, remove "234", page-down, arrow

readline: double free when using PageDown

e-down, arrow-up, enter 5. arrow-up, arrow-up, add "000" (or whatever) after the 1, enter. this results in: free(): double free detected in tcache 2 [1]2319820 IOT instruction python3 """ this can be reproduced as well when entering these in bash. readline is 8.2 patchlevel 7, bash is 5.2 patchlevel 21.

Re: Some Readline variables are not available in "bind -v"

On 7/16/23 9:25 AM, Sebastian Carlos wrote: Hello, I noticed that the following variables are not visible in "bind -v": - active-region-start-color - active-region-end-color Thanks for the report. These two variables aren't reported by `bind -v' if they have a value, so that needs to be fixed.

Some Readline variables are not available in "bind -v"

Hello, I noticed that the following variables are not visible in "bind -v": - active-region-start-color - active-region-end-color - isearch-terminators Thanks for your time.

Re: [PATCH] Save more readline state when running compgen

On 3/22/23 4:33 PM, Koichi Murase wrote: Do you think calling `compgen', which leaves the state of `compopt -o filenames', etc., outside the bindable function `compete' would affect any behaviors? That's more or less the question. It's not that compgen leaves modifi

Re: [PATCH] Save more readline state when running compgen

ere. > > So is your function suite dependent on the compgen invocations changing > the readline completion state? I mean the function itself does not rely on the compgen, but I call compgen through such a function so the compgen would be executed in the main shell. If I understand thi

Re: [PATCH] Save more readline state when running compgen

ldn't say my usage is typical, but I do that in fact. I have a shell function to do that for an arbitrary command (which I once posted in help-bash [1] but now it's old. The latest is [2]) and use it everywhere. So is your function suite dependent on the compgen invocations changi

Re: [PATCH] Save more readline state when running compgen

2023年3月22日(水) 6:00 Greg Wooledge : > I don't use programmable completion, but I could *imagine* someone using > a temp file to store the results, then using mapfile to read them back > in, to avoid the fork() that the command substitution uses. I wouldn't say my usage is typical, but I do that in

Re: [PATCH] Save more readline state when running compgen

On Tue, Mar 21, 2023 at 5:52 PM alex xmb ratchev wrote: > On Tue, Mar 21, 2023, 22:42 Grisha Levit wrote: >> Let's say you want to know if there are any entries starting with >> `foo' in the current directory. You can do: > > i see , thank you sir > i .. mostly dont have that case ( if existing

Re: [PATCH] Save more readline state when running compgen

On Tue, Mar 21, 2023, 22:42 Grisha Levit wrote: > On Tue, Mar 21, 2023 at 5:26 PM alex xmb ratchev > wrote: > > On Tue, Mar 21, 2023, 21:05 Grisha Levit wrote: > >> > >> compgen -G 'foo/*' >/dev/null && COMPREPLY=(bar) > > > > i dont get that code at all , but i like idea of speedier file filli

Re: [PATCH] Save more readline state when running compgen

On Tue, Mar 21, 2023 at 5:26 PM alex xmb ratchev wrote: > On Tue, Mar 21, 2023, 21:05 Grisha Levit wrote: >> >> compgen -G 'foo/*' >/dev/null && COMPREPLY=(bar) > > i dont get that code at all , but i like idea of speedier file filling .. can > u explain some in short ? Let's say you want to kn

Re: [PATCH] Save more readline state when running compgen

On Tue, Mar 21, 2023, 21:05 Grisha Levit wrote: > On Tue, Mar 21, 2023 at 3:47 PM Chet Ramey wrote: > > OK, say you did in fact run compgen in the foreground -- very unusual > > because it's awkward to capture the possible completions that way -- to > > generate completions. > > Sorry I should h

Re: [PATCH] Save more readline state when running compgen

On Tue, Mar 21, 2023, 21:05 Grisha Levit wrote: > On Tue, Mar 21, 2023 at 3:47 PM Chet Ramey wrote: > > OK, say you did in fact run compgen in the foreground -- very unusual > > because it's awkward to capture the possible completions that way -- to > > generate completions. > > Sorry I should h

Re: [PATCH] Save more readline state when running compgen

e foreground so it's > hard for me to imagine a use case that benefits from the readline > state being modified. I don't use programmable completion, but I could *imagine* someone using a temp file to store the results, then using mapfile to read them back in, to avoid the for

Re: [PATCH] Save more readline state when running compgen

cified with `complete -C') so nothing persists anyway, right? I don't know if there's really any use case that generates completions to place into COMPREPLY by running compgen in the foreground so it's hard for me to imagine a use case that benefits from the readline state being modified.

Re: [PATCH] Save more readline state when running compgen

On 3/21/23 4:04 PM, Grisha Levit wrote: On Tue, Mar 21, 2023 at 3:47 PM Chet Ramey wrote: OK, say you did in fact run compgen in the foreground -- very unusual because it's awkward to capture the possible completions that way -- to generate completions. Sorry I should have explained. I hit th

Re: [PATCH] Save more readline state when running compgen

On Tue, Mar 21, 2023 at 3:47 PM Chet Ramey wrote: > OK, say you did in fact run compgen in the foreground -- very unusual > because it's awkward to capture the possible completions that way -- to > generate completions. Sorry I should have explained. I hit this issue because I was using compgen i

Re: [PATCH] Save more readline state when running compgen

On 3/19/23 10:08 PM, Grisha Levit wrote: Completion state is not fully restored after invoking `compgen' within a competition function. Normally, if a compspec does not specifically include one of the options that triggers filename completion, the generated completions are not treated as filenam

[PATCH] Save more readline state when running compgen

Completion state is not fully restored after invoking `compgen' within a competition function. Normally, if a compspec does not specifically include one of the options that triggers filename completion, the generated completions are not treated as filenames: $ complete -W '/tmp /var' cmd $ cmd /[

Re: bash-5.2.9 lib/readline/input.c fix for Tru64

On 11/15/22 7:25 PM, Koichi Murase wrote: 2022年11月16日(水) 0:11 Chet Ramey : It should be possible to simulate a machine like this by manually editing config.h after running configure. You are right. There are three more places to fix in addition to the two in the previous reply (see the attache

Re: bash-5.2.9 lib/readline/input.c fix for Tru64

On Tue, 15 Nov 2022 at 20:02, Koichi Murase wrote: > 2022年11月16日(水) 9:36 Koichi Murase : > > > > 2022年11月16日(水) 0:18 Henry Bent : > > > There is a free Alpha emulator here: > > > http://www.migrationspecialties.com/FreeAXP.html . I haven't used > > > it extensively since I have real hardware but

Re: bash-5.2.9 lib/readline/input.c fix for Tru64

2022年11月16日(水) 9:36 Koichi Murase : > > 2022年11月16日(水) 0:18 Henry Bent : > > There is a free Alpha emulator here: > > http://www.migrationspecialties.com/FreeAXP.html . I haven't used > > it extensively since I have real hardware but it seems to work > > reasonably well. > > Thank you for the info

Re: bash-5.2.9 lib/readline/input.c fix for Tru64

2022年11月16日(水) 0:18 Henry Bent : > There is a free Alpha emulator here: > http://www.migrationspecialties.com/FreeAXP.html . I haven't used > it extensively since I have real hardware but it seems to work > reasonably well. Thank you for the information. I tried to install Tru64 5.1b in FreeAXP,

Re: bash-5.2.9 lib/readline/input.c fix for Tru64

e64-v2.patch). -- Koichi From 863f054d126e0e6481e94a3f193e6e982d2b70f3 Mon Sep 17 00:00:00 2001 From: Koichi Murase Date: Tue, 15 Nov 2022 11:32:01 +0900 Subject: [PATCH] fix for HAVE_PSELECT in Tru64 https://lists.gnu.org/archive/html/bug-bash/2022-11/msg00044.html --- lib/readline/input.

Re: bash-5.2.9 lib/readline/input.c fix for Tru64

On Tue, 15 Nov 2022 at 10:11, Chet Ramey wrote: > On 11/14/22 10:01 PM, Koichi Murase wrote: > > > I think someone needs to finally check the fixed version actually > > compiles in a real Tru64 machine. I attach a possible patch > > [202211-0044.HAVE_PSELECT-in-True64.patch] but haven't tested it

Re: bash-5.2.9 lib/readline/input.c fix for Tru64

On 11/14/22 10:01 PM, Koichi Murase wrote: 2022年11月15日(火) 9:04 Henry Bent : In bash-5.2.9 if HAVE_SELECT is set but HAVE_PSELECT is not, we still need the "fd_set readfds;" at line 808 in lib/readline/input.c. Found on Tru64 5.1. This seems to be reported repeatedly for differen

Re: bash-5.2.9 lib/readline/input.c fix for Tru64

On 11/14/22 6:56 AM, Henry Bent wrote: Also this platform doesn't have strtoimax but config.h is still setting #define HAVE_DECL_STRTOIMAX 1 #define HAVE_DECL_STRTOLL 1 #define HAVE_DECL_STRTOULL 1 #define HAVE_DECL_STRTOUMAX 1 even though later on it correctly realizes that HAVE_STRTOLL, HAVE

Re: bash-5.2.9 lib/readline/input.c fix for Tru64

2022年11月15日(火) 9:04 Henry Bent : > In bash-5.2.9 if HAVE_SELECT is set but HAVE_PSELECT is not, we still need > the "fd_set readfds;" at line 808 in lib/readline/input.c. Found on Tru64 > 5.1. This seems to be reported repeatedly for different lines in the source code. ht

Re: Should the readline *-meta flags reset when $LANG changes?

urrently, a temporal change of TERM clears keybindings of some > >>> keys (home, end, right, left, etc.) even when the temporal change does > >>> not survive across multiple calls of readline: > >> > >> I finally got back to look at this, and I couldn't repro

Re: Should the readline *-meta flags reset when $LANG changes?

when the temporal change does not survive across multiple calls of readline: I finally got back to look at this, and I couldn't reproduce it. That was expected, since the arrow key binding functions are pretty careful not to overwrite an existing binding. Then I figured out what was goi

Re: Should the readline *-meta flags reset when $LANG changes?

On 8/11/22 5:56 PM, Koichi Murase wrote: Can we also change the behavior of TERM in a similar way with option 4? Currently, a temporal change of TERM clears keybindings of some keys (home, end, right, left, etc.) even when the temporal change does not survive across multiple calls of readline

  1   2   3   4   5   6   >