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

Re: $@ in function gives error

On Sat, Aug 17, 2024, at 6:41 AM, Freek de Kruijf wrote: > Apparently I have a problem with the concept of $@ Greg has already tried explaining it, so I'll just focus on a few details: > I see it as list of zero or more non-whitespaced elements When used in a context where splitting is performe

Re: $@ in function gives error

On Sat, Aug 17, 2024 at 12:41:45 +0200, Freek de Kruijf wrote: > Apparently I have a problem with the concept of $@, I see it as list of zero > or more non-whitespaced elements, and quotes around it makes it into a single > element. Like a parameter p with a content of zero or more non-whitespace

Re: $@ in function gives error

t; > that "$@" expands to multiple fields when there are two or more > > positional parameters, so (as the error message says) you end up > > running test(1) with too many arguments. This is a usage error. > > > > $ set -x a b c d > >

Re: $@ in function gives error

or more > positional parameters, so (as the error message says) you end up > running test(1) with too many arguments. This is a usage error. > > $ set -x a b c d > $ test -n "$@" > + test -n a b c d > bash: test: too many arguments > Apparen

Re: $@ in function gives error

On Fri, Aug 16, 2024 at 18:59:15 +0200, freek--- via Bug reports for the GNU Bourne Again SHell wrote: > #!/bin/bash > init() { > [ -n "$@" ] && echo $@ > } > init $@ You have multiple errors in this script. The first error is that you used $@ without quotes, tw

Re: $@ in function gives error

On Fri, Aug 16, 2024, at 6:29 PM, Lawrence Velázquez wrote: > There is no problem with "$@" or functions here. The "problem" is > that "$@" expands to multiple fields when there are two or more > positional parameters, so (as the error message says) you

Re: $@ in function gives error

script as follows: > > :~> LC_ALL=C . ./test.sh a b c d > > gives the following error: > > bash: [: too many arguments There is no problem with "$@" or functions here. The "problem" is that "$@" expands to multiple fields when there are two

$@ in function gives error

t() { [ -n "$@" ] && echo $@ } init $@ 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

Re: Error in "help ulimit": missing unit info

On 7/14/24 9:59 AM, Carlo Teubner wrote: Bash Version: 5.2 Patch Level: 26 Release Status: release Description: "help ulimit" includes this paragraph: Thanks for the report. This was changed in the devel branch some time ago. -- ``The lyf so short, the craft so long to lerne.'' - Cha

Error in "help ulimit": missing unit info

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-p

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

URL: <https://savannah.gnu.org/bugs/?65638> 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

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

On Apr 15 2024, Greg Wooledge wrote: > And that's a bug. That code is wrong, and it should be written this way > instead: > > [ -z "$var1" ] && [ -z "$var2" ] && continue Or just [ -z "$var1$var2" ] && continue -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

On Mon, Apr 15, 2024 at 08:13:23PM +0200, Emanuel Attila Czirai wrote: > On Mon, Apr 15, 2024 at 7:56 PM Greg Wooledge wrote: > > Sounds like you've found a nontrivial bug in FreeBSD (in the adduser > > script, not in sh). I hope this gets reported and fixed, and in any case, > > good work and th

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

is: [ -z ">" -a -z ">" ] && continue which errors like: [: -a: unexpected operator but the > are $passwordvars so if I want to set the password to ">" for example, I get to see that error, but still works as expected in the end.

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

On Mon, Apr 15, 2024 at 07:04:23PM +0200, Emanuel Attila Czirai wrote: > In my superficial report, I definitely didn't think of that. I even forgot > to mention that it works when escaped like "\>" > > I've encountered it in the "adduser" FreeBSD sh script that runs as root, > while trying to set

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

the angle bracket > char > > followed by -a or -o operators, fails like: > > bash: [: syntax error: `-n' unexpected > > > > Repeat-By: > > > > $ [ -n ">" -a -n "something" ] || echo hmm > > bash: [: syntax error: `-n' unex

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

On 4/14/24 5:16 AM, Emanuel Attila Czirai wrote: Bash Version: 5.2 Patch Level: 26 Release Status: release Description: the [ test with -n or -z on a string that's only the angle bracket char followed by -a or -o operators, fails like: bash: [: syntax error: `-n' unexpected

Re: syntax error with lone > or < as string in [ ] tests with -a or -o operators

On Sun, Apr 14, 2024 at 11:16:27AM +0200, Emanuel Attila Czirai wrote: > $ [ -n ">" -a -n "something" ] || echo hmm > bash: [: syntax error: `-n' unexpected > hmm Don't do this. You're in the land of unspecified behavior here. Use multiple test

syntax error with lone > or < as string in [ ] tests with -a or -o operators

GenuineIntel GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 26 Release Status: release Description: the [ test with -n or -z on a string that's only the angle bracket char followed by -a or -o operators, fails like: bash: [: syntax error: `-n' unexpected Repeat-B

Re: install-headers stdckdint.h error

On Fri, Mar 29, 2024, 09:37 Chet Ramey wrote: > On 3/28/24 9:54 PM, Grisha Levit wrote: > > The addition of stdckdint.h to CREATED_HEADERS in Makefile.in leads to > > an error when installing loadable builtins on platforms that provide > > the header: > > Thanks for th

Re: install-headers stdckdint.h error

On 3/28/24 9:54 PM, Grisha Levit wrote: The addition of stdckdint.h to CREATED_HEADERS in Makefile.in leads to an error when installing loadable builtins on platforms that provide the header: Thanks for the report. What platform are you using that provides that header? -- ``The lyf so short

install-headers stdckdint.h error

The addition of stdckdint.h to CREATED_HEADERS in Makefile.in leads to an error when installing loadable builtins on platforms that provide the header: install: cannot stat '/tmp/bash/stdckdint.h': No such file or directory make[2]: *** [Makefile:903: install-headers] Error 1 make[2

Re: internal error

On 2/12/24 12:02 PM, Frank Heckenbach wrote: On 2/10/24 9:41 PM, Frank Heckenbach wrote: % ./bash -c "set -e; f() { eval false; }; f" ./bash: line 1: pop_var_context: head of shell_variables not a function context Might be related to https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00073.

Re: internal error

> On 2/10/24 9:41 PM, Frank Heckenbach wrote: > > % ./bash -c "set -e; f() { eval false; }; f" > > ./bash: line 1: pop_var_context: head of shell_variables not a function > > context > > > > Might be related to > > https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00073.html, > > but still p

Re: internal error

On 2/10/24 9:41 PM, Frank Heckenbach wrote: % ./bash -c "set -e; f() { eval false; }; f" ./bash: line 1: pop_var_context: head of shell_variables not a function context Might be related to https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00073.html, but still present in 5.2.21. Thanks, i

internal error

% ./bash -c "set -e; f() { eval false; }; f" ./bash: line 1: pop_var_context: head of shell_variables not a function context Might be related to https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00073.html, but still present in 5.2.21.

Re: [PATCH] printf: more error handling

On Sat, Feb 3, 2024 at 1:05 PM Chet Ramey wrote: > > On 2/2/24 6:33 PM, Grisha Levit wrote: > > Is it necessary to check the error indicator if printf(3) just had a non- > > negative return? > > I think printf is allowed to set the error flag that ferror checks even if >

Re: [PATCH 01/18] doc/bash.1: fix rendering error on old *roffs

On 1/31/24 3:40 AM, G. Branden Robinson wrote: The man(7) in Seventh Edition Unix (1979) accepted at most six arguments to any macro. Documenter's Workbench 3.3 troff retains this limitation, as do at least some System V troffs that survive in commercial Unix (such as Solaris 10 troff). Thanks

Re: [PATCH] printf: more error handling

out)) \ 179 { \ Is it necessary to check the error indicator if printf(3) just had a non- negative return? I think printf is allowed to set the error flag that ferror checks even if it returns 0, but I could be convinced otherwise. And, if so, can this check be, as elsewhere: `(vflag =

Re: Error with SIGCHLD trap and process substitution

On 2/2/24 3:32 PM, Tavian Barnes wrote: Bash Version: 5.2 Patch Level: 26 Release Status: release Description: When a SIGCHLD trap is set, commands that include two process substitutions fail with a strange "unexpected EOF" error. Thanks for the report. This was fixed last Sept

Re: [PATCH] printf: more error handling

can append up to INT_MAX bytes to the buffer: > > Thanks for the report and patch. Thanks, a small question -- in your commit[1] you added an ferror check here: 177 nw = vflag ? vbprintf (f, func) : printf (f, func); \ 178 if (nw < 0 || ferror (stdout)) \ 179 { \ I

Error with SIGCHLD trap and process substitution

rocess substitutions fail with a strange "unexpected EOF" error. Repeat-By: [tavianator@tachyon ~]$ trap : SIGCHLD [tavianator@tachyon ~]$ echo "$(id -u):$(id -g)" bash: trap: line 2: unexpected EOF while looking for matching `)' bash: command substitution: line 4: syntax e

Re: [PATCH] printf: more error handling

On 1/22/24 9:44 PM, Grisha Levit wrote: The size of the buffer used for printf -v is tracked in an int but this can overflow since the buffer can be built up by multiple vsnprintf(3) calls, each of which can append up to INT_MAX bytes to the buffer: Thanks for the report and patch. Chet -- ``

[PATCH v2 01/18] doc/bash.1: fix rendering error on old *roffs

Hi Chet, Sorry--I need to update 2 of the items in this series. v2: Fix a goof where I regressed the escaped hyphen in "self-insert". The man(7) in Seventh Edition Unix (1979) accepted at most six arguments to any macro. Documenter's Workbench 3.3 troff retains this limitation, as do at least s

[PATCH 01/18] doc/bash.1: fix rendering error on old *roffs

The man(7) in Seventh Edition Unix (1979) accepted at most six arguments to any macro. Documenter's Workbench 3.3 troff retains this limitation, as do at least some System V troffs that survive in commercial Unix (such as Solaris 10 troff). Quote the mulitiplicity of arguments so that they will a

[PATCH] printf: more error handling

-1))s" Bus error: 10 or when appending individual chars: $ printf -v VAR "%$((INT_MAX-1))sXXX" -bash: xrealloc: cannot allocate 18446744071562068032 bytes The return value of vsnprintf(3) or printf(3) can be negative if, e.g. the underlying write(2) call fails, or if a w

Re: wrong variable name in error message about unbound variable?

On Thu, Oct 19, 2023, 16:58 Chet Ramey wrote: > On 10/17/23 3:32 PM, Grisha Levit wrote: > > > The reason is that if there was no variable found prior to expanding > > the subscript, bash does not check to see if one was created during > > that process. > > Thanks, I'll consider it. Behavior vari

Re: wrong variable name in error message about unbound variable?

On 10/17/23 3:32 PM, Grisha Levit wrote: The reason is that if there was no variable found prior to expanding the subscript, bash does not check to see if one was created during that process. Thanks, I'll consider it. Behavior varies across shells in this area. Chet -- ``The lyf so short, th

Re: wrong variable name in error message about unbound variable?

On Tue, Oct 17, 2023, 10:48 Christoph Anton Mitterer wrote: > > On Tue, 2023-10-17 at 00:26 -0400, Grisha Levit wrote: > > The array subscript can an arbitrary arithmetic expression with side > > effects, so it makes sense to perform the expansion even if the array > > whose subscript is being exp

Re: wrong variable name in error message about unbound variable?

On Tue, Oct 17, 2023, at 10:48 AM, Christoph Anton Mitterer wrote: > As Lawrence pointed out: > $ set -u > $ declare -A a > $ echo ${a[k]} > bash: a[k]: unbound variable > > Here it actually looks first at a (which turns out to be an associative > array) and thus doesn't even bother to evaluate k,

Re: wrong variable name in error message about unbound variable?

On Tue, 2023-10-17 at 00:26 -0400, Grisha Levit wrote: > The array subscript can an arbitrary arithmetic expression with side > effects, so it makes sense to perform the expansion even if the array > whose subscript is being expanded is unset: Okay... that's all pretty convoluted. I assume it boil

Re: wrong variable name in error message about unbound variable?

On Tue, Oct 17, 2023, 16:30 Chet Ramey wrote: > On 10/17/23 8:43 AM, Zachary Santer wrote: > > On Tue, Oct 17, 2023 at 8:00 AM Greg Wooledge wrote: > > > >> unicorn:~$ unset -v a b c array > >> unicorn:~$ a=b b=c c=42 array[a]=foo; declare -p array > >> declare -a array=([42]="foo

Re: wrong variable name in error message about unbound variable?

On 10/17/23 8:43 AM, Zachary Santer wrote: On Tue, Oct 17, 2023 at 8:00 AM Greg Wooledge wrote: unicorn:~$ unset -v a b c array unicorn:~$ a=b b=c c=42 array[a]=foo; declare -p array declare -a array=([42]="foo") What? What is Bash doing here? Dereferencing iteratively until i

Re: wrong variable name in error message about unbound variable?

On Tue, Oct 17, 2023, 15:09 Zachary Santer wrote: > On Tue, Oct 17, 2023 at 8:43 AM Zachary Santer wrote: > > > On Tue, Oct 17, 2023 at 8:00 AM Greg Wooledge wrote: > > > >> unicorn:~$ unset -v a b c array > >> unicorn:~$ a=b b=c c=42 array[a]=foo; declare -p array > >> declare -a a

Re: wrong variable name in error message about unbound variable?

On Tue, Oct 17, 2023 at 8:43 AM Zachary Santer wrote: > On Tue, Oct 17, 2023 at 8:00 AM Greg Wooledge wrote: > >> unicorn:~$ unset -v a b c array >> unicorn:~$ a=b b=c c=42 array[a]=foo; declare -p array >> declare -a array=([42]="foo") >> > What? What is Bash doing here? Dereferenci

Re: wrong variable name in error message about unbound variable?

On Tue, Oct 17, 2023 at 8:00 AM Greg Wooledge wrote: > unicorn:~$ unset -v a b c array > unicorn:~$ a=b b=c c=42 array[a]=foo; declare -p array > declare -a array=([42]="foo") > What? What is Bash doing here? Dereferencing iteratively until it finds something it can do arithmetic with

Re: wrong variable name in error message about unbound variable?

ouldn't it already know that > there is no indexed array of the name "array" and any evaluation of the > subscript is thus pointless? There are two undefined variables at that point, and bash chooses one of them to report. Prioritizing "the important error" over "

  1   2   3   4   5   6   7   8   9   10   >