[PATCH 6/8] doc/bash.1: use page-local `FN` macro for file name

The page defines it; might as well use it. --- doc/bash.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/bash.1 b/doc/bash.1 index 8943e01e..fff8a817 100644 --- a/doc/bash.1 +++ b/doc/bash.1 @@ -2107,7 +2107,7 @@ .SS Shell Variables This variable expands to a 32-bit

[PATCH 7/8] doc/bash.1: make code displays more portable

1. Use `EX`/`EE` extension. groff_man(7): .EX .EEBegin and end example. After .EX, filling is disabled and a constant‐width (monospaced) font is selected. Calling .EE enables filling and restores the previous font. .EX and .EE are extensions

[PATCH 5/8] doc/bash.1: add man page cross references

Cross-reference arc4random(3) and stty(1) man pages. Protect the former from hyphenation. Also break an input line after a sentence. --- doc/bash.1 | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/doc/bash.1 b/doc/bash.1 index f532d628..8943e01e 100644 ---

[PATCH 8/8] doc/bash.1: fix erroneous escape sequences

troff:doc/bash.1:10090: warning: ignoring escape character before '+' troff:doc/bash.1:11896: warning: ignoring escape character before 'P' --- doc/bash.1 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/bash.1 b/doc/bash.1 index 35c076f0..9d44a6d4 100644 ---

completion very slow with gigantic list

Hi, I noticed bash struggles with gigantic completion lists (100k items of ~70 chars each) It's reproducible with both LANG+LC_ALL set to en_US.UTF-8 and C, so it's not just locales slowing things down. This happens on the up-to-date `devel' branch (commit

[PATCH 3/8] doc/bash.1: define and use "Q" quotation macro

...instead of assuming the availability of a font named `CW`, and using inconsistent quotation conventions when rendering to terminals with nroff(1). This resolves 25 instances of the following warning from groff 1.23.0. troff:./doc/bash.1:360: warning: cannot select font 'CW' To extract the

[PATCH 1/8] doc/bash.1: use consistent inter-paragraph spacing

Historically in man(7), the inter-paragraph spacing (equivalently, the spacing before section and subsection headings, and the value of the PD register) is 0.4v (or four tenths of a "vee", the distance between vertically adjacent text baselines) on typesetters, and 1v on terminals (that is, a

[PATCH 0/8] doc/bash.1: silence groff warnings, fix style issues

With this series of changes, bash(1) formats quiescently for me using groff 1.23.0 with the following command line. nroff -ww -rCHECKSTYLE=1 -man -z doc/bash.1 Regards, Branden signature.asc Description: PGP signature

[PATCH 4/8] doc/bash.1: make quoted trailing spaces unbreakable

By luck, at present, input like times, as necessary, to indicate multiple levels of indirection. The default is .Q "+\ " . does not get set as times, as necessary, to indicate multiple levels of indirection. The default is “+ ”. by any of groff {1.22.4,1.23.0,git}, mandoc, Heirloom Doctools,

[PATCH 2/8] doc/bash.1: fix unescaped hyphens

--- doc/bash.1 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/bash.1 b/doc/bash.1 index 8c2fa229..ed67e4b0 100644 --- a/doc/bash.1 +++ b/doc/bash.1 @@ -6132,7 +6132,7 @@ .SS "Readline Variables" treated specially by the kernel's terminal driver to their readline

Re: completion very slow with gigantic list

Eric Wong writes: > Hi, I noticed bash struggles with gigantic completion lists > (100k items of ~70 chars each) A priori, it isn't surprising. But the question becomes "What algorithmic improvement to bash would make this work faster?" and then "Who will write this code?" Dale

Re: Bash 5.2.21 segfaults when I feed it garbage

On Mon, Jan 8, 2024 at 4:41 PM Chet Ramey wrote: > I think there's a simpler > way to fix it in parse_compound_assignment and parse_string_to_word_list > directly, and that change will be in the next devel branch push. Rewriting the original report as: bash <<<'((X=([))' even after the

Re: completion very slow with gigantic list

"Dale R. Worley" wrote: > A priori, it isn't surprising. But the question becomes "What > algorithmic improvement to bash would make this work faster?" and then > "Who will write this code?" I'll try to take a look at it in a few months if I run out of things to do and nobody beats me to it.

Re: Bash 5.2.0: Memory leak with $(

On Mon, Jan 8, 2024, 12:26 wrote: > Do any of the other six patches in that report also apply to Bash 5.2? > Yes, all but the one for the `kv' builtin which did not exist yet. See attached. > From 711ab85262884f2b91f09eceb9aefd0e2426ce67 Mon Sep 17 00:00:00 2001 From: Grisha Levit Date: Sat,

Re: bash-4-2 issue

On Wed, Jan 10, 2024 at 5:33 PM Grisha Levit wrote: > I'm not sure this is fixed. In all versions, including 4.2 [...] > > $ bash -m -c 'trap /usr/bin/true DEBUG; :|:' > bash: child setpgid (49581 to 49579): Operation not permitted Correction, versions prior to 4.3 did not respect the -m

Re: bash-4-2 issue

On Mon, Jan 8, 2024 at 7:04 AM Sam Kappen via Bug reports for the GNU Bourne Again SHell wrote: > We see that bash throws the "Operation not permitted" error when doing > chained pipe operation > along with a debug trap. > > We set a debug trap here "my_debug" to save the terminal commands

document that read built-in can't return zero-length string in the middle of input

Dear. I needed to read 16 bytes from a binary file and tried to replace a hexdump call with read built-in. I expected that with "-N1" if a NUL character is encountered bash would assign an empty string, however there's no indication that a NUL character was there and it simply assigns the next