Re: [PATCH] examples/s-f/Bash_aliases: Fix off-by-one error

On Sat, Sep 20, 2025, at 9:03 AM, Stan Marsh wrote: > Regarding the fundamental question of "Is this a bug or not?", note that > in computer stuff, yeah, most people's intuitive idea of what "repeat n > times" means is "Do it n times". And most implementations I've seen of > a "repeat" keyword in p

Re: [PATCH] examples/s-f/Bash_aliases: Fix off-by-one error

On 20/09/2025 at 14:03, Stan Marsh wrote: Very entertaining thread! Blast from the past! Regarding the fundamental question of "Is this a bug or not?", note that in computer stuff, yeah, most people's intuitive idea of what "repeat n times" means is "Do it n times". And most implementations I've

Re: [PATCH] examples/s-f/Bash_aliases: Fix off-by-one error

Hello, I try to resolve the confusion: Am Sat, 20 Sep 2025 14:56:05 +0100 schrieb Chris Elvidge : > ... > On my machines (Slack 15 / LMDE 6) 'seq 100' prints a line 100 times. > seq is an elf binary, not a function. > repeat doesn't exist as an executable or function. In the bash source tree yo

Re: [PATCH] examples/s-f/Bash_aliases: Fix off-by-one error

> On my machines (Slack 15 / LMDE 6) 'seq 100' prints a line 100 times. > seq is an elf binary, not a function repeat doesn't exist as an > executable or function. To fix that, you need to "dot" (aka, "source") the file Bash_aliases, which you will find in the "examples/startup-files" subdirecto

Re: builtin_name --help

Sep 19, 2025, 09:14 by andreas.kah...@abc.se: > Should I somehow *assume* that "--help" is supported? Actually, yes. If there is only one thing that you would reasonably assume about any command -- then this would be it. :-) When you encounter an unfamiliar command, you don't immediately rush to

Re: [PATCH] examples/s-f/Bash_aliases: Fix off-by-one error

On 20/09/2025 at 00:01, Gioele Barabucci wrote: From: Nicolas Aupetit The `repeat` function calls the provided command one time too many: repeat 10 echo "foo" | wc -l ⇒ 11 Surely that depends on your definition of repeat. Do it and repeat it 10 times vs. Do it a total of 10 times -- C

Re: builtin_name --help

Sep 19, 2025, 06:26 by andreas.kah...@abc.se: > the fact that they *also* output help text seems like a bug to me. If you think that builtins don't support "--help" then try: builtin --help vs. builtin --yelp

Re: builtin_name --help

On Fri, Sep 19, 2025 at 05:00:12PM +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: > I don't know how else to say it. My question has nothing to do > with "documentation". I am talking about any command that recognizes > "--help" as a valid option, nothing else. (See my ori

Re: builtin_name --help

On 9/19/25 11:13 AM, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: Sep 19, 2025, 10:08 by chet.ra...@case.edu: So you want builtins that recognize --help (not all do) to return 0 instead Precisely. OK, that is consistent with the GNU Coding Standards, which is the only rea

Re: builtin_name --help

On 9/19/25 10:46 AM, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: So this is the bug report? That the builtins that accept --help (some builtins are documented as not accepting any options) do not return 0? No, it most certainly is not. And yet you say it is below: To r

Re: builtin_name --help

On Fri, 19 Sep 2025 14:57:48 -0400 Chet Ramey wrote: > > > You mentioned times, but times does not accept --help. > > It would have only taken a second to test this. > $ ../bash-5.3-patched/bash -c 'times --help' > times: times > Display process times. Right. My bad! It turns out, on the box I

Re: builtin_name --help

On 9/19/25 1:39 PM, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: You mentioned times, but times does not accept --help. It would have only taken a second to test this. $ ../bash-5.3-patched/bash -c 'times --help' times: times Display process times. Prints the accu

Re: builtin_name --help

On 9/19/25 11:06 AM, Lawrence Velázquez wrote: On Fri, Sep 19, 2025, at 9:20 AM, Chet Ramey wrote: On 9/19/25 7:26 AM, Andreas Kähäri wrote: To get the help text, one should use "help builtin_name" (this also works for built-ins like "[" and "echo" that do not recognize "--help"). This is the

Re: builtin_name --help

Sep 19, 2025, 11:05 by chet.ra...@case.edu: > It would not, but you're in the right neighborhood. > I'll take care of it. Are you sure that it's not enough? I just built a fresh new bash with the following patch, and it seems to have solved everything for me: -

Re: builtin_name --help

On Fri, 19 Sep 2025 12:30:07 -0400 Chet Ramey wrote: > > > It would not, but you're in the right neighborhood. > > > I'll take care of it. > > > > Are you sure that it's not enough? I just built a fresh new bash with the > > following patch, and it seems to have solved everything for me: > > Yes.

Re: builtin_name --help

On 9/19/25 12:21 PM, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: Sep 19, 2025, 11:05 by chet.ra...@case.edu: It would not, but you're in the right neighborhood. I'll take care of it. Are you sure that it's not enough? I just built a fresh new bash with the following patch,

Re: builtin_name --help

On 9/19/25 11:33 AM, Andreas Kähäri wrote: Should I somehow *assume* that "--help" is supported? You can in the case we're discussing, but only because bash is a GNU program and `--help' is part of the GNU coding standards. Hmm... and the GNU coding standards says to exit with a zero exit sta

Re: builtin_name --help

On Fri, Sep 19, 2025 at 11:17:14AM -0400, Chet Ramey wrote: > On 9/19/25 10:13 AM, Andreas Kähäri wrote: > > > > No, the fact that they output help text is because "--help" was asked for, > > > and they do support "--help". > > > > Support? I would expect that to be documented. If a utility doe

Re: builtin_name --help

On Fri, Sep 19, 2025, at 9:20 AM, Chet Ramey wrote: > On 9/19/25 7:26 AM, Andreas Kähäri wrote: >> To get the help text, one should use "help builtin_name" >> (this also works for built-ins like "[" and "echo" that do not recognize >> "--help"). This is the point of the "help" built-in. > > This i

Re: builtin_name --help

On 9/19/25 10:13 AM, Andreas Kähäri wrote: No, the fact that they output help text is because "--help" was asked for, and they do support "--help". Support? I would expect that to be documented. If a utility does not document an option, how can I be sure what would happen if I used it? So

Re: builtin_name --help

Sep 19, 2025, 10:08 by chet.ra...@case.edu: > So you want builtins that recognize --help (not all do) to return 0 instead > Precisely.

Re: builtin_name --help

On 9/19/25 11:00 AM, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: I don't know how else to say it. My question has nothing to do with "documentation". I am talking about any command that recognizes "--help" as a valid option, nothing else. (See my original post.) How is that

Re: builtin_name --help

I don't know how else to say it. My question has nothing to do with "documentation". I am talking about any command that recognizes "--help" as a valid option, nothing else. (See my original post.) Sep 19, 2025, 09:51 by chet.ra...@case.edu: > On 9/19/25 10:46 AM, pourko--- via Bug reports for t

Re: builtin_name --help

On Fri, Sep 19, 2025 at 03:55:14PM +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: > Sep 19, 2025, 06:26 by andreas.kah...@abc.se: > > On Fri, Sep 19, 2025 at 11:40:51AM +0200, Pourko wrote: > > The bug here seems to be that the "--help" long option provokes a > > behaviour

Re: builtin_name --help

On 9/19/25 10:28 AM, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: Sep 19, 2025, 09:14 by andreas.kah...@abc.se: Should I somehow *assume* that "--help" is supported? Actually, yes. If there is only one thing that you would reasonably assume about any command -- then this wou

Re: builtin_name --help

On 9/19/25 9:55 AM, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: Not *some*, they all return error code 2. And, I don't see anything "invalid" about --help. So this is the bug report? That the builtins that accept --help (some builtins are documented as not accepting any op

Re: builtin_name --help

On 9/19/25 7:26 AM, Andreas Kähäri wrote: The bug here seems to be that the "--help" long option provokes a behaviour from some built-ins that is not documented. Such as? To get the help text, one should use "help builtin_name" (this also works for built-ins like "[" and "echo" that do not

Re: builtin_name --help

Sep 19, 2025, 06:26 by andreas.kah...@abc.se: > On Fri, Sep 19, 2025 at 11:40:51AM +0200, Pourko wrote: > The bug here seems to be that the "--help" long option provokes a > behaviour from some built-ins that is not documented.  The built-ins > that do this are rightly exiting with status 2, since

Re: [bug #67486] Can't use if with two separate awk floating number comparisons

At 2025-09-09T10:54:29-0400, Chet Ramey wrote: > On 9/9/25 10:23 AM, G. Branden Robinson wrote: [Martin D. Kealey wrote:] > > > Savane (the > > > software that runs on Savannah) only seems to offer “group > > > membership” roles as a way to restrict wh

Re: builtin_name --help

On Fri, Sep 19, 2025 at 11:40:51AM +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: > Wouldn't it be more reasonable to return 0 when invoking >   builtin_name --help > the way most external commands do? > (Unless there's actually an error.) > Playing the devil's advocate

Re: Bash glob range [0-5] in UTF-8 locale misses ¹, ² & ³

On 9/8/25 4:59 AM, Grisha Levit wrote: So, in fact, locale-aware collation is disabled only if the range boundary and character being tested are both codepoints in the range U+0001..U+00FF. This doesn't make much sense for codepoints in the range U+0080..U+00FF, so the <= UCHAR_MAX check should

Re: CORRECTED: Bug in the read command

I see that the mail-archive mangled my quotes and lines a little, but you'll get what I mean.

Re: CORRECTED: Bug in the read command

On Sep 18, 2025, 13:55 Chet Ramey wrote: > On 9/17/25 12:02 PM, Pourko wrote: > > As a side question, wouldn't it make more sense if read -d"" -t 0 > > makes the read in raw mode? > > What would that do to change things? (I assume that you mean a non- > blocking read; `raw mode' has historically m

Re: [bug #67486] Can't use if with two separate awk floating number comparisons

On 9/9/25 1:18 AM, Koichi Murase wrote: I think Chet has set up forwarding the notifications to the bug-bash mailing list after the following thread [1,2]: [1] https://lists.gnu.org/archive/html/bug-bash/2024-03/threads.html#00253 [2] https://lists.gnu.org/archive/html/bug-bash/2024-04/threads.

Re: CORRECTED: Bug in the read command

On 9/17/25 11:31 AM, pou...@tutamail.com wrote: Chet Ramey wrote: > Why? If you're running the script from an interactive shell with job > control enabled, the standard input and standard output will be the > same as the parent shell. I am kicking myself why I had to be so easily provoked by

Re: CORRECTED: Bug in the read command

On 9/17/25 12:02 PM, pou...@tutamail.com wrote: As a side question, wouldn't it make more sense if read -d"" -t 0 makes the read in raw mode? What would that do to change things? (I assume that you mean a non- blocking read; `raw mode' has historically meant something different.) Or is it car

Re: bash hangs when executing a script with a here document larger than 64 KiB

On 9/17/25 3:39 PM, Bruno Haible via Bug reports for the GNU Bourne Again SHell wrote: Machine Type: x86_64-pc-cygwin Bash Version: 5.2 Patch Level: 21 Release Status: release Description: bash hangs when executing a very particular config.status script. Repeat-By: ==

Re: [PATCH] command substitution with trailing newlines (was Re: [PATCH] Add shopts for ...)

On 9/18/25 10:09 AM, Koichi Murase wrote: 2025年8月29日(金) 20:16 Kevin Pulo : This patch adds the syntax ${;cmd;}, which is handled identically to ${ cmd;} except that trailing newlines are preserved. I've checked the contents of the patch. Maybe it's already been applied to the codebase with adj

Re: [PATCH] command substitution with trailing newlines (was Re: [PATCH] Add shopts for ...)

2025年8月29日(金) 20:16 Kevin Pulo : > This patch adds the syntax ${;cmd;}, which is handled identically to ${ cmd;} > except that trailing newlines are preserved. I've checked the contents of the patch. Maybe it's already been applied to the codebase with adjustments, but shouldn't the keep-trailing-

Re: [PATCH] command substitution with trailing newlines (was Re: [PATCH] Add

2025年9月4日(木) 20:57 Martin D Kealey : > On Wed, 3 Sept 2025 at 07:17, Koichi Murase wrote: >> 2025年9月3日(水) 1:21 Martin D Kealey : >> > Maybe « function foo -o compat=60 -o extglob -o nullglob … { …; } »? >> >> With that syntax, Zsh defines multiple functions of the same content, > > Aww sheesh. Zsh

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Mon, Sep 15, 2025, at 12:32 PM, Lawrence Velázquez wrote: > Attachments: > * single_byte_test.txt Embarrassing confession: this script will create or overwrite a file named "z" in the current directory. The attached version skips testing ">". -- vqset -- unset -v z # \076 ('>') skipped inte

Re: Bug in the read command

On 9/17/25 10:37 AM, Oğuz wrote: On Wed, Sep 17, 2025 at 5:31 PM Chet Ramey wrote: Thanks, this is a mostly-unrelated issue that is easily fixed. Ah, you beat me to it. The problem is `i' ends up with -1 here https://cgit.git.savannah.gnu.org/cgit/bash.git/tree/builtins/read.def?h=devel#n595

Re: CORRECTED: Bug in the read command

Greg Wooledge wrote: > Now, this is where I get confused about your goals.  It sounds like > you've written a program that interacts with a user via the terminal. > If something else runs your program as a background command, then your > program won't work.  It'll be stopped when it tries to read t

Re: Bug in the read command

On Wed, Sep 17, 2025 at 19:16:21 +0700, Robert Elz wrote: > I think a better question would be, which shell is being > used to run ./test0 & wait and ./test1 & wait. > > The implication is that it also is bash, but I doubt bash would > act as described. If however it is some other shell (say das

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Tue, 16 Sept 2025 at 01:46, Chet Ramey wrote: > On 9/15/25 10:46 AM, Robert Elz wrote: > > > If it was intended to mean "parsing the script" it would certainly say > so. > > Doesn't the fact that the discussion of token recognition includes the > references to s imply this? > There's an argum

Re: CORRECTED: Bug in the read command

Duncan Roe wrote: > malloc: unknown:0: assertion botched > free: underflow detected; magic8 corrupted > Aborting...$ > [1]+  Aborted    (core dumped) ./test1 > > Maybe there is a bug in here somewhere after all. Curiouser and curiouser! :-) Thanks, Duncan!

Re: [bug #67486] Can't use if with two separate awk floating number comparisons

On 9/9/25 10:23 AM, G. Branden Robinson wrote: Savane (the software that runs on Savannah) only seems to offer “group membership” roles as a way to restrict who can make changes, meaning that all group membership has to be approved by existing maint

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On 9/16/25 10:58 PM, Martin D Kealey wrote: On Tue, 16 Sept 2025 at 01:46, Chet Ramey > wrote: On 9/15/25 10:46 AM, Robert Elz wrote: > If it was intended to mean "parsing the script" it would certainly say so. Doesn't the fact that the discussion

Re: Bug in the read command

Andreas Kähäri wrote: > Can you say something about the version of Bash you're running and on > what platform? I can not reproduce the hanging behaviour of "test1" > using Bash 5.2.37 on Alpine Linux, nor with 5.2.15 on Debian, or with > 5.3.0 buildt from the latest sources on Alpine. Now that you

Re: trap and BASH_COMMAND

run. So `return 1' executes, which sets BASH_COMMAND; it > > > completes (which causes `foo' to complete execution as a side effect); > > > and the ERR trap runs with BASH_COMMAND unchanged. Upon re-reading this, I see that it is the same as what I describe below. The trap

Re: Bug in the read command

Date:Wed, 17 Sep 2025 20:04:58 +1000 From:Duncan Roe via Bug reports for the GNU Bourne Again SHell Message-ID: | Do you by any chance have job control disabled? I think a better question would be, which shell is being used to run ./test0 & wait and ./test1 & wai

Re: Bug in the read command

On Sep 17 2025, Greg Wooledge wrote: > I can't tell what those ioctl() calls are doing. Why call TCGETS three > times in a row? I see only two times TCGETS. The first TCGETS comes from isatty. The second one comes from tcgetattr to save the current settings, followed by tcsetattr to update the

Re: Bug in the read command

On 9/17/25 9:48 AM, Robert Elz wrote: g...@wooledge.org said: | I'm not sure exactly what bash is doing here, but I'm guessing it has | something to do with switching the terminal from canonical mode to raw | mode...? I don't look at bash code, but the NetBSD shell sets the "eol" char

Re: CORRECTED: Bug in the read command

As a side question, wouldn't it make more sense if read -d"" -t 0 makes the read in raw mode? Or is it carved in stone for historical reasons? If so, then couldn't we maybe some time in the future get a new "-T 0" option that could do a read in raw mode? Because, as things are now, one has no way

Re: CORRECTED: Bug in the read command

On Wed, Sep 17, 2025 at 17:31:04 +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: > Nothing interactive in that. Now, if some other script, > that calls my script, were to spin it off with an "&", that's when > one of my functions gets stuck there forever. I am trying to fin

Re: Bug in the read command

Date:Wed, 17 Sep 2025 10:25:08 -0400 From:Greg Wooledge Message-ID: <20250917142508.gk22...@wooledge.org> | I can't tell what those ioctl() calls are doing. Why call TCGETS three | times in a row? That's a good question ... and the TCGETS after the (successful)

Re: Bug in the read command

Date:Wed, 17 Sep 2025 15:33:31 +0200 (CEST) From:pourko--- via Bug reports for the GNU Bourne Again SHell Message-ID: | Why do you need to "doubt" it, when you can just as easily test it? You're right I could, but I'm lazy, and Duncan had already done that, and n

Re: Bug in the read command

Chet Ramey wrote: > It's more likely that the OP is running the scripts from an interactive > shell that is not bash. On my box I have no shells other than bash, and even sh is symlinked to bash ~# help | head -1 GNU bash, version 5.2.37(47)-release (x86_64-slackware-linux-gnu)

Re: CORRECTED: Bug in the read command

Chet Ramey wrote: > Why? If you're running the script from an interactive shell with job > control enabled, the standard input and standard output will be the > same as the parent shell. I am kicking myself why I had to be so easily provoked by some posts, as to rewrite the examples as two separa

Re: Bug in the read command

On 9/17/25 11:09 AM, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: Chet Ramey wrote: It's more likely that the OP is running the scripts from an interactive shell that is not bash. On my box I have no shells other than bash, and even sh is symlinked to bash ~# help | head -1

Re: CORRECTED: Bug in the read command

On 9/17/25 5:05 AM, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: RESULTS: ./test0 finishes execution. ./test1 gets stuck after echo "RUNNING", and before echo "RETURNING". You can look at the process status using ps and see what's going on. It's already been covered in othe

Re: Bug in the read command

On Wed, Sep 17, 2025 at 16:37:55 +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: > Robert Elz wrote: > > > Also, if you notice there is a "#!/bin/bash" in each of the examples. > > > > That's irrelevant, that's not the shell that is causing the issue. > > What matters is wh

Re: Bug in the read command

Robert Elz wrote: > > Also, if you notice there is a "#!/bin/bash" in each of the examples. > > That's irrelevant, that's not the shell that is causing the issue. > What matters is which shell you are using to run those scripts, that > is the one in which you're doing > ./test1 & wait I s

Re: Bug in the read command

On 9/17/25 8:16 AM, Robert Elz wrote: Date:Wed, 17 Sep 2025 20:04:58 +1000 From:Duncan Roe via Bug reports for the GNU Bourne Again SHell Message-ID: | Do you by any chance have job control disabled? I think a better question would be, which shell is being

Re: Bug in the read command

On Wed, Sep 17, 2025 at 5:31 PM Chet Ramey wrote: > Thanks, this is a mostly-unrelated issue that is easily fixed. Ah, you beat me to it. The problem is `i' ends up with -1 here https://cgit.git.savannah.gnu.org/cgit/bash.git/tree/builtins/read.def?h=devel#n595 and then the SIGTERM and SIGCONT se

Re: Bug in the read command

On 9/17/25 6:04 AM, Duncan Roe via Bug reports for the GNU Bourne Again SHell wrote: [1]+ Stopped./test1 -bash: wait: warning: job 1[4286] stopped Do you by any chance have job control disabled? It's more likely that the OP is running the scripts from an interactive shel

Re: Bug in the read command

On Wed, Sep 17, 2025 at 20:48:13 +0700, Robert Elz wrote: > g...@wooledge.org said: > | I'm not sure exactly what bash is doing here, but I'm guessing it has > | something to do with switching the terminal from canonical mode to raw > | mode...? > > I don't look at bash code, but the NetBSD

Re: Bug in the read command

On Wed, Sep 17, 2025 at 15:33:31 +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: > Robert Elz wrote: > > I think a better question would be, which shell is being > > used to run ./test0 & wait and ./test1 & wait. > > > > The implication is that it also is bash, but I doubt

Re: Bug in the read command

Robert Elz wrote: > I think a better question would be, which shell is being > used to run ./test0 & wait and ./test1 & wait. > > The implication is that it also is bash, but I doubt bash would > act as described. Why do you need to "doubt" it, when you can just as easily test it? Also, if you no

Re: Bug in the read command

e[a8a1c2fa] under Slackware. test1 gave: ==> NOTE: RUNNING. [1]+ Stopped./test1 -bash: wait: warning: job 1[4286] stopped Do you by any chance have job control disabled? But, things get interesting when I kill the job:- $ kill %1 [1]+ Stopped./test1 ./t

Re: Bug in the read command

On Wed, Sep 17, 2025 at 08:25:01AM +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: > Some people suggested that my post was not in a suitable form. > So I am rephrasing my original post, with simpler examples: > > cat <<'EOF' >./test0 > #!/bin/bash > [ -t 0 ] && [ -t 1 ] ||

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

the C standard prohibits re-using the names of standard functions, it also mandates that those functions should operate as advertised. Meanwhile « # define standard_function_name replacement_version_that_works » has a minimal chance of messing up, and so I think this would be an acceptable tra

Re: A problem with the read command

>What, no takers? Come on, guys, that can't be normal for the read >command to get stuck like that. After all, I've given it the timeout >option, "read -t 1", which means, "In one second, read-or-not, be out >of there!", does it not? There must be something I could do to avoid >getting stuck like t

Re: [PATCH] command substitution with trailing newlines (was Re: [PATCH] Add shopts for ...)

On 9/15/25 11:03 PM, Kevin Pulo wrote: On Tue, 9 Sept 2025 at 00:05, Chet Ramey wrote: That association seems kind of tenuous, but it's better than nothing. Attached is a patch for suggested docs and tests updates, to go alongside the original ${;cmd;} patch. Shouldn't be too hard to update

Re: A problem with the read command

Stan Marsh wrote: > >What, no takers? Come on, guys, that can't be normal for the read > >command to get stuck like that. After all, I've given it the timeout > >option, "read -t 1", which means, "In one second, read-or-not, be out > >of there!", does it not? There must be something I could do to a

Re: A problem with the read command

pourko--- via Bug reports for the GNU Bourne Again SHell writes: > What, no takers? Come on, guys, that can't be normal for the read command to > get stuck like that. After all, I've given it the timeout option, "read -t 1", > which means, "In one second, read-or-not, be out of there!", does it

Re: A problem with the read command

What, no takers? Come on, guys, that can't be normal for the read command to get stuck like that. After all, I've given it the timeout option, "read -t 1", which means, "In one second, read-or-not, be out of there!", does it not? There must be something I could do to avoid getting stuck like that

Re: [PATCH] command substitution with trailing newlines (was Re: [PATCH] Add shopts for ...)

On Tue, 9 Sept 2025 at 00:05, Chet Ramey wrote: > That association seems kind of tenuous, but it's better than nothing. Attached is a patch for suggested docs and tests updates, to go alongside the original ${;cmd;} patch. Shouldn't be too hard to update if something other than ';' is chosen in

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Sep 15 2025, Chet Ramey wrote: > On 9/13/25 10:55 AM, Lawrence Velázquez wrote: > >> Yeah, I misunderstood how locale_setblanks [1] works. Its function >> comment is: >> Set every character in the character class to be a >> shell break character for the lexical analyzer when the >>

Re: trap and BASH_COMMAND

On 9/13/25 5:45 AM, Mike Jonkmans wrote: Thanks for your answers. On Fri, Sep 12, 2025 at 04:31:07PM -0400, Chet Ramey wrote: On 9/11/25 5:02 PM, Mike Jonkmans wrote: The below script echoes (when saved to bash_command.bash): Trace: 1: bash_command.bash:29 onerror () 2: bash_command.ba

Re: [PATCH] ansic_quote: zero mbstate when needed

On 9/14/25 1:50 AM, Grisha Levit wrote: ansic_quote calls mbrtowc with a NULL parser state argument. This uses a static anonymous shift state that ends up in an undefined state after an invalid sequence. AFAICT most libcs handle UTF-8 conversions with the static state just fine, but on Android [1

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Mon, Sep 15, 2025 at 7:34 PM Lawrence Velázquez wrote: > Of the shells I have at hand, running under a UTF-8 locale on macOS, > only yash delimits on anything other than space and tab. FWIW the original ksh88 on both Solaris and Unixware delimit tokens on all members of the blank class defined

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

Andreas Schwab writes: > On Sep 15 2025, Chet Ramey wrote: > >> On 9/13/25 10:55 AM, Lawrence Velázquez wrote: >> >>> Yeah, I misunderstood how locale_setblanks [1] works. Its function >>> comment is: >>> Set every character in the character class to be a >>> shell break character for t

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Mon, Sep 15, 2025 at 12:32:05 -0400, Lawrence Velázquez wrote: > Of the shells I have at hand, running under a UTF-8 locale on macOS, > only yash delimits on anything other than space and tab. (I tested > the twenty-five Unicode whitespace characters [*]. Eighteen of > them are s in my locale,

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On 9/14/25 3:08 PM, Robert Elz wrote: There is really nothing in the standard I can find which is explicit about how locales affect parsing of programs using any of the languages it defines (awk, bc, sed, sh ...) - and I would certainly hesitate to jump to the conclusion that the locale settings

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Sun, Sep 14, 2025, at 3:21 PM, Robert Elz wrote: > Date:Sun, 14 Sep 2025 13:23:06 -0400 > From:=?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= > Message-ID: > > | yash takes this very seriously. > > And is very much the outlier - I couldn't find any other shell which > reports o

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On 9/15/25 10:46 AM, Robert Elz wrote: If it was intended to mean "parsing the script" it would certainly say so. Doesn't the fact that the discussion of token recognition includes the references to s imply this? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

Re: more readline signal issue examples

On 9/5/25 8:21 PM, Grisha Levit wrote: On Thu, Sep 4, 2025 at 12:05 PM Chet Ramey wrote: Well, definitely a few. Thanks for the report. If you find other places where signals cause data to be freed, please report them as well. Sure, a couple variations on the recent reports: Thanks for the

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

Date:Mon, 15 Sep 2025 09:51:01 -0400 From:Chet Ramey Message-ID: <584c7249-b6a5-430e-9ce2-46e4a5091...@case.edu> | At least for sh -- I didn't look at the other utilities -- the standard is | fairly explicit that characters delimit tokens, and is | locale-spe

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Mon, Sep 15, 2025 at 09:51:01 -0400, Chet Ramey wrote: > At least for sh -- I didn't look at the other utilities -- the standard is > fairly explicit that characters delimit tokens, and is > locale-specific. I would respectfully ask that this interpretation, should you choose to abide by it,

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On 9/13/25 10:55 AM, Lawrence Velázquez wrote: Yeah, I misunderstood how locale_setblanks [1] works. Its function comment is: Set every character in the character class to be a shell break character for the lexical analyzer when the locale changes. But it seems to onl

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On 9/13/25 6:12 AM, Duncan Roe via Bug reports for the GNU Bourne Again SHell wrote: I believe bash mostly tokenizes on characters. Is U+00A0 considered a in your locale? -- vq It certainly *renders* as a space. Other than that, I'm not sure I understand your question. https://pubs.open

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Sun, Sep 14, 2025, at 9:37 PM, Duncan Roe via Bug reports for the GNU Bourne Again SHell wrote: > I'm still not getting A0 to be a blank:- That's expected for some locales. Greg saw the same thing. Again, it doesn't matter. Even if your UTF-8 locale did consider U+00A0 to be a , bash wouldn

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Sun, Sep 14, 2025 at 09:12:17PM -0400, Lawrence Velázquez wrote: > On Sun, Sep 14, 2025, at 8:51 PM, Duncan Roe via Bug reports for the GNU > Bourne Again SHell wrote: > > $ [[ $'\u20' = [[:blank:]] ]]; echo "$?" > > 0 > > Now you're testing a regular space for some reason. > > In any case, it

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Sun, Sep 14, 2025, at 8:51 PM, Duncan Roe via Bug reports for the GNU Bourne Again SHell wrote: > $ [[ $'\u20' = [[:blank:]] ]]; echo "$?" > 0 Now you're testing a regular space for some reason. In any case, it doesn't matter. As far as I can tell, under UTF-8 locales bash looks for possible

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Sun, Sep 14, 2025 at 02:25:28PM +1000, Bash development wrote: > On Sat, Sep 13, 2025 at 11:06:03PM -0400, Lawrence Velázquez wrote: > > On Sat, Sep 13, 2025, at 6:12 AM, Duncan Roe via Bug reports for the GNU > > Bourne Again SHell wrote: > > > On Fri, Sep 12, 2025 at 11:23:17PM -0400, Lawrenc

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

Date:Sun, 14 Sep 2025 13:23:06 -0400 From:=?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= Message-ID: | yash takes this very seriously. And is very much the outlier - I couldn't find any other shell which reports other than "1 args", just yash. Not mksh, dash, ksh93, bosh,

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

Date:Sun, 14 Sep 2025 13:23:06 -0400 From:=?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= Message-ID: | POSIX seems to require delimiting on all s [*], without | qualification. | | 7. If the current character is an unquoted , any | token containing the pr

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Sat, Sep 13, 2025, at 11:02 AM, Greg Wooledge wrote: > I really think this is a bad idea. A script needs to have predictable > behavior regardless of what bizarre locales may exist on the target > system. Turns out that this doesn't even require a particularly "bizarre" locale to observe. ISO

Re: Missing semicolon tolerated after double-bracket [[ ]] expression

On Sat, Sep 13, 2025 at 11:06:03PM -0400, Lawrence Velázquez wrote: > On Sat, Sep 13, 2025, at 6:12 AM, Duncan Roe via Bug reports for the GNU > Bourne Again SHell wrote: > > On Fri, Sep 12, 2025 at 11:23:17PM -0400, Lawrence Velázquez wrote: > >> On Fri, Sep 12, 2025, at 10:56 PM, Duncan Roe via

  1   2   3   4   5   6   7   8   9   10   >