Re: Bug tracking

On Tue, 2 Apr 2024 at 00:31, Chet Ramey wrote: > On 3/31/24 8:34 PM, Martin D Kealey wrote: > > That's a good start, but it seems incomplete, and there's little -- > perhaps > > no -- overlap with bug reports in this list. > And this is still the most fundamental problem;

Re: [bug #65827] Cross-compilation fails with gcc 14.1.0

On 6/3/24 08:30, Chet Ramey wrote: On 6/2/24 9:43 AM, Brett Neumeier wrote: ./configure --build=x86_64-unknown-linux-gnu --host=aarch64-cbl-linux-gnu --enable-static-link --without-bash-malloc I get this failure: [...] If I add "#include " to tparam.c, it

Re: [bug #65827] Cross-compilation fails with gcc 14.1.0

On 6/2/24 9:43 AM, Brett Neumeier wrote: ./configure --build=x86_64-unknown-linux-gnu --host=aarch64-cbl-linux-gnu --enable-static-link --without-bash-malloc I get this failure: --- aarch64-cbl-linux-gnu-gcc -c -I/home/lbl/work/sysroot/scaffolding/include -DHAVE_CONFIG_H -I. -I../..

[bug #65827] Cross-compilation fails with gcc 14.1.0

URL: Summary: Cross-compilation fails with gcc 14.1.0 Group: The GNU Bourne-Again SHell Submitter: bneumeier Submitted: Sun 02 Jun 2024 01:43:53 PM UTC Category: None

Re: yet another $(case ... parse bug

On 5/24/24 1:43 AM, Oğuz wrote: While you're at it take a look at this too: true; for (( ; $? == 0; ${ ! break;} )); do uname; done The arithmetic for command should probably check for breaking after it evaluates the loop test. You have to admit this is not something people are going to write

Re: yet another $(case ... parse bug

On 5/23/24 1:19 PM, Oğuz wrote: See: $ bash -c 'for (( $(case x in x) esac);; )); do :; done' bash: -c: line 1: syntax error: `;' unexpected bash: -c: line 1: syntax error: `(( $(case x in x) ;; esac);; ))' Thanks for the report. This should be a pretty easy fix; just use

Re: yet another $(case ... parse bug

While you're at it take a look at this too: true; for (( ; $? == 0; ${ ! break;} )); do uname; done Once you run this command bash gets stuck in a state where it prints the prompt string and reads commands but doesn't execute anything. If you press Ctrl+C it returns to normal. Oğuz

yet another $(case ... parse bug

See: $ bash -c 'for (( $(case x in x) esac);; )); do :; done' bash: -c: line 1: syntax error: `;' unexpected bash: -c: line 1: syntax error: `(( $(case x in x) ;; esac);; ))' This is reproducible on 5.3 alpha too. Oğuz

Re: bug in bash

On 5/14/24 11:12 AM, Chet Ramey wrote: On 5/14/24 10:20 AM, Andreas Schwab wrote: On Mai 14 2024, Chet Ramey wrote: Setting the process group might solve this particular issue, at the cost of losing keyboard-generated signals. That's not so bad for SIGINT, though people do expect to be able

Re: bug in bash

On 5/14/24 10:20 AM, Andreas Schwab wrote: On Mai 14 2024, Chet Ramey wrote: Setting the process group might solve this particular issue, at the cost of losing keyboard-generated signals. That's not so bad for SIGINT, though people do expect to be able to kill a procsub when you interrupt the

Re: bug in bash

On Mai 14 2024, Chet Ramey wrote: > Setting the process group might solve this particular issue, at the cost of > losing keyboard-generated signals. That's not so bad for SIGINT, though > people do expect to be able to kill a procsub when you interrupt the job > using it, but you also wouldn't be

Re: bug in bash

On 5/13/24 3:37 PM, Oğuz wrote: On Monday, May 13, 2024, Chet Ramey > wrote: performs the setpgid in the process forked to run the process substitution). Yes, this sounds like the easy way. I don't know how else to prevent the race in OP. Close

Re: bug in bash

On Monday, May 13, 2024, Chet Ramey wrote: > performs the setpgid in the process forked > to run the process substitution). > Yes, this sounds like the easy way. I don't know how else to prevent the race in OP. Close stdin/stdout? Direct it from /dev/null? -- Oğuz

Re: bug in bash

On 5/12/24 10:00 AM, Oğuz wrote: On Sun, May 12, 2024 at 4:33 PM Andreas Schwab wrote: Since the redirection fails and the cat command is never started, bash doesn't switch the terminal process group It does on my computer: 554 ioctl(255, TIOCSPGRP, [554]) = 0 553

Re: bug in bash

On Mai 12 2024, Greg Wooledge wrote: > Ah... I assumed bk was an existing file. > > hobbit:~$ cat <(wc -l) <.bashrc > wc: 'standard input': Input/output error > 0 > hobbit:~$ Even then there can be a race when the foreground command finishes fast enough that bash switches the terminal process

Re: bug in bash

On Sun, May 12, 2024 at 4:33 PM Andreas Schwab wrote: > Since the redirection fails and the cat command is never started, bash > doesn't switch the terminal process group It does on my computer: 554 ioctl(255, TIOCSPGRP, [554]) = 0 553 execve("/usr/bin/wc", ["wc", "-l"], 0x55706d7bac10

Re: bug in bash

On Sun, May 12, 2024 at 03:33:12PM +0200, Andreas Schwab wrote: > > On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > >> I found a bug when i tried with syntax <(cmd). this is an example > >> cat <(wc -l) < bk > Since the redirection fails and th

Re: bug in bash

On Mai 12 2024, Greg Wooledge wrote: > On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: >> I found a bug when i tried with syntax <(cmd). this is an example >> cat <(wc -l) < bk > > What is "wc -l" supposed to read from? It counts lines o

Re: bug in bash

On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > I found a bug when i tried with syntax <(cmd). this is an example > cat <(wc -l) < bk What is "wc -l" supposed to read from? It counts lines of standard input, until EOF is reached. But its standard input i

Re: bug in bash

On Sun, 12 May 2024 03:55:21 +0200 Quốc Trị Đỗ wrote: > Hi, > > I found a bug when i tried with syntax <(cmd). this is an example > cat <(wc -l) < bk > > You can follow this command, then you have bugs. I think because you > created a fork getting inside in the pa

Re: bug in bash

On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote: > Hi, > > I found a bug when i tried with syntax <(cmd). this is an example > cat <(wc -l) < bk > > You can follow this command, then you have bugs. I think because you > created a fork getting inside i

bug in bash

Hi, I found a bug when i tried with syntax <(cmd). this is an example cat <(wc -l) < bk You can follow this command, then you have bugs. I think because you created a fork getting inside in the parenthesis and the main process do < bk. They work parallel. Because of that, yeah.

(Just making sure this went through.) Bug: Bash is not memory safe.

$ bash --version | head -n1 GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu) $ valgrind --leak-check=full \ --track-origins=yes \ --verbose \ --log-file=valgrind-out-bash.txt \ /bin/bash ==2762== Memcheck, a memory error detector ==2762== Copyright

[bug #65670] Bash is not memory safe.

URL: Summary: Bash is not memory safe. Group: The GNU Bourne-Again SHell Submitter: None Submitted: Wed 01 May 2024 11:39:28 PM UTC Category: None Severity: 3

Re: Bug#1069978: bash: incorrect value of $BASH for login shells

On 4/28/24 6:18 PM, Gioele Barabucci wrote: On 28/04/24 22:50, Chet Ramey wrote: On 4/28/24 3:07 PM, Gioele Barabucci wrote: $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; head -1z /proc/$$/cmdline; echo' /bin/bash /usr/bin/bash-static

Re: Bug#1069978: bash: incorrect value of $BASH for login shells

On 28/04/24 22:50, Chet Ramey wrote: On 4/28/24 3:07 PM, Gioele Barabucci wrote: $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; head -1z /proc/$$/cmdline; echo' /bin/bash /usr/bin/bash-static -bash-static So argv[0] == "-bash-static", which

Re: Bug#1069978: bash: incorrect value of $BASH for login shells

On 4/28/24 3:07 PM, Gioele Barabucci wrote:     $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; head -1z /proc/$$/cmdline; echo'     /bin/bash     /usr/bin/bash-static     -bash-static So argv[0] == "-bash-static", which causes $0 to be set to -bash-static and

Re: Bug#1069978: bash: incorrect value of $BASH for login shells

On 28/04/24 20:01, Chet Ramey wrote: On 4/27/24 6:23 PM, Gioele Barabucci wrote: bash 5.0 and 5.2 do not set $BASH to the right value when bash is used as the login shell: $ apt install bash-static $ getent passwd $USER | cut -d: -f 7 /bin/bash $ su $USER -s

Re: [bug #65651] argument reference inconsistency

On 4/28/24 1:10 PM, Lawrence Velázquez wrote: On Sun, Apr 28, 2024, at 7:59 AM, Emanuele Torre wrote: I don't know why this savannah ticket has been crossposted to @bug-bash, but its replies have not been crossposted here: it is very confusing. Apparently it's not possible to have the replies

Re: [bug #65651] argument reference inconsistency

On 4/28/24 7:59 AM, Emanuele Torre wrote: I don't know why this savannah ticket has been crossposted to @bug-bash, but its replies have not been crossposted here: it is very confusing. Because savannah can't do that. The original request was to have one place to go to for bug reports

Re: [bug #65651] argument reference inconsistency

On Sun, Apr 28, 2024, at 7:59 AM, Emanuele Torre wrote: > I don't know why this savannah ticket has been crossposted to @bug-bash, > but its replies have not been crossposted here: it is very confusing. Apparently it's not possible to have the replies crossposted: https://savannah.g

Re: [bug #65651] argument reference inconsistency

On Sun, Apr 28, 2024, 13:59 Emanuele Torre wrote: > I don't know why this savannah ticket has been crossposted to @bug-bash, > but its replies have not been crossposted here: it is very confusing. > cool , thanks ... btw got me the link ? thxx && bless Anyway, they alrea

Re: [bug #65651] argument reference inconsistency

I don't know why this savannah ticket has been crossposted to @bug-bash, but its replies have not been crossposted here: it is very confusing. Anyway, they already got a response on savannah. o/ emanuele6

Re: [bug #65651] argument reference inconsistency

On Sun, Apr 28, 2024, 08:52 anonymous wrote: > URL: > > > Summary: argument reference inconsistency >Group: The GNU Bourne-Again SHell >Submitter: None >Submitted: Sun 28 Apr 2024

[bug #65651] argument reference inconsistency

URL: Summary: argument reference inconsistency Group: The GNU Bourne-Again SHell Submitter: None Submitted: Sun 28 Apr 2024 06:51:44 AM UTC Category: None

Bug#1069978: bash: incorrect value of $BASH for login shells

Package: bash Version: 5.2.21-2 X-Debbugs-CC: bug-bash@gnu.org Hi, bash 5.0 and 5.2 do not set $BASH to the right value when bash is used as the login shell: $ apt install bash-static $ getent passwd $USER | cut -d: -f 7 /bin/bash $ su $USER -s /bin/bash-static -c 'echo

[bug #65638] Make error: two or more data types in declaration specifiers

URL: Summary: Make error: two or more data types in declaration specifiers Group: The GNU Bourne-Again SHell Submitter: None Submitted: Wed 24 Apr 2024 07:32:32 PM UTC

Bug#973620: bash: overflow on integer variables greater than 9223372036854775807

Control: found -1 5.2.21-2 Control: tags -1 upstream X-Debbugs-CC: bug-bash@gnu.org On Mon, 2 Nov 2020 16:46:14 +0100 Antonio wrote: Dear Maintainer, recently while I was running some tests, I ran into this strange overflow: $ declare -i n=9223372036854775800; for((i=0; i<15; ++i)); do e

Bug#306043: bash executable completion doesn't work if there is a space in the executable path

Control: found -1 5.2.21-2 Control: tags -1 upstream X-Debbugs-CC: bug-bash@gnu.org On Sat, 23 Apr 2005 15:20:19 -0700 Frederik Eaton wrote: Bash executable completion doesn't work if there is a space in the executable path. This issue is still partially present in current version of Bash

Re: Bug tracking

On 4/1/24 5:30 AM, Koichi Murase wrote: Perhaps bug tracking could be migrated to a more modern system? I think a more realistic solution for GNU is to improve Savane, which is also an open-source project: https://savannah.nongnu.org/projects/administration/ That is a GNU project decision

Re: Bug tracking

On 3/31/24 8:34 PM, Martin D Kealey wrote: On Mon, 11 Dec 2023, 05:19 Chet Ramey, <mailto:chet.ra...@case.edu>> wrote: On 11/30/23 5:18 AM, Martin D Kealey wrote: > If there's a bug tracking system beyond "threads in a mailing list", I'd > like to

Re: Bug tracking

2024年4月1日(月) 9:35 Martin D Kealey : > On Mon, 11 Dec 2023, 05:19 Chet Ramey, wrote: > > On 11/30/23 5:18 AM, Martin D Kealey wrote: > > > If there's a bug tracking system beyond "threads in a mailing list", I'd > > > like to know how I can get access to

Re: Bug tracking

On Monday, April 1, 2024, Martin D Kealey wrote: > On Mon, 11 Dec 2023, 05:19 Chet Ramey, wrote: > Are we building a cathedral with gatekeepers, or a bazaar > where the masses can contribute? > What's stopping masses from contributing now? All you need is an email address. And why this

Bug tracking

On Mon, 11 Dec 2023, 05:19 Chet Ramey, wrote: > On 11/30/23 5:18 AM, Martin D Kealey wrote: > > > If there's a bug tracking system beyond "threads in a mailing list", I'd > > like to know how I can get access to it. > > https://savannah.gnu.org/support

Debian bug #929178: wrong trap displayed inside functions

On Tuesday, March 26, 2024, Martin D Kealey wrote: > > When forwarding incoming HTML to a text-only list, most mailing list > servers will put the hyperlinks in a footnote, so that that long links > won't obscure the text they apply to. (The better ones only do this when > text text and its

Re: Debian bug #929178: wrong trap displayed inside functions

On Tue, 26 Mar 2024 at 04:05, Oğuz wrote: > On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson > wrote: > > [1] > > [1] http... > > I keep seeing this. Why don't you guys just paste the link? > When forwarding incoming HTML to a text-only list, most mailing list servers will put the

Re: Debian bug #929178: wrong trap displayed inside functions

On 3/25/24 3:47 PM, Gioele Barabucci wrote: On 25/03/24 18:13, Oğuz wrote: On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci > wrote:  > Just for reference, neither dash nor busybox sh preserve the caller's trap: I don't know why you think they are relevant. Because

Re: Debian bug #929178: wrong trap displayed inside functions

On 3/25/24 11:45 AM, Gioele Barabucci wrote: Hi, I'm forwarding a minor issue originally reported in . If a function does not set a trap, `trap` will output the command set by the caller. This is just a cosmetic issue, the right trap will be run at runtime.

Re: Debian bug #929178: wrong trap displayed inside functions

On 25/03/24 18:13, Oğuz wrote: On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci > wrote: > Just for reference, neither dash nor busybox sh preserve the caller's trap: I don't know why you think they are relevant. Because they are two very commonly used /bin/sh, and

Re: Debian bug #929178: wrong trap displayed inside functions

At 2024-03-25T21:05:02+0300, Oğuz wrote: > On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson > wrote: > > [1] > > [1] http... > > I keep seeing this. Why don't you guys just paste the link? I believe I am. https://lists.gnu.org/archive/html/bug-bash/2024-03/msg0020

Re: Debian bug #929178: wrong trap displayed inside functions

On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson wrote: > [1] > [1] http... I keep seeing this. Why don't you guys just paste the link?

Re: Debian bug #929178: wrong trap displayed inside functions

At 2024-03-25T19:13:39+0200, Oğuz wrote: > On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci wrote: > > Just for reference, neither dash nor busybox sh preserve the > > caller's trap: > > I don't know why you think they are relevant. dash doesn't even support > `x=$(trap)', which is mandated by

Debian bug #929178: wrong trap displayed inside functions

On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci wrote: > Just for reference, neither dash nor busybox sh preserve the caller's trap: I don't know why you think they are relevant. dash doesn't even support `x=$(trap)', which is mandated by POSIX to work; and busybox sh is a bare-bones shell for

Re: Debian bug #929178: wrong trap displayed inside functions

On 25/03/24 17:12, Oğuz wrote: On Monday, March 25, 2024, Gioele Barabucci > wrote: If a function does not set a trap, `trap` will output the command set by the caller. This is just a cosmetic issue, the right trap will be run at runtime. Doesn't POSIX

Debian bug #929178: wrong trap displayed inside functions

On Monday, March 25, 2024, Gioele Barabucci wrote: > > If a function does not set a trap, `trap` will output the command set by > the caller. This is just a cosmetic issue, the right trap will be run at > runtime. > Doesn't POSIX allow this? How else do you propose we save the trap set for an

Debian bug #929178: wrong trap displayed inside functions

Hi, I'm forwarding a minor issue originally reported in . If a function does not set a trap, `trap` will output the command set by the caller. This is just a cosmetic issue, the right trap will be run at runtime. To reproduce this issue: #!/bin/bash

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

On 3/22/24 2:02 AM, Gioele Barabucci wrote: For various reasons. First of all, because it confuses users (there are various bug reports in Debian for this specific issue). More technically, because non-builtin commands are treated differently, for example /bin/echo (from <ht

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

; ...`). Then he should do `trap '' PIPE' before the loop. it is incorrect that > SIGPIPE terminates the subshell. Why? For various reasons. First of all, because it confuses users (there are various bug reports in Debian for this specific issue). More technically, because non-builtin comma

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

the loop. it is incorrect that > SIGPIPE terminates the subshell. Why? For various reasons. First of all, because it confuses users (there are various bug reports in Debian for this specific issue). More technically, because non-builtin commands are treated differently, for example /bin/e

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

On 3/21/24 12:13 PM, Gioele Barabucci wrote: When bash runs a builtin command without forking, it should install a SIGPIPE handler that will cause that signal to abort the command but not terminate the shell. If this behavior is desired and not considered a bug, then the bash manual should

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

IPE terminates the subshell. Why? For various reasons. First of all, because it confuses users (there are various bug reports in Debian for this specific issue). More technically, because non-builtin commands are treated differently, for example /bin/echo (from <https://bugs.debian.org/

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci wrote: > The command in the first shell will exit after a random number of > iterations with "terminated with exit status 141". That's what every other shell does. > Regardless of the reason for the SIGPIPE, the reporter expects the loop > to

Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

Hi, I'm forwarding a bug report originally reported in <https://bugs.debian.org/822605>. When a builtin function like echo fails to write to a named pipe, bash will receive a SIGPIPE that will terminate the whole shell. To reproduce this issue: In shell 1: $ rm -f /tmp/f &&am

Re: Documentation Bug: ‘of’ should be ‘or’

On 3/17/24 1:24 AM, Abigail Read wrote: As of Reference Documentation for Bash Edition 5.2, for Bash Version 5.2. September 2022 In 3.1.2.5 Locale-Specific Translation Quoting from the first paragraph of this section: If the current locale is C or POSIX, if there are no translations available,

Re: Documentation Bug: ‘of’ should be ‘or’

+1 On Sun, Mar 17, 2024, 15:04 Abigail Read wrote: > As of > Reference Documentation for Bash Edition 5.2, for Bash Version 5.2. > September 2022 > > In 3.1.2.5 Locale-Specific Translation > Quoting from the first paragraph of this section: > If the current locale is C or POSIX, if there are no

Documentation Bug: ‘of’ should be ‘or’

As of Reference Documentation for Bash Edition 5.2, for Bash Version 5.2. September 2022 In 3.1.2.5 Locale-Specific Translation Quoting from the first paragraph of this section: If the current locale is C or POSIX, if there are no translations available, of if the string is not translated, the

Re: Bug report for pretty-printing coprocesses with simple commands

On 2/27/24 7:25 PM, Seth Sabar wrote: Hi, I'd like to report a bug with the *--pretty-print* feature of bash. When I run the following script: *coproc sleep 5* the pretty-printed result is *coproc COPROC* sleep 5 Thanks for the report. This issue was fixed back in December as the result

Bug report for pretty-printing coprocesses with simple commands

Hi, I'd like to report a bug with the *--pretty-print* feature of bash. When I run the following script: *coproc sleep 5* the pretty-printed result is *coproc COPROC* sleep 5 The reason this happens is because within Bash's AST every *coproc* is given a name regardless of whether the user

Re: Bug: Ligatures are removed as one character

hat matters is that "combining characters" do not have stand-alone semantic meaning; they should be erased along with the principal character. Accents in European languages (and Thai) tend to be in this category. This is how readline behaves, and the behavior the OP was reporti

Re: Bug: Ligatures are removed as one character

n Fri, 23 Feb 2024, Chet Ramey wrote: > On 2/19/24 9:26 PM, Avid Seeker wrote: > > When pressing backspace on Arabic ligatures (including characters with > > diacritics), they are removed as if they are one character. > > As you might guess, readline doesn't know much about Arabic, per se. In a >

Re: Bug: Ligatures are removed as one character

On 2/19/24 9:26 PM, Avid Seeker wrote: When pressing backspace on Arabic ligatures (including characters with diacritics), they are removed as if they are one character. As you might guess, readline doesn't know much about Arabic, per se. In a UTF-8 locale, for example, it knows base

Re: Bug: Ligatures are removed as one character

$ locale LANG=C.UTF-8 LC_CTYPE="C.UTF-8" LC_NUMERIC="C.UTF-8" LC_TIME="C.UTF-8" LC_COLLATE="C.UTF-8" LC_MONETARY="C.UTF-8" LC_MESSAGES="C.UTF-8" LC_PAPER="C.UTF-8" LC_NAME="C.UTF-8" LC_ADDRESS="C.UTF-8" LC_TELEPHONE="C.UTF-8" LC_MEASUREMENT="C.UTF-8" LC_IDENTIFICATION="C.UTF-8" LC_ALL= But it's

Re: Bug: Ligatures are removed as one character

On 2/19/24 9:26 PM, Avid Seeker wrote: When pressing backspace on Arabic ligatures (including characters with diacritics), they are removed as if they are one character. What's your locale? (Not that I guarantee having it installed.) -- ``The lyf so short, the craft so long to lerne.'' -

Re: Bug: Ligatures are removed as one character

ining" to "combining" depending on the language in which they're used. Unicode also has a problem distinguishing a combining letter (vowel points in Arabic or Hebrew) from a combining diacritic (accents in Latin script). If you think that's a bug in Unicode, you're not alone; the Unicode

Bug: Ligatures are removed as one character

When pressing backspace on Arabic ligatures (including characters with diacritics), they are removed as if they are one character. Example: السَّلامُ Pressing 3 backspaces leaves the word at ال. It removed لا which is a ligature combining "ل" and "ا", and removed "م" with diacritics. Compare

Re: possible bash bug bringing job. to foreground

On Sat, Feb 17, 2024, 20:54 Greg Wooledge wrote: > On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote: > > After further examination, the examples with "fg $$" and "fg $!" clearly > do not bring the subshell into the foreground, as they are evaluated prior > to the subshells background

Re: possible bash bug bringing job. to foreground

I was unaware of TMOUT. Now I have a backup as well. Thanks for tolerating my inexperience. On Sat, Feb 17, 2024 at 2:54 PM, Greg Wooledge wrote: On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote: > After further examination, the examples with "fg $$" and "fg $!" clearly do >

Re: possible bash bug bringing job. to foreground

On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote: > After further examination, the examples with "fg $$" and "fg $!" clearly do > not bring the subshell into the foreground, as they are evaluated prior to > the subshells background execution. > I'm trying to bring the subshell to the

Re: possible bash bug bringing job. to foreground

After further examination, the examples with "fg $$" and "fg $!" clearly do not bring the subshell into the foreground, as they are evaluated prior to the subshells background execution. I'm trying to bring the subshell to the foreground to perform an exit, after a delay. Ultimately, it will be

Re: Possible bug Bash v5.22.6/5.1.16

On 2/17/24 6:40 AM, John Larew wrote: This is a portion of a script that appears to be problematic. Each of these attempts appear to be valid; none of them work. The issue is apparent with bash in both termux v0.118.0/5.22.6 and Ubuntu v22.04.3 LTS/5.1.16  (see attached). The clue is in the

Re: possible bash bug bringing job. to foreground

On Sat, Feb 17, 2024 at 01:30:00PM +, John Larew wrote: > Repeat-By: 1: (sleep 15s; set -m; fg %%; exit ) & 2: (sleep 15s; set -m; fg > %+; exit ) &  You're using %% or %+ inside a shell where there have NOT been any background jobs created yet. The sleep 15s runs in the foreground,

possible bash bug bringing job. to foreground

Configuration Information [Automatically generated, do not change]:Machine: x86_64OS: linux-gnuCompiler: gccCompilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux

[PATCH 03/18] doc/bash.1: fix latent bug in `QN` macro

Whether it arises will depend on word placement and line length. *roff has a simplistic notion of what a "word" is. groff_man_style(7): ... The formatter troff(1) collects words from the input and fills output lines with as many as will fit. Words are separated by spaces and

[PATCH 02/18] doc/bash.1: fix bug in new `Q` macro

I didn't pay close enough attention to Documenter's Workbench 3.3 troff output when submitting the original version of this macro. Add a necessary backslash to escape the newline at the beginning of a conditional block. This omission was causing DWB to put a blank line on the output every time

Re: BUG: Here-doc delimiter: unclosed quotes

On 1/18/24 9:16 AM, Dastan Abdygali wrote: Bash Version: 5.2 Patch Level: 0 Release Status: release Description: If unclosed single quotes or unclosed double quotes are used as a delimiter in here-doc, bash lets the user finish the quote on the next lines. As a result

BUG: Here-doc delimiter: unclosed quotes

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin19.6.0 Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Darwin lab1r2s10.42abudhabi.ae 19.6.0 Darwin Kernel Version 19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.$ Machine Type:

Re: Bash Bug - Incorrect Printing of Escaped Characters

Hi Grisha, I didn’t know to look there (I’m still pretty new to the Bash source). Thanks, this is exciting! Best, Seth On Jan 16, 2024, at 12:18 PM, Grisha Levit wrote:  On Tue, Jan 16, 2024, 11:01 Seth Sabar <[1]sethsa...@gmail.com> wrote: Are you

Re: [Bug][Bash Posix] Inquiry about Contributing to the Project

On 1/16/24 7:11 PM, Emre Ulusoy wrote: Dear Bash Maintainers, I hope this message finds you well. I am writing to inquire about the possibility of contributing to your project. Recently, I discovered a potential bug in the 'bash --posix' terminal and I believe I have a fix that could resolve

Re: [Bug][Bash Posix] Inquiry about Contributing to the Project

On Tue, Jan 16, 2024, at 7:11 PM, Emre Ulusoy wrote: > Recently, I discovered a potential bug in the 'bash --posix' terminal > and I believe I have a fix that could resolve this issue. Before > proceeding, I wanted to confirm if this is an open-source project where > external contr

[Bug][Bash Posix] Inquiry about Contributing to the Project

Dear Bash Maintainers, I hope this message finds you well. I am writing to inquire about the possibility of contributing to your project. Recently, I discovered a potential bug in the 'bash --posix' terminal and I believe I have a fix that could resolve this issue. Before proceeding, I wanted

Re: Bash Bug - Incorrect Printing of Escaped Characters

On Tue, Jan 16, 2024, 11:01 Seth Sabar wrote: > Are you planning on releasing a patch for this? If you'd like me to try to > prepare a patch, I'd appreciate some guidance around the various > dequote_... functions in subst.c. Thanks! > Hi Seth, Chet has committed a fix for this in the devel

Re: Bash Bug - Incorrect Printing of Escaped Characters

t; Hi all, > > > > I'm reaching out to report what I believe to be a bug with the > > *--pretty-print* feature in bash-5.2. From what I can tell, Bash uses the > > utf-8 character */001* as an escape character. However, when using the > > pretty-print feature in Bash,

Re: [bug-bash] Bash-5.2 Patch 22

On 1/16/24 10:09 AM, Dr. Werner Fink wrote: On 2024/01/16 09:27:19 -0500, Chet Ramey wrote: On 1/16/24 4:00 AM, Dr. Werner Fink wrote: what is with the readline82-008, readline82-009, and readline82-010 patches? What about them? Should those be part also of trhe bash52 patches as well?

Re: [bug-bash] Bash-5.2 Patch 22

On 2024/01/16 09:27:19 -0500, Chet Ramey wrote: > On 1/16/24 4:00 AM, Dr. Werner Fink wrote: > > > what is with the readline82-008, readline82-009, and readline82-010 > > patches? > > What about them? Should those be part also of trhe bash52 patches as well? -- "Having a smoking section in

Re: [bug-bash] Bash-5.2 Patch 22

On 1/16/24 4:00 AM, Dr. Werner Fink wrote: what is with the readline82-008, readline82-009, and readline82-010 patches? What about them? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU

Re: [bug-bash] Bash-5.2 Patch 22

On 2024/01/14 13:34:06 -0500, Chet Ramey wrote: >BASH PATCH REPORT >= > > Bash-Release: 5.2 > Patch-ID: bash52-022 > > Bug-Reported-by: srobert...@peratonlabs.com > Bug-Reference-ID: > Bug

Re: A possible bug?

On 12/27/23 4:33 PM, George R Goffe wrote: Chet, Thanks for your response. Is this clone NOT a dev branch? I'm thinking you're saying that it is not. It is not. The default (master) branch is for releases. My objective in using the clone is to get as close to a "release" as possible... a

Re: A possible bug?

devel branch; the releases should have complete dependencies included. If they don't, it's a bug. The idea is to have as few dependencies (no pun intended) in the releases as possible. I suppose I could make the depend target conditional on the release status, but I've never done it. -- ``The lyf

Re: A possible bug?

s only intended for the devel branch; the releases should have complete dependencies included. If they don't, it's a bug. The idea is to have as few dependencies (no pun intended) in the releases as possible. I suppose I could make the depend target conditional on the release status, but I've never done it.

Re: Bash Bug - Incorrect Printing of Escaped Characters

On 12/25/23 5:00 PM, Seth Sabar wrote: Hi all, I'm reaching out to report what I believe to be a bug with the *--pretty-print* feature in bash-5.2. From what I can tell, Bash uses the utf-8 character */001* as an escape character. However, when using the pretty-print feature in Bash

  1   2   3   4   5   6   7   8   9   10   >