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

On 9/22/25 2:25 PM, pou...@tutamail.com wrote: With or without eval, or with any combination thereof, you still won't be able to make a repeat function that covers all the bases. For example, you won't be able to do this: repeat { ((x++)); echo $x;} If you want to use operators in the command

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

On Mon, 22 Sep 2025 10:43:27 -0400, Chet Ramey wrote: > > > > +    for ((i=1; i<=n; i++)); do > > > > +    "$@" > > > > > > You need the eval, otherwise something like > > > > > > repeat 5 v+=f > > > > > > fails. > > > > On the other hand, often you *don't* want the eval, because then > > s

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

On 9/19/25 7:01 PM, Gioele Barabucci wrote: From: Nicolas Aupetit The `repeat` function calls the provided command one time too many: repeat 10 echo "foo" | wc -l ⇒ 11 Wow, software archaeology. This function has sat undisturbed since late 1990. Also, the provided `seq` function shado

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

On 9/22/25 10:36 AM, Greg Wooledge wrote: On Mon, Sep 22, 2025 at 10:12:09 -0400, Chet Ramey wrote: On 9/22/25 3:24 AM, Gioele Barabucci wrote: +for ((i=1; i<=n; i++)); do +"$@" You need the eval, otherwise something like repeat 5 v+=f fails. On the other hand, often you *don

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

On Mon, Sep 22, 2025 at 10:12:09 -0400, Chet Ramey wrote: > On 9/22/25 3:24 AM, Gioele Barabucci wrote: > > > +for ((i=1; i<=n; i++)); do > > +"$@" > > You need the eval, otherwise something like > > repeat 5 v+=f > > fails. On the other hand, often you *don't* want the eval, becau

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

On 9/22/25 10:14 AM, Lawrence Velázquez wrote: This was my first thought as well. I doubt bash 1.x compatibility is really a concern anymore. Well, how about we just remove them from the Bash_aliases file and provide a modern version of `repeat' in the examples/functions subdirectory. That

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

From: Greg Wooledge 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`. This patch fixes this problem by adapting the changes suggested by Greg Wooledge in

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

On 9/22/25 3:24 AM, Gioele Barabucci wrote: +for ((i=1; i<=n; i++)); do +"$@" You need the eval, otherwise something like repeat 5 v+=f fails. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTe

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

On Mon, Sep 22, 2025, at 10:03 AM, Chet Ramey wrote: > On 9/20/25 11:20 AM, Lawrence Velázquez wrote: >>> And, if I were doing this, I'd get rid of "seq" completely (*) and just >>> code the loop in "repeat" as: >>> >>> for ((i=1; i<=count; i++)); do >>> >>> (*) Thereby eliminating the "shadow

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

On 9/20/25 11:20 AM, Lawrence Velázquez wrote: And, if I were doing this, I'd get rid of "seq" completely (*) and just code the loop in "repeat" as: for ((i=1; i<=count; i++)); do (*) Thereby eliminating the "shadowing" issue. This was my first thought as well. I doubt bash 1.x compati

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

On 9/21/25 9:06 AM, Chris Elvidge wrote: I think general /etc/[bash[_.]*|profile] and /etc/skel/ file suggestions should be left to the distro maintainers. I agree. In the case we're discussing, the functions predate Linux, distros, and distro maintainers. -- ``The lyf so short, the craft so l

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

From: Greg Wooledge 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`. This patch fixes this problem by adapting the changes suggested by Gerg Wooledge in

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

>>Sure, except this isn't a script. It's in a file named Bash_aliases >>contained in a directory named examples/startup-files. It was clearly >>intended to be copied into one's ~/.bashrc file (or to be dotted in >>from there). >>Including it in your ~/.bashrc would effectively mask the real se

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

On Sat, 20 Sep 2025 15:57:08 -0400 Greg Wooledge wrote: > I have two -- no, three -- no, four -- issues with this function: > >  1) It's overriding the seq(1) command on systems which have one, with > a less capable alternative. >  2) It's "off by one" if you provide two sensible inputs.  This

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

On 21/09/2025 at 13:37, Greg Wooledge wrote: On Sun, Sep 21, 2025 at 13:04:59 +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: On Sat, 20 Sep 2025 15:57:08 -0400 Greg Wooledge wrote: I have two -- no, three -- no, four -- issues with this function: 1) It's overriding

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

It is fine to keep the relics :-) I used that more as an exercise about how to do it in modern bash. If one can find a shorter one, or a faster one, would be nice to know :-) thats how I learn bash, by looking others examples... reading the docco in last resort :-) Cheer,

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

On Sun, Sep 21, 2025 at 13:04:59 +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: > On Sat, 20 Sep 2025 15:57:08 -0400 Greg Wooledge wrote: > > I have two -- no, three -- no, four -- issues with this function: > > > >  1) It's overriding the seq(1) command on systems which h

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

>May be the 'repeat' function in the 'examples' is a bit lengthy, and use >subshells, the example I got is ... I think all of the files in the examples/startup-files directory should be treated as museum pieces. You wouldn't go into a museum and start insisting that all the displays be changed

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

May be the 'repeat' function in the 'examples' is a bit lengthy, and use subshells, the example I got is === # "repeat" command. Like: # # repeat 10 echo foo repeat () { local count="$1" i; shift; for i in $(seq 1 "$count"); do eval "$@";

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

Date:Sat, 20 Sep 2025 15:57:08 -0400 From:Greg Wooledge Message-ID: <20250920195708.gt22...@wooledge.org> | 2) It's using eval "$@". This is just bad. | It should either be using "$@" without eval, That I agree is the way it should be. However: | o

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

On Sat, Sep 20, 2025 at 21:25:44 +0200, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: > > Also, the provided seq function shadows /usr/bin/seq > > [...] The patch to fix these issues... > > Shadowing a command is not really an "issue". > > In this example, a function shadows an

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

> Also, the provided seq function shadows /usr/bin/seq > [...] The patch to fix these issues... Shadowing a command is not really an "issue". In this example, a function shadows an external command, hence it is in the examples dir.

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

On 20/09/2025 at 15:22, Martin Schulte wrote: 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

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

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

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 seen of a "repeat" keyword in programming h

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

[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

[bug #67406] Make set -e to exit on error default

URL: <https://savannah.gnu.org/bugs/?67406> Summary: Make set -e to exit on error default Group: The GNU Bourne-Again SHell Submitter: None Submitted: Thu 07 Aug 2025 04:10:31 PM UTC Category

Re: fltexpr_strtod range error seems bad

My bad, I did'nt upgraded my source tree! Sorry for the noise! Le Tue, Jul 15, 2025 at 09:58:56AM -0400, Chet Ramey a écrit : > On 7/15/25 7:33 AM, Félix Hauri wrote: > > >var=99;humanizeVar var;echo $var > >90.95T > > looks good, but > >var=99;humanizeVarFact

Re: fltexpr_strtod range error seems bad

On 7/15/25 7:33 AM, Félix Hauri wrote: var=99;humanizeVar var;echo $var 90.95T looks good, but var=99;humanizeVarFactor=1000 humanizeVar var;echo $var 99.00T should sow '100.00T' instead! That's what I get on macOS. -- ``The lyf so short, the craft so long

Re: fltexpr_strtod range error seems bad

Le Wed, Jul 09, 2025 at 09:40:16AM -0400, Chet Ramey a écrit : > On 7/8/25 8:32 PM, Isabella Bosia wrote: > > bash: fltexpr: 1e1: number out of range (error token is "1e1") > > What do you propose? Catch HUGE_VAL/ERANGE and convert to Inf? Far before HUGE num

Re: fltexpr_strtod range error seems bad

On 7/8/25 8:32 PM, Isabella Bosia wrote: $ fltexpr -p inf inf $ fltexpr -p 10**1 inf $ fltexpr -p 1e1 bash: fltexpr: 1e1: number out of range (error token is "1e1") can you just ignore erange? strtod returns an infinity in that case What do you propose? Catch HUGE_

fltexpr_strtod range error seems bad

$ fltexpr -p inf inf $ fltexpr -p 10**1 inf $ fltexpr -p 1e1 bash: fltexpr: 1e1: number out of range (error token is "1e1") can you just ignore erange? strtod returns an infinity in that case in other interpreted languages, 1e1 is: - inf in ksh93 and lua - &#x

Re: getcwd() returns with stale errno value upon error

and no matching directory entry was found. But bash's getcwd() assumes that NULL from readdir() is always an error, which is not the case. This can happen on filesystems where d_ino != st_ino such as on Linux's OverlayFS. Thanks for the report. I'

Re: getcwd() returns with stale errno value upon error

On Thursday, June 26, 2025, Martin D Kealey wrote: > There's a fairly obvious race condition where another process replaces a > directory entry That's not the case here. between readlink and lstat. Who said anything about them? > I would like bash to cope more gracefully with "unexpected"

Re: getcwd() returns with stale errno value upon error

On Thu, 26 Jun 2025 at 04:07, Oğuz wrote: > On Wednesday, June 25, 2025, Richard Weinberger > wrote: > > > > This can happen on filesystems where d_ino != st_ino > > i.e. a broken filesystem. Or not broken. There's a fairly obvious race condition where another process replaces a direc

Re: getcwd() returns with stale errno value upon error

On Donnerstag, 26. Juni 2025 08:45 Phi Debian wrote: > That's true that the bash shell-init: could be omitted and defered until > one ask for pwd explicitly. > > I don't see any *ino* jazz here, but the classic, my current dir has been > removed under my feet. > > I may have mis-read the *ino* pa

Re: getcwd() returns with stale errno value upon error

In the given reproducer, I am not sure btrfs is relevant here on my good'ol ext4 I got. $ mount | grep '/d2 ' | sed 's/(.*//' /dev/sda1 on /d2 type ext4 $ cd /d2 ; mkdir -p a/b/c ; cd a/b/c ; rmdir /d2/a/b/c $ bash -c 'pwd' shell-init: error retrieving curre

Re: getcwd() returns with stale errno value upon error

On Mittwoch, 25. Juni 2025 21:28 Oğuz wrote: > On Wednesday, June 25, 2025, Richard Weinberger > wrote: > > > > I'm not asking you to implement a workaround > > > I'm just another user. I agree that a descriptive error message is better > than a random

Re: getcwd() returns with stale errno value upon error

On Wednesday, June 25, 2025, Richard Weinberger wrote: > > I'm not asking you to implement a workaround I'm just another user. I agree that a descriptive error message is better than a random one. But if your system can't return the same inode number for the same f

Re: getcwd() returns with stale errno value upon error

On Wednesday, June 25, 2025, Richard Weinberger wrote: > > This can happen on filesystems where d_ino != st_ino i.e. a broken filesystem. What does any of this have to do with bash? -- Oğuz

Re: getcwd() returns with stale errno value upon error

On Wednesday, June 25, 2025, Richard Weinberger wrote: > > Having different results for d_ino and st_ino is not that uncommon. > POSIX defines both fields to contain the unique serial number of a file in a filesystem. I don't think Bash is at fault here for not assuming otherwise. -- Oğuz

Re: getcwd() returns with stale errno value upon error

h could, for example, check the readdir() return state better to avoid a confusing error message. IOW setting errno to 0 before calling readdir() and then checking whether errno has changed. Having different results for d_ino and st_ino is not that uncommon. The most prominent example is Linux&#x

getcwd() returns with stale errno value upon error

algorithm fails. It aborts if readdir() returns NULL and no matching directory entry was found. But bash's getcwd() assumes that NULL from readdir() is always an error, which is not the case. This can happen on filesystems where d_ino != st_ino such as on Li

Re: [PATCH] Fix link error on GNU/Hurd.

Hi Chet, Chet Ramey writes: > Thanks for the report. I'm interested in why you're not using ncurses. Is > it just not installed on your build system? I occasionally test Gnulib in a Hurd VM (fresh each time since my image doesn't like to reboot, unfortunately). I had assumed that libncurses-de

Re: [PATCH] Fix link error on GNU/Hurd.

On 5/9/25 1:29 AM, Collin Funk wrote: Hi Chet, Building bash from the devel branch fails the link on GNU/Hurd. Here is the error: Thanks for the report. I'm interested in why you're not using ncurses. Is it just not installed on your build system? Chet -- ``The lyf so short, th

[PATCH] Fix link error on GNU/Hurd.

Hi Chet, Building bash from the devel branch fails the link on GNU/Hurd. Here is the error: gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/malloc -L./lib/sh -L./lib/termcap -g -O2 -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o

[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: Unexpected $BASH_COMMAND after error in subshell

++bugfixes++ On Wed, Feb 26, 2025, 3:15 PM Chet Ramey wrote: > On 2/23/25 12:20 PM, Max Bowsher wrote: > > > Bash Version: 5.2 > > Patch Level: 37 > > Release Status: release > > > > Description: > > > > When using $BASH_COMMAND in an EXIT trap to tell the user what failed, I > > came across a p

Re: Unexpected $BASH_COMMAND after error in subshell

On 2/23/25 12:20 PM, Max Bowsher wrote: Bash Version: 5.2 Patch Level: 37 Release Status: release Description: When using $BASH_COMMAND in an EXIT trap to tell the user what failed, I came across a problem where errors in subshells would instead implicate the command immediately before the sub

Unexpected $BASH_COMMAND after error in subshell

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux spectrex360 6.8.0-53-generic #55-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 17 15:37:52 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

On 2/12/25 10:50 AM, Andrés Rodríguez Reina wrote: Bash Version: 5.0 Patch Level: 17 Release Status: release Description: Due to a mistake in coding a script, a folder named '~' was generated. An unexperienced bash user issued the command "rm -rf ~" by mistake, intending to delete th

Re: grammar error in Bash Reference Manual

On Wed, Feb 12, 2025, at 9:18 PM, LY via Bug reports for the GNU Bourne Again SHell wrote: > I think there is a grammar error in this sentence > in https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html > >  "but double quote characters in expressio

grammar error in Bash Reference Manual

Hi, I think there is a grammar error in this sentence in https://www.gnu.org/software/bash/manual/html_node/Conditional-Constructs.html  "but double quote characters in expression are not treated specially are removed." This sentence should be changed to "but double quot

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

Andrés Rodríguez Reina writes: ... > Due to a mistake in coding a script, a folder named '~' was > generated. An unexperienced bash user issued the command "rm -rf ~" by > mistake, intending to delete the '~' folder, but this resulted in > deleting 150GB+ of data at their home directory. It mig

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

either, but it can easily be activated in ~/.bashrc for beginners. From: microsuxx Sent: Wednesday, February 12, 2025 9:29:40 PM To: Andrés Rodríguez Reina Cc: bug-bash ; Marina López Seoane Subject: Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the ti

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

or \~ On Wed, Feb 12, 2025, 9:05 PM microsuxx wrote: > to use ~ as file .. > > '~' n "~" > or ./~ > > On Wed, Feb 12, 2025, 5:21 PM Andrés Rodríguez Reina > wrote: > >> Subject: [Suggestion] Add warning/error when using the tilde expansion in &

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

to use ~ as file .. '~' n "~" or ./~ On Wed, Feb 12, 2025, 5:21 PM Andrés Rodríguez Reina wrote: > Subject: [Suggestion] Add warning/error when using the tilde expansion in > a folder where the tile-named file/folder exists > > Configuration Information [Automa

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

On Wed, Feb 12, 2025, at 2:02 PM, Andrés Rodríguez Reina wrote: > And I also > agree that any other substitution is subject to cause the same > confusion, but the case with the tilde expansion produces more damage > to inexperienced users. I mean: "rm -rf *" just deletes the whole > folder cont

RE: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

can easily disable the flag and obtain full power/risk. Best regards, Andrés -Original Message- From: Lawrence Velázquez Sent: 12 February 2025 19:46 To: Andrés Rodríguez Reina Cc: Marina López Seoane ; bug-bash@gnu.org Subject: Re: [Suggestion] Add warning/error when using the tilde exp

Re: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

ntry for every word before it does anything? > Fix: > When in interactive mode and when a suitable flag is activated, > an error should appear. For example: > type the home path to avoid ambiguity.> Tilde expansion may surprise inexperienced users, but there's nothing "ambiguous" about it. It is well defined. -- vq

[Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists

Subject: [Suggestion] Add warning/error when using the tilde expansion in a folder where the tile-named file/folder exists Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

ion when it's unset and 'set -u' is active will cause bash to > > > error out. ${| command; } is likewise also an explicit attempt to > > > expand the value of a variable, this time the instance of REPLY local > > > to the funsub. > > > > Your vie

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

ther nonsense real quick: > > > > > > zsant@Zack2021HPPavilion MSYS ~/repos/bash > > > $ : ${| REPYL="whatever"} > > > ; } > > > bash: syntax error near unexpected token `;' while looking for > matching `}' > > > bash: DEBUG warning: cu

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Tue, Dec 24, 2024 at 7:51 PM Lawrence Velázquez wrote: > > On Tue, Dec 24, 2024, at 12:10 PM, Zachary Santer wrote: > > Some other nonsense real quick: > > > > zsant@Zack2021HPPavilion MSYS ~/repos/bash > > $ : ${| REPYL="whatever"} > > ;

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Tue, Dec 24, 2024, at 12:10 PM, Zachary Santer wrote: > Some other nonsense real quick: > > zsant@Zack2021HPPavilion MSYS ~/repos/bash > $ : ${| REPYL="whatever"} > ; } > bash: syntax error near unexpected token `;' while looking for matching `}' &g

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Mon, Dec 23, 2024 at 11:50 AM Chet Ramey wrote: > > On 12/20/24 11:04 AM, Zachary Santer wrote: > > > Explicitly attempting to expand any one of those with a parameter > > expansion when it's unset and 'set -u' is active will cause bash to > > err

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On 12/20/24 11:04 AM, Zachary Santer wrote: Explicitly attempting to expand any one of those with a parameter expansion when it's unset and 'set -u' is active will cause bash to error out. ${| command; } is likewise also an explicit attempt to expand the value of a variable

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Sat, 21 Dec 2024, 04:01 Zachary Santer, wrote: > On Fri, Dec 20, 2024 at 11:50 AM Greg Wooledge wrote: > > I don't think your definition of "explicit" matches mine. > > ${variable} and ${| command; } are explicit expansions in the sense > that I had to write them in the script for the expansi

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

lue should fail if that variable is unset? How far do you want to > > > take that? PS2? PS4? GLOBIGNORE? COMPREPLY? > > > > Explicitly attempting to expand any one of those with a parameter > > expansion when it's unset and 'set -u' is active will cause

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

; > take that? PS2? PS4? GLOBIGNORE? COMPREPLY? > > Explicitly attempting to expand any one of those with a parameter > expansion when it's unset and 'set -u' is active will cause bash to > error out. ${| command; } is likewise also an explicit attempt to > expand the value o

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

, as bash then isn't pointlessly redirecting stdout. > > > > The manual describes 'set -u'/'set -o nounset' thusly: > > Treat unset variables and parameters other than the special parameters > > “@” and “*”, or array variables subscripted with “@” or “*”, as a

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

27;set -o nounset' thusly: Treat unset variables and parameters other than the special parameters “@” and “*”, or array variables subscripted with “@” or “*”, as an error when performing parameter expansion. If expansion is attempted on an unset variable or parameter, the shell prints an error me

Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

On Wed, Dec 18, 2024, at 9:39 PM, Zachary Santer wrote: > $ set -u > $ unset REPLY > $ printf '%s\n' "${REPLY}" > bash: REPLY: unbound variable > $ printf '%s\n' "${| :; }" > > $ printf '%s\n' "${| unset REPLY; }" FWIW, this agrees with mksh R59 2020/10/31 but not zsh master. (I'll be raising the

${| command; } funsub not setting REPLY does not error out with 'set -u' active

that can be made to work by simply removing the space between the > process substitution and the following function substitution. Bash > treats the whole amalgamation as one word. If one wants to use funsubs that don't expand to anything as a workaround like this, it might be more

Re: degraded error message in case of hash-bang interpreter error

On Mon, 4 Nov 2024, 21:37 Robert Elz, wrote: > | I guess I should s/POSIX/common Unix-like tradition/ and maybe > | mumble something about BSD. > > you'd need to go to *every* OS that exists … Good luck with that. Yeah I'm well aware this is futile whimsy. I should have raised this point ab

Re: degraded error message in case of hash-bang interpreter error

On 11/3/24 10:45 PM, Martin D Kealey wrote: This is one of those cases I would file under "POSIX being annoyingly literal". POSIX says that the execve syscall reads the name of an interpreter (and options) from a '#!' line, prefaces them onto the front of argv, and then restarts itself. This i

Re: degraded error message in case of hash-bang interpreter error

Date:Mon, 4 Nov 2024 19:30:23 +1000 From:Martin D Kealey Message-ID: | I guess I should s/POSIX/common Unix-like tradition/ and maybe | mumble something about BSD. Yes, but this would not be the place where it is appropriate to request system call changes - wha

Re: degraded error message in case of hash-bang interpreter error

Fair point. I guess I should s/POSIX/common Unix-like tradition/ and maybe mumble something about BSD. On Mon, 4 Nov 2024, 17:54 Robert Elz, wrote: > Date:Mon, 4 Nov 2024 06:55:54 +0300 > From:=?UTF-8?B?T8SfdXo=?= > Message-ID: < > cah7i3lrjfhfgcejhmrmwd7mu2hu4r_oum

Re: degraded error message in case of hash-bang interpreter error

Date:Mon, 4 Nov 2024 06:55:54 +0300 From:=?UTF-8?B?T8SfdXo=?= Message-ID: | On Monday, November 4, 2024, Martin D Kealey | wrote: | | > POSIX says that the execve syscall reads the name of an interpreter (and | > options) from a '#!' line, | > | | W

Re: degraded error message in case of hash-bang interpreter error

On Monday, November 4, 2024, Martin D Kealey wrote: > POSIX says that the execve syscall reads the name of an interpreter (and > options) from a '#!' line, > Where? -- Oğuz

Re: degraded error message in case of hash-bang interpreter error

ave "access" and "stat" say "OK" but "execve" say "File does not exist". To my mind, the name of the interpreter is an internal detail, so a more logical error to return would be ENOEXEC aka 'Exec format error'. It would be a trivial chan

Re: degraded error message in case of hash-bang interpreter error

On 11/2/24 8:43 AM, hmms...@kpnplanet.nl wrote: Bash Version: 5.2 Patch Level: 9 Release Status: release Description: If the interpreter after #! is wrong, a non-informative message prints Repeat-By: "unix2dos bashscript" starting with #!/bin/bash ./bashscript bash

degraded error message in case of hash-bang interpreter error

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=

Re: errno not restore before printing error in exec_builtin

On 10/27/24 7:47 PM, Emanuele Torre wrote: In a branch of exec_builtin(), errno is not restored before printing an error message, and that causes "Success" to be printed. Thanks for the report. The right fix for this is to suppress the exec builtin printing an error message in the c

Re: errno not restore before printing error in exec_builtin

ble_file() function call above, so maybe the correct fix is to change else => "else if (errno)" instead of restoring it. Anyway, that does not address that this if-elseif-else block always prints duplicate errors. I have not found any case in which after shell_execve() is called, t

errno not restore before printing error in exec_builtin

In a branch of exec_builtin(), errno is not restored before printing an error message, and that causes "Success" to be printed. Example: $ # bash 5.2.37 $ cd /tmp $ echo "export env='\''$(echo {1..100500})'\''" > src $ . ./sr

Re: No error for missing semicolon before "then"

On 9/6/24 11:44 AM, Ulrich Mueller wrote: Bash Version: 5.2 Patch Level: 32 Release Status: release Description: The following command does not error out, in spite of a semicolon missing before "then": $ if [[ x ]] then :; fi Previous versions (e

No error for missing semicolon before "then"

Radeon Graphics AuthenticAMD GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 32 Release Status: release Description: The following command does not error out, in spite of a semicolon missing before "then": $ if [[ x ]] then :; fi

Re: [PATCH] Correct error message when using -n and -o ignoreeof in interactive mode

Date:Wed, 21 Aug 2024 12:09:06 -0400 From:Grisha Levit Message-ID: | I've found using | | bash --norc -in <<< INPUT | | invaluable for testing input handling so I hope that remains an option. That kind of thing (not precisely that) is why the NetBSD s

Re: [PATCH] Correct error message when using -n and -o ignoreeof in interactive mode

On 8/21/24 12:09 PM, Grisha Levit wrote: On Wed, Aug 21, 2024, 11:27 Chet Ramey > wrote: On 8/19/24 9:52 AM, Ángel wrote: > On 2024-08-18 at 11:21 +0700, Robert Elz wrote: >> Interactive shells with -n (noexec) set are pointless > > The man pag

Re: [PATCH] Correct error message when using -n and -o ignoreeof in interactive mode

On Wed, Aug 21, 2024, 11:27 Chet Ramey wrote: > On 8/19/24 9:52 AM, Ángel wrote: > > On 2024-08-18 at 11:21 +0700, Robert Elz wrote: > >> Interactive shells with -n (noexec) set are pointless > > > > The man page states: > >>-n Read commands but do not execute them. This may

Re: [PATCH] Correct error message when using -n and -o ignoreeof in interactive mode

On 8/19/24 9:52 AM, Ángel wrote: On 2024-08-18 at 11:21 +0700, Robert Elz wrote: Interactive shells with -n (noexec) set are pointless The man page states: -n Read commands but do not execute them. This may be used to check a shell script for synta

Re: [PATCH] Correct error message when using -n and -o ignoreeof in interactive mode

On 2024-08-18 at 11:21 +0700, Robert Elz wrote: > Interactive shells with -n (noexec) set are pointless The man page states: > -n Read commands but do not execute them. This may be used > to check a shell script for syntax errors. This is ig‐ >

Re: [PATCH] Correct error message when using -n and -o ignoreeof in interactive mode

Date:Sun, 18 Aug 2024 02:09:10 +0200 From:Milana <948...@riseup.net> Message-ID: | I recently encountered an issue while experimenting with different shell | options in Bash. When launching Bash with both the `-n` (noexec) and `-o | ignoreeof` flags in interac

[PATCH] Correct error message when using -n and -o ignoreeof in interactive mode

'exit' to leave the shell." Since no commands can be executed in this state due to the `noexec` option, this message might be misleading. To address this, I've created a small patch that adjusts the error message depending on whether Bash is in command execution mode or

Re: $@ in function gives error

27; null or more non whitespace ' when u dont "$@" quote it it goes prolly on wordsplitting away and calling the script as follows: > > :~> LC_ALL=C . ./test.sh a b c d > > gives the following error: > > bash: [: too many arguments > > Fix: > > When assigning $@ to a parameter p and using that parameter as "$p" > instead of "$@" > it works OK. > > fr.gr. > > Freek de Kruijf > >

  1   2   3   4   5   6   7   8   9   10   >