[bug #67536] -Wmisleading-indentation warning in strtrans.c

URL: Summary: -Wmisleading-indentation warning in strtrans.c Group: The GNU Bourne-Again SHell Submitter: correctmost Submitted: Fri 19 Sep 2025 04:07:36 PM UTC Category: None

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

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

From: Nicolas Aupetit The `repeat` function calls the provided command one time too many: repeat 10 echo "foo" | wc -l ⇒ 11 Also, the provided `seq` function shadows `/usr/bin/seq`. The patch to fix these issues has originally been provided by Nicolas Auperit in

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

builtin_name --help

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.)

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