Re: Heap-buffer-overflow in read_token_word() when read element with -1 index

On 4/23/25 1:37 PM, Grisha Levit wrote: On Wed, Apr 23, 2025, 11:40 Chet Ramey wrote: On 4/23/25 11:30 AM, Александр Ушаков wrote: I encountered an issue in Bash and would like to report it. buggyfile.txt is attached to the email. Steps to reproduce $ CC=clang-19 CFLAGS="-fsanitize=addres

Re: Heap-buffer-overflow in read_token_word() when read element with -1 index

On Wed, Apr 23, 2025, 11:40 Chet Ramey wrote: > > On 4/23/25 11:30 AM, Александр Ушаков wrote: > > > I encountered an issue in Bash and would like to report it. buggyfile.txt > > is attached to the email. > > > > Steps to reproduce > > > > $ CC=clang-19 CFLAGS="-fsanitize=address -g -O0" ./config

Re: Heap-buffer-overflow in read_token_word() when read element with -1 index

On 4/23/25 11:30 AM, Александр Ушаков wrote: I encountered an issue in Bash and would like to report it. buggyfile.txt is attached to the email. Steps to reproduce $ CC=clang-19 CFLAGS="-fsanitize=address -g -O0" ./configure --without-bash-malloc $ make $ cat crash1.txt | ./bash --norc --noe

Re: BashPitfall 65, read reading past the delimiter on records ending in truncated characters

My two cents: I know `read` to be one of the worst way for reading data, in term of performances. I know *shell* not to be able to manage binary and mostly null bytes, The most reliable way I use for parsing strings that contain null bytes is mapfile (readarray): $ printf %b\\0 winter spring 's

Re: Bash documentation is missing ID anchor

On 4/19/25 12:02 AM, Antti Savolainen wrote: https://www.gnu.org/software/bash/manual/html_node/Directory-Stack-Builtins.html pushd on this page is missing an anchor and I'm unable to link directly to it due to that. Looks like the scripts that generate the HTML require that @item come before @

Re: Bash shell uses wrong language

On 2025-04-14 at 10:59 -0400, Greg Wooledge wrote: > Are bilingual but primarily-English-speaking end users expected to put > "en@quot" as their preferred language in the LANGUAGE variable, in order > to get messages in English? > > Would creating an empty /usr/share/locale/en/LC_MESSAGES/bash.mo

Re: BashPitfall 65, read reading past the delimiter on records ending in truncated characters

On 4/21/25 2:48 AM, Stephane Chazelas wrote: 2025-04-20 17:31:56 -0400, Chet Ramey: [...] This has been fixed since last July, and the fix is in bash-5.3. [...] Thanks, though as Greg says, there seems to be a few more related issues still affecting 5.3. I repost a message sent privately below

Re: BashPitfall 65, read reading past the delimiter on records ending in truncated characters

On 4/20/25 6:58 PM, Greg Wooledge wrote: That one may be fixed, but: bash-5.3$ printf 'FOO\0\315\0\226\0' | while IFS= read -rd '' f; do printf '<%q>\n' "$f"; done <$'\315'> <''> <''> The context for all of this was someone in IRC who was reading a chunk of data from /dev/urandom and got dif

Re: BashPitfall 65, read reading past the delimiter on records ending in truncated characters

2025-04-20 17:31:56 -0400, Chet Ramey: [...] > This has been fixed since last July, and the fix is in bash-5.3. [...] Thanks, though as Greg says, there seems to be a few more related issues still affecting 5.3. I repost a message sent privately below now that the discussion has been extended to t

Re: BashPitfall 65, read reading past the delimiter on records ending in truncated characters

On Sun, Apr 20, 2025 at 17:31:56 -0400, Chet Ramey wrote: > On 4/20/25 3:08 AM, Stephane Chazelas wrote: > > > $ printf '%b\0' winter 'spring\0315' summer automn | > > bash -c 'while IFS= read -rd "" season; do printf "<%q>\n" "$season"; > > done' > > > > <$'spring\315'> > > > > > > skippi

Re: Heap-buffer-overflow in parse_matched_pair when push_delimiter (dstack, ch) macros opens up

On 4/20/25 2:45 PM, Александр Ушаков wrote: Dear Bash Maintainers, I encountered an issue in Bash and would like to report it. buggyfile.txt is attached to the email. The attached file is just a copy of bashbug. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

Re: Make cd built-in as resilient as mkdir -p built-in

On 4/12/25 3:29 AM, Laurent Lyaudet wrote: Le ven. 11 avr. 2025 à 18:11, Chet Ramey > a écrit : On 4/10/25 12:29 PM, Laurent Lyaudet wrote: > Hello :), > > Recently, I noticed during tests that mkdir -p can handle paths beyond > PATH_MAX tha

Re: tiny tweak to examples/functions/autoload.v3 (email addresses)

On 4/11/25 7:24 PM, Mark Kennedy wrote: Thanks, I'll update your email address. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signatur

Re: Bash shell uses wrong language

On 4/14/25 10:56 AM, Kaulkwappe wrote: Hi Chet! Can you confirm that Bash really has translations for 'en_US'? Because you say: If there is no installed locale for en_US [...] No, very few programs do. The Debian 12 system I looked at claims to have en_US installed, but nothing in /usr/share/

Re: Bash shell uses wrong language

++ On Mon, Apr 14, 2025, 16:46 Chet Ramey wrote: > On 4/13/25 11:37 AM, microsuxx wrote: > > seems to cycle between lc : parts one loose .. > > No, these are all translated strings. > > >> hobbit:~$ LANGUAGE=en_US:es_ES bash --version > >> GNU bash, versión 5.2.15(1)-release (x86_64-pc-linux-gnu

Re: Bash shell uses wrong language

On Mon, Apr 14, 2025 at 10:44:06 -0400, Chet Ramey wrote: > According to > https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html#tag_08_02 > > only gettext(3) looks at LANGUAGE, and that behavior can't be modified by > any calls to setlocale(3). gettext(3) is responsible for ov

Re: Bash shell uses wrong language

se. -- Kaulkwappe From: Chet Ramey Sent: Monday, 14. Apr 2025 – 16:44 CEST +0200 To: Kaulkwappe bug-bash@gnu.org CC: chet.ra...@case.edu Subject: Re: Bash shell uses wrong language On 4/13/25 10:06 AM, Kaulkwappe wrote: > > >

Re: Bash shell uses wrong language

On 4/13/25 11:37 AM, microsuxx wrote: seems to cycle between lc : parts one loose .. No, these are all translated strings. hobbit:~$ LANGUAGE=en_US:es_ES bash --version GNU bash, versión 5.2.15(1)-release (x86_64-pc-linux-gnu) Note the accented `o'. Copyright (C) 2022 Free Software Founda

Re: Bash shell uses wrong language

On 4/13/25 10:06 AM, Kaulkwappe wrote: Hi! I use Fedora 41 KDE and my first and default language is English (primary) and my second language (secondary) is German. However, the Bash shell wrongfully uses the secondary language: bash --version GNU bash, Version 5.2.3

Re: Bash shell uses wrong language

seems to cycle between lc : parts one loose .. On Sun, Apr 13, 2025, 16:46 Greg Wooledge wrote: > On Sun, Apr 13, 2025 at 16:06:46 +0200, Kaulkwappe wrote: > > > bash --version > > > GNU bash, Version 5.2.32(1)-release (x86_64-redhat-linux-gnu) > > > Copyright (C) 2022 Free Software Foundation,

Re: Bash shell uses wrong language

On Sun, Apr 13, 2025 at 16:06:46 +0200, Kaulkwappe wrote: > > bash --version > > GNU bash, Version 5.2.32(1)-release (x86_64-redhat-linux-gnu) > > Copyright (C) 2022 Free Software Foundation, Inc. > > Lizenz GPLv3+: GNU GPL Version 3 oder jünger > > > > > > Dies

Re: /dev/tcp feature request...

On Wed, Apr 9, 2025 at 8:48 AM A. James Lewis wrote: > > Yes, this is how I am doing it currently, but remember that once you > cut that subshell loose, you cannot easily get a response from it and > certainly can't pass variables back... and you are more or less forced > to wait for a sensible ti

Re: Make cd built-in as resilient as mkdir -p built-in

Le ven. 11 avr. 2025 à 18:11, Chet Ramey a écrit : > On 4/10/25 12:29 PM, Laurent Lyaudet wrote: > > Hello :), > > > > Recently, I noticed during tests that mkdir -p can handle paths beyond > > PATH_MAX that is currently 4096. > > But cd cannot do this. > > POSIX requires cd to fail in this case,

Re: /dev/tcp feature request...

++ On Fri, Apr 11, 2025, 17:21 Chet Ramey wrote: > On 4/11/25 11:03 AM, microsuxx wrote: > > same error as eof i'd say .. > > No. The file descriptor is invalid. There is a difference between a read > error (-1/EINVAL) and EOF (0). > > -- > ``The lyf so short, the craft so long to lerne.'' - Cha

Re: Make cd built-in as resilient as mkdir -p built-in

On 4/10/25 12:29 PM, Laurent Lyaudet wrote: Hello :), Recently, I noticed during tests that mkdir -p can handle paths beyond PATH_MAX that is currently 4096. But cd cannot do this. POSIX requires cd to fail in this case, leaving the current directory unchanged. -- ``The lyf so short, the cra

Re: /dev/tcp feature request...

On 4/10/25 7:51 PM, A. James Lewis wrote: I'm not quite sure about that, I would be trying to get back the file descriptor to use for a period and then close it... so if it fails to open, then I don't know if "redirection error" makes sense, but then again, I'm not sure what would the correct err

Re: /dev/tcp feature request...

On 4/11/25 11:03 AM, microsuxx wrote: same error as eof i'd say .. No. The file descriptor is invalid. There is a difference between a read error (-1/EINVAL) and EOF (0). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Ch

Re: /dev/tcp feature request...

same error as eof i'd say .. On Fri, Apr 11, 2025, 01:53 A. James Lewis wrote: > I'm not quite sure about that, I would be trying to get back the file > descriptor to use for a period and then close it... so if it fails to > open, then I don't know if "redirection error" makes sense, but then >

Re: /dev/tcp feature request...

I'm not quite sure about that, I would be trying to get back the file descriptor to use for a period and then close it... so if it fails to open, then I don't know if "redirection error" makes sense, but then again, I'm not sure what would the correct error be. Certainly I would just be checking f

Re: /dev/tcp feature request...

On Tuesday, April 8, 2025, A. James Lewis wrote: > > I have however found it extremely frustrating to open TCP connections > via /dev/tcp, because there appears to be no way to control the > timeout! Same. It'd be nice if bash gave up after $TMOUT seconds -- Oğuz

Re: Make cd built-in as resilient as mkdir -p built-in

Le jeu. 10 avr. 2025 à 18:29, Laurent Lyaudet a écrit : > Hello :), > > Recently, I noticed during tests that mkdir -p can handle paths beyond > PATH_MAX that is currently 4096. > But cd cannot do this. > You have to split your cd commands to go to the farthest directory. > > I think that cd cann

Re: Make cd built-in as resilient as mkdir -p built-in

Le jeu. 10 avr. 2025 à 18:30, Laurent Lyaudet a écrit : > > > Le jeu. 10 avr. 2025 à 18:29, Laurent Lyaudet > a écrit : > >> Hello :), >> >> Recently, I noticed during tests that mkdir -p can handle paths beyond >> PATH_MAX that is currently 4096. >> But cd cannot do this. >> You have to split y

Re: /dev/tcp feature request...

On 4/7/25 6:24 PM, A. James Lewis wrote: I've not been around this mailing list all too long, so I don't know if this has been debated before, but I have always attempted to avoid using external programs where functionality within bash can meet a requirement. Doing this allows my scripts to be m

Re: 2.0..devel: `set -u; a=1; echo ${#a[@]}' fails

On 4/7/25 12:36 PM, Koichi Murase wrote: So to be clear, you're requesting a behavior change so that expanding ${#a[0]}, ${#a[*]}, and ${#a[@]}, where a is a scalar variable, when nounset is enabled, does not result in an unbound variable error. Right. That is the behavior I naively expect.

Re: Bash skips empty lines when reading history file in multiline mode

On 4/4/25 4:18 PM, Jens Schmidt wrote: [bashbug output manually adapted to real version ...] Bash Version: 5.3 Commit: a6767763de5e7859107711b166a64a9e4a77a8ae Release Status: compiled from recent devel branch Description: Bash skips empty lines when reading history file in multiline mode.

Re: 3 updates for 5.3rc1

On 4/6/25 3:16 AM, Duncan Roe wrote: Hi, I found the following 3 items. They are addressed by the patch in next email. Patch is against 2e113467f061587a3475b692d25ca449717834c8 in the devel branch. Thanks for the message. 1. The new fltexpr loadable builtin doesn't get built. Need to move it

Re: Support ksh93 x=${cmd;}

On 4/9/25 9:31 AM, Dan Shelton wrote: On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote: On 4/9/25 2:09 AM, Cedric Blancher wrote: Good morning! Could bash please support x=${cmd;} alongside x=$(cmd)? I implemented it back in 2023 and it will be in bash-5.3. There was quite a long discussion

Re: Support ksh93 x=${cmd;}

Besides, HP-UX sh is ksh88 :-) no risk anyone port anything from there.

Re: Support ksh93 x=${cmd;}

On 4/9/25 9:46 AM, Dan Shelton wrote: What is not great is the cmd | x=${|cmd;} extension in HP/UX which randomly hung or crashed /bin/sh in a way to make the tty locked and unuseable. Sure, I get that. I wager that there are comparatively few people who will assume this is an implementation o

Re: Bash skips empty lines when reading history file in multiline mode

i dunno what lithist is , but remaining data one to one is a big bug thats gotta be fixed its like u write foo "$1" "$2" and it sends foo $1 $2 .. if data , in case heredoc content , which is highly underrated and underused , is not remained .. its nothing else than a big broken cmd plz fixx greets

Re: /dev/tcp feature request...

Yes, this is how I am doing it currently, but remember that once you cut that subshell loose, you cannot easily get a response from it and certainly can't pass variables back... and you are more or less forced to wait for a sensible timeout, even tho the actual connection might take a much short

Re: Support ksh93 x=${cmd;}

On Wed, 9 Apr 2025 at 15:40, Chet Ramey wrote: > > On 4/9/25 9:31 AM, Dan Shelton wrote: > > On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote: > >> > >> On 4/9/25 2:09 AM, Cedric Blancher wrote: > >>> Good morning! > >>> > >>> Could bash please support x=${cmd;} alongside x=$(cmd)? > >> > >> I imple

Re: Support ksh93 x=${cmd;}

On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote: > > On 4/9/25 2:09 AM, Cedric Blancher wrote: > > Good morning! > > > > Could bash please support x=${cmd;} alongside x=$(cmd)? > > I implemented it back in 2023 and it will be in bash-5.3. Thank you. I like the x=${ cmd;} feature :) Dan -- Dan Sh

Re: Support ksh93 x=${cmd;}

On Wed, 9 Apr 2025 at 15:16, Chet Ramey wrote: > > On 4/9/25 2:09 AM, Cedric Blancher wrote: > > Good morning! > > > > Could bash please support x=${cmd;} alongside x=$(cmd)? > > I implemented it back in 2023 and it will be in bash-5.3. > > There was quite a long discussion about it: > > https://l

Re: Support ksh93 x=${cmd;}

On 4/9/25 2:09 AM, Cedric Blancher wrote: Good morning! Could bash please support x=${cmd;} alongside x=$(cmd)? I implemented it back in 2023 and it will be in bash-5.3. There was quite a long discussion about it: https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00042.html -- ``The ly

Re: Support ksh93 x=${cmd;}

Cedric Blancher writes: > Good morning! > > Could bash please support x=${cmd;} alongside x=$(cmd)? > > x=$(cmd;} works like x=$(cmd), except that cmd does not run in > a subshell, i.e. the stdout within ${cmd;} is redirected to the > variable "x", but any other changes of variables (global/stati

Re: Problem in trap help message

On 4/8/25 3:55 PM, Rafael Fontenelle via Bug reports for the GNU Bourne Again SHell wrote: Translating bash 5.3-pre1, I faced a string change in trap's help message that I didn't quite understand. The phrase in 5.3-pre1: --- If a SIGNAL_SPEC is DEBUG, ACTION is executed before every simple comma

Re: /dev/tcp feature request...

[[ -d /proc/"$!" ]] On Tue, Apr 8, 2025, 16:33 Andreas Schwab wrote: > On Apr 08 2025, MacBeth wrote: > > > while ((dur /dev/null; do > > You can use kill -0 $! to check if the process still exists. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 197

Re: /dev/tcp feature request...

On Apr 08 2025, MacBeth wrote: > while ((dur /dev/null; do You can use kill -0 $! to check if the process still exists. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Re: /dev/tcp feature request...

On Tue, Apr 8, 2025 at 8:54 AM MacBeth wrote: > > On Mon, Apr 7, 2025 at 5:37 PM A. James Lewis wrote: > > > > I have always attempted to avoid > > using external programs where functionality within bash can meet a > > requirement. Doing this allows my scripts to be more reliable, and not > > de

Re: /dev/tcp feature request...

On Tue, Apr 8, 2025 at 8:54 AM MacBeth wrote: > > script begin ... sample output being: $ . tcp.sh HTTP/1.0 200 OK Done with: www.google.com HTTP/1.0 200 OK Done with: www.example.com sleeping... waiting on 8.8.8.9 sleeping... waiting on 8.8.8.9 sleeping... waiting on 8.8.8.9 sleeping... wa

Re: /dev/tcp feature request...

On Mon, Apr 7, 2025 at 5:37 PM A. James Lewis wrote: > > I have always attempted to avoid > using external programs where functionality within bash can meet a > requirement. Doing this allows my scripts to be more reliable, and not > depend on those external tools being installed... > > I have ho

Re: /dev/tcp feature request...

On Tue, Apr 8, 2025 at 7:16 AM Zachary Santer wrote: > > Is there a good tutorial on how to actually use /dev/tcp? > I found a number of helpful results on google... https://www.google.com/search?q=%2Fdev%2Ftcp For instance: https://medium.com/@stefanos.kalandaridis/bash-ing-your-network-

Re: /dev/tcp feature request...

On Tue, Apr 8, 2025 at 7:04 AM Greg Wooledge wrote: > > On Tue, Apr 08, 2025 at 06:34:50 +0300, Oğuz wrote: > > On Tuesday, April 8, 2025, A. James Lewis wrote: > > > I have however found it extremely frustrating to open TCP connections > > > via /dev/tcp, because there appears to be no way to co

Re: /dev/tcp feature request...

On Tue, Apr 08, 2025 at 06:34:50 +0300, Oğuz wrote: > On Tuesday, April 8, 2025, A. James Lewis wrote: > > I have however found it extremely frustrating to open TCP connections > > via /dev/tcp, because there appears to be no way to control the > > timeout! > > Same. It'd be nice if bash gave up

Re: Bash skips empty lines when reading history file in multiline mode

On 2025-04-07 22:34, Chet Ramey wrote: > On 4/4/25 4:18 PM, Jens Schmidt wrote: > >> [bashbug output manually adapted to real version ...] >> Bash Version: 5.3 >> Commit: a6767763de5e7859107711b166a64a9e4a77a8ae >> Release Status: compiled from recent devel branch >> >> >> Description: >>    Bash

Re: Bash skips empty lines when reading history file in multiline mode

one small addition , <<'foo' ( with quotes is used ) .. .. should tell bash expliciply preserve data .. On Mon, Apr 7, 2025, 23:51 microsuxx wrote: > i dunno what lithist is , but remaining data one to one is a big bug thats > gotta be fixed > its like u write foo "$1" "$2" and it sends foo $1 $

Re: 2.0..devel: `set -u; a=1; echo ${#a[@]}' fails

Thank you for your answer. 2025年4月8日(火) 0:40 Chet Ramey : > OK, so you're asking for a new feature/behavior change. Yes. > don't get me wrong, but it's a little late in the cycle for bash-5.3. Yeah, that makes sense. I don't mind if the change would be applied in a later version. > > I'd be ha

Re: 2.0..devel: `set -u; a=1; echo ${#a[@]}' fails

On 4/5/25 5:37 PM, Koichi Murase wrote: With nounset, ${#a[@]} for a scalar variable fails even though we can correctly obtain the result (which is consistent with the expansion of "${a[@]}") without nounset. This is the result with the devel version: $ bash -c 'a=1; echo ${#a[@]}' 1 $

Re: [PATCH 1/1] Build loadable builtin fltexpr; fix help for history and export

On Sun, Apr 06, 2025 at 05:16:18PM +1000, Duncan Roe wrote: > --- > builtins/history.def | 3 ++- > builtins/setattr.def | 2 +- > examples/loadables/Makefile.in | 4 ++-- > 3 files changed, 5 insertions(+), 4 deletions(-) BTW if you like the above patches, save the email to a

Re: ;exit in bash history causes bash to exit

t; > > Repeat-By: > > Open a terminal with bash as the shell > > Type `;exit` > > This results in > > bash: syntax error near unexpected token `;' > > but not in closing the shell. > > > Re-open the terminal, it will immediately close > > Is there maybe something broken in your setup? > > Best regards, > > Martin

Re: Surprising behavior with inline environment variable expansion

On Mär 31 2025, Chet Ramey wrote: > It's hard to see these as being useful if they're glibc-specific. They are coming from ISO TR 14652 and 30112. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely

Re: Surprising behavior with inline environment variable expansion

On Mär 26 2025, Andreas Kähäri wrote: > The argument to "bash -c" There is no "bash -c" in that command. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Re: Surprising behavior with inline environment variable expansion

On 3/30/25 2:34 AM, Robert Elz wrote: Date:Thu, 27 Mar 2025 17:22:03 -0400 From:Chet Ramey Message-ID: <6da17a73-2aac-4fa5-9fa7-5bfff087d...@case.edu> | The shell should assume that setting a shell variable means the | user wants to modify the shell's local

Re: Surprising behavior with inline environment variable expansion

On 3/29/25 4:52 PM, Lawrence Velázquez wrote: Additional macro definitions, beginning with the characters LC_ and an uppercase letter, may also be specified by the implementation. https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/basedefs/locale.h.html Thank

Re: Surprising behavior with inline environment variable expansion

On 3/31/25 12:52 PM, Andreas Schwab wrote: On Mär 31 2025, Chet Ramey wrote: It's hard to see these as being useful if they're glibc-specific. They are coming from ISO TR 14652 and 30112. OK. And when other systems support them, and they get standardized, it will be time to revisit the issu

Re: Surprising behavior with inline environment variable expansion

Date:Thu, 27 Mar 2025 17:22:03 -0400 From:Chet Ramey Message-ID: <6da17a73-2aac-4fa5-9fa7-5bfff087d...@case.edu> | The shell should assume that setting a shell variable means the | user wants to modify the shell's locale settings. Yes, of course, the question is

Re: Surprising behavior with inline environment variable expansion

On Sat, Mar 29, 2025, at 4:52 PM, Lawrence Velázquez wrote: > https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/locale.h;hb=glibc-2.41#l33 > https://sourceware.org/git/?p=glibc.git;a=blob;f=locale/langinfo.h;hb=glibc-2.41#l584 > https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/loca

Re: Surprising behavior with inline environment variable expansion

On Sat, Mar 29, 2025, at 2:25 PM, Chet Ramey wrote: > How does a locale doing this expose the category to the programmer? > I suppose all possible additional locale categories have to be available > to setlocale() somehow, via and the documentation. Yeah, looks like POSIX explicitly permits that:

Re: Surprising behavior with inline environment variable expansion

On 3/29/25 12:05 AM, Lawrence Velázquez wrote: On Thu, Mar 27, 2025, at 5:22 PM, Chet Ramey wrote: On 3/26/25 6:29 PM, Robert Elz wrote: LANG is generally just the fallback for categories that haven't been set to something else. For this, assume the LC_ALL had never been set (setting LANG aft

Re: Surprising behavior with inline environment variable expansion

On Thu, Mar 27, 2025, at 5:22 PM, Chet Ramey wrote: > On 3/26/25 6:29 PM, Robert Elz wrote: >> LANG is generally just the fallback for categories that haven't been >> set to something else. For this, assume the LC_ALL had never been >> set (setting LANG after that is set should probably just do n

Re: Surprising behavior with inline environment variable expansion

On 3/26/25 6:29 PM, Robert Elz wrote: Date:Wed, 26 Mar 2025 16:05:57 -0400 From:Chet Ramey Message-ID: | There is a precedence hierarchy associated with locale environment | variables, since setting and unsetting environment variables is under | the use

Re: Surprising behavior with inline environment variable expansion

Le 26/03/2025 à 21:18, Chet Ramey écrivait : I think you're misunderstanding the order of execution here. What additions would you suggest? The order of execution is described in SIMPLE COMMAND EXPANSION. The locale variables and their precedence hierarchy are described in Shell Variables with t

Re: ;exit in bash history causes bash to exit

Ethan Gascoigne writes: > Narrowed it down to the line `eval "$(fasd --init auto)"` in my > .bashrc. Must be some kindof bug with fasd > (https://github.com/whjvenyl/fasd). Any idea how fasd could cause > `;exit` to be interpreted as a valid command? Running `alias exit` > shows that it's not alia

Re: Surprising behavior with inline environment variable expansion

Date:Wed, 26 Mar 2025 16:05:57 -0400 From:Chet Ramey Message-ID: | There is a precedence hierarchy associated with locale environment | variables, since setting and unsetting environment variables is under | the user's control. This brings up an unrelated, bu

Re: Surprising behavior with inline environment variable expansion

On 3/26/25 8:20 AM, Léa Gris wrote: I am onto something here : No, not really. It's pretty simple. $ LC_ALL=C bash -c 'locale; printf "\\nEnvironment variable: LC_NUMERIC=%s\ \n" "$LC_NUMERIC"' LC_ALL overrides LC_NUMERIC, as explained in the POSIX reference I sent. Setting LC_ALL doesn't c

Re: Surprising behavior with inline environment variable expansion

On 3/26/25 8:09 AM, Léa Gris wrote: I wonder if locale is switched accordingly to environment variables, but environment variables may not automatically switch to the new locale. There is a precedence hierarchy associated with locale environment variables, since setting and unsetting environm

Re: Surprising behavior with inline environment variable expansion

On 3/26/25 6:52 AM, Léa Gris wrote: LANG=C LC_NUMERIC=C printf '%s\t%f\t%f\n' "$LC_NUMERIC" 3.141592654 3,141592654 Outputs: bash: printf: 3,141592654: invalid number fr_FR.UTF-8    3.141593    3.00 In this particular case, the expansion of LC_NUMERIC is performed before the `printf' bu

Re: Surprising behavior with inline environment variable expansion

On 3/26/25 7:54 AM, Andreas Kähäri wrote: On my Alpine system (bash 5.3.37), LC_NUMERIC is unset, and setting LC_ALL does not automagically set LC_NUMERIC in "bash -c": % LC_ALL=C bash -c 'echo "$LC_NUMERIC"' (blank line output) % LANG=C bash -c 'echo "$LC_NUMERIC"'

Re: Surprising behavior with inline environment variable expansion

Le 26/03/2025 à 12:54, Andreas Kähäri wrote : On my Alpine system (bash 5.3.37), LC_NUMERIC is unset, and setting LC_ALL does not automagically set LC_NUMERIC in "bash -c": % LC_ALL=C bash -c 'echo "$LC_NUMERIC"' (blank line output) % LANG=C bash -c 'echo "$LC_NUMERIC"'

Re: ;exit in bash history causes bash to exit

; > > Repeat-By: > > > Open a terminal with bash as the shell > > > Type `;exit` > > > > This results in > > > > bash: syntax error near unexpected token `;' > > > > but not in closing the shell. > > > > > Re-open the terminal, it will immediately close > > > > Is there maybe something broken in your setup? > > > > Best regards, > > > > Martin > >

Re: Surprising behavior with inline environment variable expansion

On Wed, Mar 26, 2025 at 01:35:12PM +0100, Andreas Schwab wrote: > On Mär 26 2025, Andreas Kähäri wrote: > > > The argument to "bash -c" > > There is no "bash -c" in that command. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3

Re: Surprising behavior with inline environment variable expansion

On Wed, Mar 26, 2025 at 13:09:45 +0100, Léa Gris wrote: > $ LC_ALL=C locale > LANG=fr_FR.UTF-8 > LANGUAGE=fr_FR:fr_CA:en > LC_CTYPE="C" > LC_NUMERIC="C" > LC_TIME="C" > LC_COLLATE="C" > LC_MONETARY="C" > LC_MESSAGES="C" > LC_PAPER="C" > LC_NAME="C" > LC_ADDRESS="C" > LC_TELEPHONE="C" > LC_MEASUREME

Re: Surprising behavior with inline environment variable expansion

I am onto something here : $ LC_ALL=C bash -c 'locale; printf "\\nEnvironment variable: LC_NUMERIC=%s\\n" "$LC_NUMERIC"' Output: LANG=fr_FR.UTF-8 LANGUAGE=fr_FR:fr_CA:en LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="

Re: Surprising behavior with inline environment variable expansion

On Wed, Mar 26, 2025 at 12:19:48PM +0100, Andreas Schwab wrote: > On Mär 26 2025, Léa Gris wrote: > > > Even though LC_NUMERIC=C is used to correctly parse 3.141592654, the > > expansion of $LC_NUMERIC still prints its original value (fr_FR.UTF-8). > > That is expected. The reference to LC_NUMER

Re: Surprising behavior with inline environment variable expansion

On Mär 26 2025, Léa Gris wrote: > Even though LC_NUMERIC=C is used to correctly parse 3.141592654, the > expansion of $LC_NUMERIC still prints its original value (fr_FR.UTF-8). That is expected. The reference to LC_NUMERIC is expanded before the command execution is started (which includes putti

Re: ;exit in bash history causes bash to exit

On Tue, Mar 25, 2025 at 05:55:23PM -0400, Greg Wooledge wrote: > On Tue, Mar 25, 2025 at 22:16:15 +0100, microsuxx wrote: > > when bash reads exit cmd it will exit > > so bash reads rc and exits .. > > also .. u may have a ';exit' alias .. > > The claim is that the ;exit appears in .bash_history (n

Re: ;exit in bash history causes bash to exit

; Patch Level: 37 >> Release Status: release >> >> Description: >> Having ";exit" as the last entry in .bash_history, causes bash >> to immediately exit when loading >> Note: Also appears to happen with alises. For example I have >&

Re: ;exit in bash history causes bash to exit

ah bash history file .. .. yea i tried , bash dev doesnt segfault or anything , with it on a line and without an ending newline warm greetings .. :)) On Tue, Mar 25, 2025, 22:56 Greg Wooledge wrote: > On Tue, Mar 25, 2025 at 22:16:15 +0100, microsuxx wrote: > > when bash reads exit cmd it will

Re: ;exit in bash history causes bash to exit

On Tue, Mar 25, 2025 at 22:16:15 +0100, microsuxx wrote: > when bash reads exit cmd it will exit > so bash reads rc and exits .. > also .. u may have a ';exit' alias .. The claim is that the ;exit appears in .bash_history (not .bashrc) and that this somehow causes a new instance of bash to exit.

Re: ;exit in bash history causes bash to exit

lises. For example I have > `q` aliased to `exit`, and `;q` causes > > > Repeat-By: > Open a terminal with bash as the shell > Type `;exit` > Re-open the terminal, it will immediately close > >

Re: ;exit in bash history causes bash to exit

Hello Ethan, I can't reproduce the problem: > Repeat-By: > Open a terminal with bash as the shell > Type `;exit` This results in bash: syntax error near unexpected token `;' but not in closing the shell. > Re-open the terminal, it will immed

Re: foo=bar baz=${|...;} cmd segfauls after running ...

On 3/23/25 7:37 PM, Emanuele Torre wrote: If you run a simple command that runs something (not just assignments) and contains an assignment word with ${|;} that is preceeded by at least one other assignment word, bash segfaults. Thanks for the report. The fix was a simple matter of swapping two

Re: [sr #111211] `pipefail` leak/disablement

function safe_source() { > local saved_opts=$- > local pipefail_on=0 > > # Check if pipefail is set using 'shopt' > if (set -o | grep -q 'pipefail *on'); then > 'on' or 'off' is preceded by a tab character, plus arbitrary padding spaces, so that won't work. But it's a suboptimal a

Re: [sr #111211] `pipefail` leak/disablement

On Mon, Mar 24, 2025 at 03:47:20AM -0400, anonymous wrote: > # Check if pipefail is set using 'shopt' > if (set -o | grep -q 'pipefail *on'); then > pipefail_on=1 > fi To check if an option is set you use [[ -o pipefail ]], not that thing. Also if you run local - in a fun

Re: Is this a bug?

Hi, George R Goffe writes: > I've been trying to build bash from a repository > "https://git.savannah.gnu.org/git/bash.git"; and a having the devil's own time > in the process. > > Did I just catch the repository in the middle of a rework? I have a > full log of the build process if it's neede

Re: Ctrl+C during ~/.bashrc evaluation leads to unexpected behavior

quot;slow"): trap 'exit $?' SIGINT SIGQUIT # abort login on ctrl-C and ctrl-\ 4) read/include (“.”) files: - recommended by your OS - mandated by your system administrator - for any frameworks you want to use (ble, zcomp - containing your own customisations (Grouping like thi

Re: Ctrl+C during ~/.bashrc evaluation leads to unexpected behavior

On 3/17/25 3:26 PM, Ionut Nicula wrote: Bash Version: 5.2 Patch Level: 15 Release Status: release Description: Had this weird issue on my work laptop where my .bash_history file would get truncated from time to time, and I had no idea what caused it because no background or foreground

Re: Heredoc with a multiline delimiter

On 3/15/25 9:18 PM, Robert Elz wrote: POSIX says: It is unspecified whether the line containing the trailing delimiter is itself subject to this line continuation. which means that nothing is required to make that work. Further, unless bash documents it as working, it is free

Re: Heredoc with a multiline delimiter

On 3/15/25 7:08 PM, MacBeth wrote: On Sat, Mar 15, 2025 at 12:33 PM Greg Wooledge wrote: On Sat, Mar 15, 2025 at 16:14:00 +, Nikola Novak via Bug reports for the GNU Bourne Again SHell wrote: How do you end the heredoc with a multiline delimiter such as the following: cat << "a b" You

  1   2   3   4   5   6   7   8   9   10   >