Re: bash-5.3.tar.gz ships with outdated .gmo files

On 7/31/25 12:25 PM, Ross Burton wrote: I will republish the tar files. In the future, could you create a new point release instead of regenerating the tarball? Most distros checksum the tarballs for security purposes, and silently swapping the tarball looks a lot like a supply-chain attack.

Re: bash-5.3.tar.gz ships with outdated .gmo files

>I will republish the tar files. In the future, could you create a new point release instead of regenerating the tarball? Most distros checksum the tarballs for security purposes, and silently swapping the tarball looks a lot like a supply-chain attack. Ross IMPORTANT NOTICE: The contents of t

Re: bash-5.3.tar.gz ships with outdated .gmo files

On 7/30/25 4:32 AM, Christian Weisgerber wrote: Chet Ramey: This means the build now requires the msgfmt(1) tool from the gettext package to regenerate those .gmo files. No, if the configure process doesn't find msgfmt, it sets $MSGFMT (which the Makefile uses) to `:'. I'll have to see what e

Re: bash-5.3.tar.gz ships with outdated .gmo files

Chet Ramey: > > This means the build now > > requires the msgfmt(1) tool from the gettext package to regenerate > > those .gmo files. > > No, if the configure process doesn't find msgfmt, it sets $MSGFMT (which > the Makefile uses) to `:'. I'll have to see what effects that has on the > build pro

Re: bash-5.3.tar.gz ships with outdated .gmo files

On 7/28/25 5:36 PM, Christian Weisgerber wrote: The bash-5.3.tar.gz release tarball ships with a number of outdated .gmo message catalog files, i.e., at least their mtimes are older than those of the corresponding .po files. Yes, though the content has not changed. This means the build now r

Re: Bash 5.3-devel getopts reads 1 byte past the end of a buffer when called twice

On 7/17/25 12:52 AM, Nathan Mills wrote: Bash Version: 5.3-devel Patch Level: 0 Release Status: devel-a23c863e Clang: ``` clang version 19.1.7 Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /nix/store/x6rsdc4s0f1j9bn1cx2h1l5fj8765ykw-clang-19.1.7/bin ``` NixOS: ``` nixos-ve

Re: bash 5.3, rc2, "make install" does not populate the share/man/man1 directory

On 6/14/25 5:17 AM, Stan Marsh wrote: 1) Why is the error ignored, making it almost impossible to determine that something went wrong? Because it shouldn't be a fatal error in a pre-release version, where we're mostly interested in bash bugs. 2) Shouldn't the problem (that

Re: bash 5.3, rc2, "make install" does not populate the share/man/man1 directory

On 6/14/25 3:07 AM, Stan Marsh wrote: I found the problem (I think). See below: touch bashref.dvi builtins.pdf bashref.pdf bashref.html bash.pdf bashref.info bash.info builtins.0 rbash.0 So, how to fix this? See above. Note: I think I have done this successfully in the past (with ba

Re: bash 5.3, rc2, "make install" does not populate the share/man/man1 directory

On Sat, Jun 14, 2025 at 03:17:09 -0600, Stan Marsh wrote: > (Followup to my previous post) > > To answer my own question, I guess it is pretty obvious that the answer to > "How to > fix?" is "Install texinfo and re-run the make install", but it raises two > important > questions: > 1) Why is

Re: bash 5.3, rc2, "make install" does not populate the share/man/man1 directory

(Followup to my previous post) To answer my own question, I guess it is pretty obvious that the answer to "How to fix?" is "Install texinfo and re-run the make install", but it raises two important questions: 1) Why is the error ignored, making it almost impossible to determine that

Re: bash 5.3, rc2, "make install" does not populate the share/man/man1 directory

I found the problem (I think). See below: --- Cut Here --- make[1]: Entering directory '/home/username/Build/bash-5.3-rc2/doc' rm -f bashref.info makeinfo --no-split -I../lib/readline/doc ./bashref.texi make[1]: makeinfo: Command not found Makefile:181: recipe for target 'bashref.info' failed mak

Re: bash 5.3, rc2, "make install" does not populate the share/man/man1 directory

On 6/13/25 11:32 AM, Stan Marsh wrote: I did: ./configure --prefix=$HOME/local/bash5 Then make and then make install (all of this is done as a non-root user). It created the directory listed above and all the necessary subdirs, including share/man/man1, but left that directory empty. I can't r

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

On 6/13/25 10:23 AM, Todd Zullinger wrote: The issue is stated as: let is very similar to (( - the only difference being let is a builtin (simple command), and (( is a compound command. The arguments to let are therefore subject to all the same expansions and substitutions

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

On Fri, Jun 13, 2025 at 08:14:51 -0600, Stan Marsh wrote: > >According to : > > I can't access that URL - get "Bad Gateway" (in at least two different > browsers) Sometimes if there are too many requests all at once, it can get a bit cranky. Wait a

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

On Fri, Jun 13, 2025 at 07:08:21 -0600, Stan Marsh wrote: > BTW, and only tangentially related, "man bash" says that "let" and "(( ))" are > exactly the same, but "shellcheck" thinks otherwise. "shellcheck" says you > should > use "(( ))" and never use "let", but I still (mostly) use "let". And

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

Greg Wooledge wrote: > On Fri, Jun 13, 2025 at 07:08:21 -0600, Stan Marsh wrote: >> BTW, and only tangentially related, "man bash" says that >> "let" and "(( ))" are exactly the same, but "shellcheck" >> thinks otherwise. "shellcheck" says you should use "(( >> ))" and never use "let", but I still

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

On Fri, Jun 13, 2025 at 07:57:54 -0600, Stan Marsh wrote: > Also, note that if you are running with "set -e" (or "trap ... ERR"), then > having > "let" (or "(( ))") return a non-zero exit status when it happens to evaluate > to zero, > could cause an unexpected script abort. This is why I linked

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

>All of this is intentional, and not a bug. It is possible to be both. But, yes, it reflects a fundamental inconsistency in the C/Unix ecosystem. The fact that in most programming languages (e.g., C, AWK), 0 means false and non-zero means true, but in the shell, it is the opposite. E.g., in AWK

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

On Fri, Jun 13, 2025 at 07:08:21 -0600, Stan Marsh wrote: > BTW, and only tangentially related, "man bash" says that "let" and "(( ))" > are exactly > the same, but "shellcheck" thinks otherwise. "shellcheck" says you should > use "(( ))" > and never use "let", but I still (mostly) use "let". T

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

On Fri, Jun 13, 2025 at 12:41:16 +0300, Stamatis Mavrogeorgis wrote: > The shorthands "++", "--", "+=1" and "-=1" in bash arithmetic > erroneously return exit code 1 when a variable is either incremented by > "++" or decremented by "--" from 0 or incremented by "+=1" or decremented > by "-=

Re: [bash arithmetic bugs with "++","--","+=1" and "-=1"]

>Description: >The shorthands "++", "--", "+=1" and "-=1" in bash arithmetic >erroneously return exit code 1 when a variable is either incremented by >"++" or decremented by "--" from 0 or incremented by "+=1" or decremented >by "-=1" from -1 and 1 respectively, although the variable valu

Re: Bash does not complete the filename once the situation becomes singular

On 5/12/25 8:04 PM, Adam Purkrt wrote: GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu) OS: Gentoo Linux Originally met this while the download of iso file in firefox was nearing completion, and I was preparing myself to move the downloaded foobar.iso file elsewhere. I opened terminal

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

  1   2   3   4   5   6   7   8   9   10   >