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: 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: 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: 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: 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: bash --pretty-print and pattern

great hint! many thanks On Thu, 20 Feb 2025 at 14:26, Koichi Murase wrote: > 2025年2月20日(木) 20:51 Timotei Campian : > > echo !(file.f*) > > > > *bash --pretty-print test.sh* > > If this script file "test.sh" will be used as an independent > executable file, to make it work, you need to put "shop

Re: bash --pretty-print and pattern

On 2/20/25 11:04 AM, Koichi Murase wrote: Thank you. I didn't know this behavior. Is that documented? I tried to find it in the description of `--pretty-print', but I realized that the --pretty-print option itself is undocumented. It's not. It's just a novelty. -- ``The lyf so short, the cr

Re: bash --pretty-print and pattern

2025年2月20日(木) 23:37 Chet Ramey : > > $ bash --pretty-print -O extglob test.sh > > You can use BASH_ENV for this. The primary reason that pretty-printing mode > doesn't suppress execution until after any startup files are read is to > allow a custom startup file to set the shell options you want for

Re: bash --pretty-print and pattern

On 2/20/25 7:25 AM, Koichi Murase wrote: However, even if you make sure that "extglob" is enabled when the script file is parsed in real situations as described above, "--pretty-print" still doesn't work because it doesn't execute the file at all. To parse and print a file with the actual set of

Re: bash --pretty-print and pattern

Je Thu, Feb 20, 2025 at 08:29:19AM -0500, Greg Wooledge skribis: > On Thu, Feb 20, 2025 at 21:25:45 +0900, Koichi Murase wrote: > > $ bash --pretty-print -O extglob test.sh > > Yeah, I misread the question a little bit. Sorry about that. > > By the way, is this considered a bug: > > > hobbit:~

Re: bash --pretty-print and pattern

On Thu, Feb 20, 2025 at 21:25:45 +0900, Koichi Murase wrote: > $ bash --pretty-print -O extglob test.sh Yeah, I misread the question a little bit. Sorry about that. By the way, is this considered a bug: hobbit:~$ bash -O extglob --pretty-print x bash: --: invalid option Usage: bash [GNU long

Re: bash --pretty-print and pattern

2025年2月20日(木) 20:51 Timotei Campian : > echo !(file.f*) > > *bash --pretty-print test.sh* If this script file "test.sh" will be used as an independent executable file, to make it work, you need to put "shopt -s extglob" at the beginning of the file as Greg explained in the other reply. If the scr

Re: bash --pretty-print and pattern

On Thu, Feb 20, 2025 at 13:50:29 +0200, Timotei Campian wrote: > *OS*=debian12 > *BASH_VERSION*="5.2.15(1)-release" > > the script test.sh has the following content: > > echo !(file.f*) > > > Now calling bash pretty-print result in this error: > > *bash --pretty-print test.sh* > > file1: lin

Re: bash-5.2.32 fails "make install" on RHEL 9

On 1/25/25 10:44 AM, Dennis Clarke wrote: On 8/26/24 16:29, Chet Ramey wrote: On 8/24/24 11:53 PM, Dennis Clarke via Bug reports for the GNU Bourne Again SHell wrote: This seemed to happen over and over and only during "make install". There are a number of loadable builtins that require arra

Re: bash-5.2.32 fails "make install" on RHEL 9

On 8/26/24 16:29, Chet Ramey wrote: On 8/24/24 11:53 PM, Dennis Clarke via Bug reports for the GNU Bourne Again SHell wrote: This seemed to happen over and over and only during "make install". There are a number of loadable builtins that require arrays and don't build without them. It's anno

Re: bash compat* issues?

On 1/22/25 8:03 AM, MacBeth wrote: $ unset BASH_COMPAT $ declare -p BASH_COMPAT bash: declare: BASH_COMPAT: not found $ BASH_COMPAT=foobar bash: BASH_COMPAT: foobar: compatibility value out of range $ declare -p BASH_COMPAT declare -- BASH_COMPAT="foobar" $ BASH_COMPAT=4.4 /opt/homebrew/bin/bash

Re: bash compat* issues?

On 1/21/25 9:49 PM, MacBeth wrote: re: GNU bash, version 5.2.37(1)-release (aarch64-apple-darwin23.4.0) --- 1) `shopt compat50` does not exist. The manpage does specify that 'compat50' is a valid option for `shopt` under BUILTINS/shopt. Yet bash provides an error when trying to read or change i

Re: bash compat* issues?

2025年1月22日(水) 22:03 MacBeth : > Or perhaps that second error is produced by the parent shell before This. The error message is printed even for "/bin/echo": $ BASH_COMPAT=foo bash: BASH_COMPAT: foo: compatibility value out of range $ BASH_COMPAT=4.4 /bin/echo hello bash: BASH_COMPAT: foo: compati

Re: bash compat* issues?

On Tue, Jan 21, 2025 at 11:25 PM Lawrence Velázquez wrote: > On Tue, Jan 21, 2025, at 9:49 PM, MacBeth wrote: > > "Bash-5.0 is the final version for which there will be an individual > shopt > > option for the previous version. Users should use BASH_COMPAT on bash-5.0 > > and later versions." > >

Re: bash compat* issues?

2025年1月22日(水) 14:25 Lawrence Velázquez : > On Tue, Jan 21, 2025, at 9:49 PM, MacBeth wrote: > > But either > > way, `shopt compat50` should be consistent with BUILTINS/shopt. > > Yeah, probably. I think this is just an error in the man page. The error still exists in the devel branch: https://git

Re: bash compat* issues?

On Tue, Jan 21, 2025, at 9:49 PM, MacBeth wrote: > "Bash-5.0 is the final version for which there will be an individual shopt > option for the previous version. Users should use BASH_COMPAT on bash-5.0 > and later versions." > > ...Not sure if this means `shopt compat50` should work or not. It sho

Re: Bash' code to store string of any characters containing pair of "" and '' at once

Greg Wooledge writes: >> You need to escape one of the types of quotes. Double quotes is >> generally simpler: >> >> $ x="foo \"foo\" and 'bar' content" >> $ echo "$x" >> foo "foo" and 'bar' content > > Only in this restricted case. Using double quotes as the outer layer > means you have to back

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On 12/21/24 7:29 PM, Robert Elz wrote: I'm not sure of its origins (it was proposed to POSIX decades ago), Chet can confirm, but I suspect bash picked it up from the proposal to POSIX. It predated that. There was a group of shell implementors who got together to discuss possible POSIX extensio

Re: Bash' code to store string of any characters containing pair of "" and '' at once

👍 Budi reacted via Gmail On Sun, Dec 22, 2024 at 10:45 AM Martin D Kealey wrote: > > On Sun, 22 Dec 2024, 03:49 Budi, wrote: > >> How is Bash' code to store string of any charact

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Dez 22 2024, Martin D Kealey wrote: > If you don't mind even more thinking then you can instead memorize the list > of characters that need \ and skip all the others; they are space, tab, > newline, and "#$'&<>*()?`\[]| Careful. \ has a different meaning. -- Andreas Schwab, sch...@linux-m68k

Re: Bash' code to store string of any characters containing pair of "" and '' at once

Date:Sun, 22 Dec 2024 13:45:19 +1000 From:Martin D Kealey Message-ID: | But a nagging question is why does the text contain both ' and " | characters? My guess (and that is all it is) is that the answer isn't that it contains both, but that it might contain eit

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sun, Dec 22, 2024 at 13:45:19 +1000, Martin D Kealey wrote: > Failing that, by far the "simplest" approach to "literal" text is not to > have it inside the script, but in a separate file that the script can read. Yes, this. I omitted this case in my initial reply, thought of it later, but didn

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sun, 22 Dec 2024, 03:49 Budi, wrote: > How is Bash' code to store string of any characters should be containing > pair of "" and '' at the same time explicitly, being exact verbatim so, > ie. cannot be modified, escaped or etc, as expected from ordinary/naive > human writing), into a variable

Re: Bash' code to store string of any characters containing pair of "" and '' at once

Date:Sun, 22 Dec 2024 09:39:11 +0700 From:Robert Elz Message-ID: <10875.1734835...@jacaranda.noi.kre.to> | Not sure about current bash I must has been bashed in the brain there, I meant dash, bash has had this for eons (as have most of the others in which it works,

Re: Bash' code to store string of any characters containing pair of "" and '' at once

Date:Sat, 21 Dec 2024 19:47:31 -0500 From:Greg Wooledge Message-ID: <20241222004731.go29...@wooledge.org> | Either way, it's not widespread yet, and one shouldn't expect it to be | available outside of bash. If it were only in bash it would never have made it int

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sun, Dec 22, 2024 at 07:29:14 +0700, Robert Elz wrote: > Date:Sat, 21 Dec 2024 13:49:48 -0500 > From:Greg Wooledge > Message-ID: <20241221184948.gm29...@wooledge.org> > > | Choice #2: use $'...' quoting, > | Choice 2 is a bash extension. > > No it isn't, or at

Re: Bash' code to store string of any characters containing pair of "" and '' at once

Date:Sat, 21 Dec 2024 13:49:48 -0500 From:Greg Wooledge Message-ID: <20241221184948.gm29...@wooledge.org> | Choice #2: use $'...' quoting, | Choice 2 is a bash extension. No it isn't, or at least not any more. Dollar-Quote quoting (sometimes called C-stye strin

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sat, Dec 21, 2024, at 1:52 PM, Greg Wooledge wrote: > On Sat, Dec 21, 2024 at 09:56:15 -0800, Eric Pruitt wrote: >> You need to escape one of the types of quotes. Double quotes is >> generally simpler: > > Only in this restricted case. Using double quotes as the outer layer > means you have to

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sat, Dec 21, 2024 at 09:56:15 -0800, Eric Pruitt wrote: > On Sun, Dec 22, 2024 at 12:49:07AM +0700, Budi wrote: > > How is Bash' code to store string of any characters should be containing > > pair of "" and '' at the same time explicitly, being exact verbatim so, > > ie. cannot be modified, esc

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sun, Dec 22, 2024 at 00:49:07 +0700, Budi wrote: > How is Bash' code to store string of any characters should be containing > pair of "" and '' at the same time explicitly, being exact verbatim I'm interpreting this as: * You would like to store some data in a string variable. * The data is

Re: Bash' code to store string of any characters containing pair of "" and '' at once

On Sun, Dec 22, 2024 at 12:49:07AM +0700, Budi wrote: > How is Bash' code to store string of any characters should be containing > pair of "" and '' at the same time explicitly, being exact verbatim so, > ie. cannot be modified, escaped or etc, as expected from ordinary/naive > human writing), into

Re: Bash spews bracketed-paste escape sequences when handling signal.

On 12/18/24 4:56 PM, Kaz Kylheku wrote: (That would be an issue if we had used eval: eval 'command ... $$ ...' & now we backgrounded the eval, which then in the background process parses the shell syntax and does all the expanding. Now $$ is the PID of the background process, not that of the

Re: Bash spews bracketed-paste escape sequences when handling signal.

On 12/18/24 4:38 PM, Kaz Kylheku wrote: I understand that Bash will die if you send a SIGUSR1, and it has no trap set up for it; but when it does have a handler set up, it seems that Readline may be blocking the signal (perhaps via the sigprocmask or whatever). I probably won't be digging into i

Re: Bash spews bracketed-paste escape sequences when handling signal.

Date:Wed, 18 Dec 2024 13:56:48 -0800 From:Kaz Kylheku Message-ID: | The $$ parameter is expanded to a decimal numeric word | *before* the while command is executed, No it isn't. | so the background process is referencing the correct PID of the parent. But th

Re: Bash spews bracketed-paste escape sequences when handling signal.

were my wrong assumptations .. sry .. peace .. On Wed, Dec 18, 2024, 10:57 PM Kaz Kylheku wrote: > On 2024-12-18 13:46, microsuxxor wrote: > > try > > > > p=$$ ; while sleep 1 ; do kill -USR1 "$p" ; done & > > That's not necessary; my existing repro steps successfully show > a difference between

Re: Bash spews bracketed-paste escape sequences when handling signal.

On 2024-12-18 13:46, microsuxxor wrote: > try > > p=$$ ; while sleep 1 ; do kill -USR1 "$p" ; done & That's not necessary; my existing repro steps successfully show a difference between two signals, that being the only difference between them. The $$ parameter is expanded to a decimal numeric

Re: Bash spews bracketed-paste escape sequences when handling signal.

On Wed, Dec 18, 2024, 10:40 PM Kaz Kylheku wrote: > On 2024-12-18 12:48, Chet Ramey wrote: > > On 12/18/24 1:27 PM, Kaz Kylheku wrote: > > > >> What remains is the question why I somehow cannot get my > >> stuff to work with a different signal like SIGUSR1 or SIGVTALRM. > >> > >> Bash will not ta

Re: Bash spews bracketed-paste escape sequences when handling signal.

On 2024-12-18 12:48, Chet Ramey wrote: > On 12/18/24 1:27 PM, Kaz Kylheku wrote: > >> What remains is the question why I somehow cannot get my >> stuff to work with a different signal like SIGUSR1 or SIGVTALRM. >> >> Bash will not take them while it's sitting in the call to readline. > > Somethin

Re: Bash spews bracketed-paste escape sequences when handling signal.

On 12/18/24 1:27 PM, Kaz Kylheku wrote: What remains is the question why I somehow cannot get my stuff to work with a different signal like SIGUSR1 or SIGVTALRM. Bash will not take them while it's sitting in the call to readline. Something is indeed messed up in your execution environment. L

Re: Bash spews bracketed-paste escape sequences when handling signal.

i made smth with reserved line for some chat .. On Wed, Dec 18, 2024, 8:18 PM Kaz Kylheku wrote: > On 2024-12-18 11:02, microsuxxor wrote: > > post ur code for review , if u want .. > > It's BSD-licensed freeware: https://www.kylheku.com/cgit/basta/about/ >

Re: Bash spews bracketed-paste escape sequences when handling signal.

On 2024-12-18 11:02, microsuxxor wrote: > post ur code for review , if u want .. It's BSD-licensed freeware: https://www.kylheku.com/cgit/basta/about/

Re: Bash spews bracketed-paste escape sequences when handling signal.

post ur code for review , if u want .. On Wed, Dec 18, 2024, 7:28 PM Kaz Kylheku wrote: > On 2024-12-18 06:58, Chet Ramey wrote: > >> With signals other than SIGALRM, the code has to be careful; if it > >> ever happens that the signal is delivered without the trap being > >> in place, Bash will

Re: Bash spews bracketed-paste escape sequences when handling signal.

On 2024-12-18 06:58, Chet Ramey wrote: >> With signals other than SIGALRM, the code has to be careful; if it >> ever happens that the signal is delivered without the trap being >> in place, Bash will die. > > Same with SIGALRM, too. OK, that is my mistake. These steps do terminate Bash: trap -

Re: Bash spews bracketed-paste escape sequences when handling signal.

On 12/15/24 2:16 AM, Kaz Kylheku wrote: If you do not have "trap : ALRM" then this doesn't happen. Because SIGALRM is a terminating signal that kills the shell. But no; I mean the shell keeps running in that case. Try it: $ kill -ALRM $$ $ # didn't die Then something about the execu

Re: Bash spews bracketed-paste escape sequences when handling signal.

On 2024-12-14 23:16, Kaz Kylheku wrote: > The right fix may be to stay away from SIGALRM, since readline > clearly uses it for something. Nope! It turns out that by dumb luck, I had picked the winning signal. The hack used in Basta will not work with signals other than SIGALRM. (No, not even ones

Re: Bash spews bracketed-paste escape sequences when handling signal.

On 2024-12-14 11:36, Chet Ramey wrote: > On 12/14/24 12:40 PM, Kaz Kylheku wrote: >> Hi! >> >> I first ran into this issue on MacOS using the Homebrew build of Bash 5 >> (BASH_VERSION "5.2.37(1)-release"). >> >> When a trap is installed for a signal, and delivered, Bash sends characters >> to the

Re: Bash spews bracketed-paste escape sequences when handling signal.

On 12/14/24 12:40 PM, Kaz Kylheku wrote: Hi! I first ran into this issue on MacOS using the Homebrew build of Bash 5 (BASH_VERSION "5.2.37(1)-release"). When a trap is installed for a signal, and delivered, Bash sends characters to the terminal which move the cursor. It does not; readline d

Re: bash doesn't build with gcc 14.x

On Sat, Dec 7, 2024 at 7:50 PM Chet Ramey wrote: > Since you're building in a docker container, or, more specifically, > without ncurses or any kind of termcap/termlib support, it might be > better to run > > ./configure --disable-readline > > The ancient termcap library in lib/termcap is

Re: bash doesn't build with gcc 14.x

On 12/6/24 10:24 PM, Yuri Kanivetsky wrote: Meanwhile the workaround is: ./configure CFLAGS=-Wno-implicit-function-declaration && make Since you're building in a docker container, or, more specifically, without ncurses or any kind of termcap/termlib support, it might be better to run

Re: bash doesn't build with gcc 14.x

On 12/6/24 7:50 PM, Yuri Kanivetsky wrote: gcc 14.1.0 turned -Wimplicit-function-declaration into an error: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=55e94561e97ed0bce4774aa1c6b5d5d82209a379 Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

Re: bash doesn't build with gcc 14.x

Meanwhile the workaround is: ./configure CFLAGS=-Wno-implicit-function-declaration && make

Re: Bash 5.2: broken built-in printf for float numbers

On 11/7/24 4:16 AM, Thomas Dreibholz wrote: Hi, Bash 5.2 has a broken built-in printf for float numbers. https://lists.gnu.org/archive/html/bug-bash/2024-09/msg00094.html -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates C

Re: Bash 5.2: broken built-in printf for float numbers

On Thu, Nov 07, 2024 at 10:16:46 +0100, Thomas Dreibholz wrote: > Hi, > > Bash 5.2 has a broken built-in printf for float numbers. > > Example: printf "%5.1f" 1024 should print "1024.0" (with standard locale > LC_ALL=C.UTF-8) > > Testing the Bash shell in different versions of recent Debian and

Re: bash -xv issue with stderr

A big thank you to all of you who contributed to the speedy solution of this issue.I am still amazed at the speed of some of the responses - something that could serve as a role model for most commercial support organisations that I know of. It's that source of community spirit that got me invo

Re: bash -xv issue with stderr

On 11/4/24 10:15 AM, Christoph Zimmermann wrote: Thanks for pointing me in the right direction. When checking the info and man (bash.1) files on the devel branch of this repo, I can't find the reference you and other people pointed out wrt to the clarification I referred to earlier. http://gi

Re: bash -xv issue with stderr

Thanks for pointing me in the right direction. When checking the info and man (bash.1) files on the devel branch of this repo, I can't find the reference you and other people pointed out wrt to the clarification I referred to earlier. Perhaps you could point me in the right direction as apparen

Re: bash -xv issue with stderr

On 11/4/24 3:20 AM, Christoph Zimmermann wrote: Hi Chat, As I can't seem to find this: You are referring to the 'devel' branch at https://github.com/bminor/bash (files doc/bash.info and doc/bash.1)? What is that? I am referring to the bash git repository at http://git.savannah.gnu.org/cgit/

Re: bash -xv issue with stderr

On Mon, Nov 4, 2024 at 3:21 AM Christoph Zimmermann wrote: > > As I can't seem to find this: https://git.savannah.gnu.org/git/bash.git

Re: bash -xv issue with stderr

i doubt its 'bminor' he talks about bash git on savannah .. i think .. On Mon, Nov 4, 2024, 09:21 Christoph Zimmermann wrote: > Hi Chat, > > As I can't seem to find this: You are referring to the 'devel' branch at > https://github.com/bminor/bash (files doc/bash.info and doc/bash.1)? > >

Re: bash -xv issue with stderr

Hi Chat, As I can't seem to find this: You are referring to the 'devel' branch at https://github.com/bminor/bash (files doc/bash.info and doc/bash.1)? Cheers, Chris On 03.11.24 21:00, Chet Ramey wrote: On 11/3/24 5:28 AM, Christoph Zimmermann wrote: Thanks for all the quick reactions

Re: bash -xv issue with stderr

On 11/3/24 5:28 AM, Christoph Zimmermann wrote: Thanks for all the quick reactions on that issue (including microsuxx's suggestion which unfortunately does require a CB change). If this is intended behaviour, it should be clearly documented on the corresponding man page (which doesn't seem to

Re: bash -xv issue with stderr

On Sun, Nov 03, 2024 at 11:28:24 +0100, Christoph Zimmermann wrote: > Thanks for all the quick reactions on that issue (including microsuxx's > suggestion which unfortunately does require a CB change). > > If this is intended behaviour, it should be clearly documented on the > corresponding man pa

Re: bash -xv issue with stderr

u can just try the BASH_XTRACEFD=3 line w/o else ... and where u need set -xv output u capture the fd 3 or u can set -xv to 2 but apps to stderr use 3 On Sun, Nov 3, 2024, 13:45 Christoph Zimmermann wrote: > Thanks for all the quick reactions on that issue (including microsuxx's > suggestion whi

Re: bash -xv issue with stderr

Thanks for all the quick reactions on that issue (including microsuxx's suggestion which unfortunately does require a CB change). If this is intended behaviour, it should be clearly documented on the corresponding man page (which doesn't seem to be case ATM). On 02.11.24 19:57, Chet Ramey wro

Re: bash -xv issue with stderr

i think .. BASH_XTRACEFD=3 .. alone may also do .. u try .. On Sat, Nov 2, 2024, 20:55 #!microsuxx wrote: > exec 3<&2 > BASH_XTRACEFD=3 > set -x > { > echo foo >&2 > } 2>&- > > replace &- with file to out log the echo > > On Sat, Nov 2, 2024, 20:37 wrote: > >> Configuration Information [Autom

Re: bash -xv issue with stderr

exec 3<&2 BASH_XTRACEFD=3 set -x { echo foo >&2 } 2>&- replace &- with file to out log the echo On Sat, Nov 2, 2024, 20:37 wrote: > Configuration Information [Automatically generated, do not change]: > Machine: aarch64 > OS: darwin24.0.0 > Compiler: clang > Compilation CFLAGS: -DSSH_SOURCE_BASH

Re: bash -xv issue with stderr

On 11/2/24 1:41 PM, monochro...@linuxinlaws.eu wrote: Bash Version: 5.2 Patch Level: 37 Release Status: release Description: Redirecting stderr to file causes output of bash -xv to be writte to file as well That's where the shell writes -v and -x output. -- ``The lyf so short, the

Re: bash -xv issue with stderr

~ $ bash mb.test.3stderr + echo foo exec 3<&2 BASH_XTRACEFD=3 set -x { echo foo >&2 } 2>&- On Sat, Nov 2, 2024, 19:25 wrote: > Configuration Information [Automatically generated, do not change]: > Machine: aarch64 > OS: darwin24.0.0 > Compiler: clang > Compilation CFLAGS: -DSSH_SOURCE_BASHRC >

Re: Bash test builtin fails on: test -n '>' -a 1 -eq 1

On 10/22/24 3:34 AM, cirrus.mazurka...@icloud.com wrote: The following produces a `bash: test: too many arguments` exception in `test`, with exit status 2: ``` bash v='>' test -n "$v" -a yes '!=' no # bash: test: too many arguments echo $? # 2 test -n '>' -a 1 -eq 1 # bash: test: too many argu

Re: Bash test builtin fails on: test -n '>' -a 1 -eq 1

On Tue, Oct 22, 2024 at 03:34:43PM +0800, cirrus.mazurka...@icloud.com wrote: > The following produces a `bash: test: too many arguments` exception in > `test`, with exit status 2: > > ``` bash > v='>' > test -n "$v" -a yes '!=' no # bash: test: too many arguments > echo $? # 2 > > test -n '>' -

Re: Bash debugging.

On 10/5/24 4:14 PM, David Shuman wrote: I have been working on several items as I am using bash to configure systems. I started wanting to log the output of my scripts. Then I added a prefixed message construct so detailed logs could be summarized without extraneous debugging information (I hav

Re: bash builtins mapfile issue - Unexpected parameter passing of causes rce

On 9/14/24 7:46 AM, ~ via Bug reports for the GNU Bourne Again SHell wrote: Dear bug-bash team:   I hope this email finds you well. During my recent security assessment of bash, I identified a potential security vulnerability that I believe may impact the security of your product and its users.

Re: bash builtins mapfile issue - Unexpected parameter passing of causes rce

You seem to be implying that execstr contains a value that's under the control of the input stream in a way that would allow malicious data on the input stream to cause the shell to invoke arbitrary code. I read the run_callback() function, and I don't see that as plausible, unless you claiming th

Re: bash builtins mapfile issue - Unexpected parameter passing of causes rce

On Sat, Sep 14, 2024 at 19:46:21 +0800, ~ via Bug reports for the GNU Bourne Again SHell wrote: > Dear bug-bash team: >   I hope this email finds you well. During my recent security > assessment of bash, I identified a potential security vulnerability that I > believe may impact the security of

Re: bash passes changed termios to backgrounded process(es) groups?

Chet Ramey wrote in : |On 8/29/24 2:17 PM, Robert Elz wrote: |> Date:Thu, 29 Aug 2024 10:40:25 -0400 |> From:Chet Ramey |> Message-ID: |> |>| It's not a big problem. You're in the background if your process \ |>| group is |>| not equal to the terminal's p

Re: bash - reproducible SEGFAULT on rapid SIGINTs

On 8/30/24 5:05 AM, Eduardo A. Bustamante López wrote: On Wed, Aug 28, 2024 at 01:16:57PM +0200, Tycho Kirchner wrote: Hi, Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the bash instance receiving them. Steps to reproduce: * Open up a shell SHELL_1 and record its pid

Re: bash - reproducible SEGFAULT on rapid SIGINTs

On 8/28/24 7:16 AM, Tycho Kirchner wrote: Hi, Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the bash instance receiving them. Steps to reproduce: * Open up a shell SHELL_1 and record its pid, e.g. "echo $$" * Launch another shell and send rapid SIGINTs: while true ;

Re: bash - reproducible SEGFAULT on rapid SIGINTs

On 8/28/24 7:16 AM, Tycho Kirchner wrote: Hi, Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the bash instance receiving them. Steps to reproduce: * Open up a shell SHELL_1 and record its pid, e.g. "echo $$" * Launch another shell and send rapid SIGINTs: while true ;

Re: bash passes changed termios to backgrounded process(es) groups?

On 8/29/24 4:59 PM, Martin D Kealey wrote: On Fri, 30 Aug 2024 at 04:17, Robert Elz > wrote: SIGTTOU is also sent, unconditionally, by any attempt to change any of the terminal's attributes, and the process (group) (by default) stops. (I don't recall off

Re: bash passes changed termios to backgrounded process(es) groups?

On 8/29/24 2:17 PM, Robert Elz wrote: Date:Thu, 29 Aug 2024 10:40:25 -0400 From:Chet Ramey Message-ID: | It's not a big problem. You're in the background if your process group is | not equal to the terminal's process group. That's more or less sufficient

Re: bash - reproducible SEGFAULT on rapid SIGINTs

On Wed, Aug 28, 2024 at 01:16:57PM +0200, Tycho Kirchner wrote: > Hi, > Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the > bash instance receiving them. Steps to reproduce: > * Open up a shell SHELL_1 and record its pid, e.g. "echo $$" > * Launch another shell and send

Re: bash passes changed termios to backgrounded process(es) groups?

Robert Elz wrote in <23591.1724975...@jacaranda.noi.kre.to>: |Date:Fri, 30 Aug 2024 00:39:40 +0200 |From:Steffen Nurpmeso |Message-ID: <20240829223940.CDUfy6-w@steffen%sdaoden.eu> | || On Linux it seems not even to cause TTOU if you set || attributes which are e

Re: bash passes changed termios to backgrounded process(es) groups?

Date:Fri, 30 Aug 2024 00:39:40 +0200 From:Steffen Nurpmeso Message-ID: <20240829223940.CDUfy6-w@steffen%sdaoden.eu> | On Linux it seems not even to cause TTOU if you set | attributes which are effectively identical to what is already | active Yes, my wording wa

Re: bash passes changed termios to backgrounded process(es) groups?

Martin D Kealey wrote in : |On Fri, 30 Aug 2024 at 04:17, Robert Elz wrote: |> SIGTTOU is also sent, unconditionally, by any attempt to change any of |> the terminal's attributes, and the process (group) (by default) stops. |> (I don't recall off hand whether simply fetching the attributes is

Re: bash passes changed termios to backgrounded process(es) groups?

Chet Ramey wrote in : |On 8/28/24 4:12 PM, Steffen Nurpmeso wrote: |> Chet Ramey wrote in |> <3ca901aa-5c5e-4be3-9a71-157d7101f...@case.edu>: |>|On 8/27/24 7:46 PM, Steffen Nurpmeso wrote: |>|> I got a bug report for my mailer which stated |>|> |>|> $ ( echo blah | Mail root ) & |>|>

Re: bash passes changed termios to backgrounded process(es) groups?

Robert Elz wrote in <25564.1724955...@jacaranda.noi.kre.to>: |Date:Thu, 29 Aug 2024 10:40:25 -0400 |From:Chet Ramey |Message-ID: | || It's not a big problem. You're in the background if your process group is || not equal to the terminal's process group. | |Th

  1   2   3   4   5   6   7   8   9   10   >