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

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

  1   2   3   4   5   6   7   8   9   10   >