Re: Mishandled backslashes in patternvar in ${var#...$patternvar...} ?

Date:Sat, 9 Aug 2025 01:35:17 +0200 From:Denys Vlasenko Message-ID: | A year ago, dash had this fix: I would call that a change, rather than a fix. | expand: Fix naked backslah leakage What should happen in such a case all depends upon what you think migh

Re: integer variable that unsets itself causes segfault

On Friday, August 8, 2025, Oğuz wrote: > declare -in x There's also this: $ declare -in x=a[x] $ echo $? 1 $ declare -p x bash: declare: x: not found The error here shouldn't be silent. I can see in gdb that the memory allocated for the `SHELL_VAR' struct for `x' gets freed

Re: integer variable that unsets itself causes segfault

On Friday, August 8, 2025, Chet Ramey wrote: > > That has no resemblance to the test case in the linked message > Both involve `${ break;}' that leaves the shell in a state where no command is executed until the user presses Ctrl-C -- Oğuz

Re: BASH_SOURCE contains incorrect information in Bash 5.3.0

Hello Chet, and thanks for looking into this. On 2025-08-08 at 13:31 +, Chet Ramey wrote: > I can't reproduce it. [...] After your reply I tried again recompiling Bash 5.3 from scratch and indeed I could no longer reproduce the problem with that. But then I tried rebuilding 5.3 the way I w

Mishandled backslashes in patternvar in ${var#...$patternvar...} ?

A year ago, dash had this fix: commit 1f1e555aba99808a82cb5090b5ef980714dea09c Author: Herbert Xu Date: Wed May 1 17:12:27 2024 +0800 expand: Fix naked backslah leakage Naked backslashes in patterns may incorrectly unquote subsequent wild characters that are themselves quoted. F

Re: BASH_SOURCE contains incorrect information in Bash 5.3.0

On 2025-08-08 at 21:39 +, Chet Ramey wrote: > BASH_SOURCE is part of the debugger support. If you disable the debugger > support, BASH_SOURCE is not available. Maybe it should be made clear in the Texinfo manual; but yes, by grepping I found it in the NEWS file. This explains everything then

Re: integer variable that unsets itself causes segfault

On Friday, August 8, 2025, Chet Ramey wrote: > > Thanks for the report. > While exploring it I rediscovered this one from last year < https://lists.gnu.org/archive/html/bug-bash/2024-05/msg00402.html>: $ bash -c 'declare -in x; for x do :; done; date' _ 'a[${ break;}]' $ Guess you don'

Re: BASH_SOURCE contains incorrect information in Bash 5.3.0

On 8/8/25 4:41 PM, Luca Saiu wrote: Hello Chet, and thanks for looking into this. On 2025-08-08 at 13:31 +, Chet Ramey wrote: I can't reproduce it. [...] After your reply I tried again recompiling Bash 5.3 from scratch and indeed I could no longer reproduce the problem with that. But t

Re: integer variable that unsets itself causes segfault

On 8/8/25 4:04 PM, Oğuz wrote: On Friday, August 8, 2025, Chet Ramey > wrote: Thanks for the report. While exploring it I rediscovered this one from last year lists.gnu.org/archive/html/bug-bash/2024-05/msg00402.html lists.gnu.org/archive/html/bug-bash/2024-05/m

Re: integer variable that unsets itself causes segfault

On 8/8/25 3:14 PM, Oğuz wrote: See: $ declare -i x $ x='a[${ unset x;}]' Segmentation fault This shouldn't even be an error; if it has to be it should be handled by bash not the host system Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

integer variable that unsets itself causes segfault

See: $ declare -i x $ x='a[${ unset x;}]' Segmentation fault This shouldn't even be an error; if it has to be it should be handled by bash not the host system Oğuz

Re: [bug #67410] Bash read fails on UTF-8

On 8/8/25 9:50 AM, Lawrence Velázquez wrote: On Fri, Aug 8, 2025, at 9:15 AM, Stan Marsh wrote: I think they meant to use IFS=$'\n' rather than IFS='\n' In which sense of the word "they" (*) ? The gender-neutral singular sense. Please do not attempt to litigate this usage on-list. "Stan"

Re: [bug #67410] Bash read fails on UTF-8

On Fri, Aug 08, 2025 at 07:39:17 -0400, Anonym wrote: > bash-5.3# IFS='\n' read -r detail < <(echo "schön") ; echo "${detail}" > schö > bash-5.3# Just in case the anonymous poster reads this... your IFS is incorrect. You've set it to a literal backslash and lowercase n. What you want is IFS=$'\n

Re: [bug #67410] Bash read fails on UTF-8

On Fri, Aug 8, 2025, at 9:15 AM, Stan Marsh wrote: >>I think they meant to use IFS=$'\n' rather than IFS='\n' > > In which sense of the word "they" (*) ? The gender-neutral singular sense. Please do not attempt to litigate this usage on-list. > In which sense of the word "meant" ? (**) OP inten

Re: BASH_SOURCE contains incorrect information in Bash 5.3.0

On 8/8/25 8:57 AM, Luca Saiu wrote: Hello. I am writing a complex Bash script which on failure prints a stack trace. After upgrading to Bash 5.3.0 I noticed a strange change of behaviour in BASH_SOURCE which I believe is a bug. I can't reproduce it. Using your script, I get $ ./bash ./f-g BA

Re: Feature request (not a bug): enhanced variable substitutions would be nice.

Just for kicks, here's an implementation of "if-then-else" called "ite", as a function. Note that: 1) It is pretty much a drop in for the missing functionality (in the usual ${var:X} syntax), when used inside $(). 2) All of the existing ${var:X} syntaxes are special cases of ite(

Re: [bug #67410] Bash read fails on UTF-8

>I think they meant to use IFS=$'\n' rather than IFS='\n' In which sense of the word "they" (*) ? In which sense of the word "meant" ? (**) (*) I'm pretty sure there's just one poster, not a bunch of them. (**) I'm pretty sure there was no typo or mechanical error when he posted to the list. ==

BASH_SOURCE contains incorrect information in Bash 5.3.0

Hello. I am writing a complex Bash script which on failure prints a stack trace. After upgrading to Bash 5.3.0 I noticed a strange change of behaviour in BASH_SOURCE which I believe is a bug. While FUNCNAME has the correct content, BASH_SOURCE does not match it element-by-element as intended. I

Re: [bug #67410] Bash read fails on UTF-8

I think they meant to use IFS=$'\n' rather than IFS='\n' Cheers. On Fri, Aug 08, 2025 at 07:39:17AM -0400, Anonym wrote: > URL: > > > Summary: Bash read fails on UTF-8 >Group: The GNU Bourne-Again SHell >

[bug #67410] Bash read fails on UTF-8

URL: Summary: Bash read fails on UTF-8 Group: The GNU Bourne-Again SHell Submitter: None Submitted: Fr 08 Aug 2025 11:39:12 UTC Category: None Severity: 3 - No