Re: here strings fold newlines on MacOS

Ah, yep — sorry for the false positive. I *have* 5.1.0 installed (and bashbug picked that up!) but the context in which I encountered the bug was indeed Apple’s ancient version. I could’ve sworn I tested it in both, but clearly messed that up - verified it’s fixed in 5.1.0.   -Rich On Jan 31

here strings fold newlines on MacOS

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: darwin18.7.0 Compiler: clang Compilation CFLAGS: -DSSH_SOURCE_BASHRC uname output: Darwin flounder.home.mati.ca 18.7.0 Darwin Kernel Version 18.7.0: Tue Nov 10 00:07:31 PST 2020; root:xnu-4903.278.51~1/RELEASE_

incorrect associative array key parsing if they contain closing square bracket

0(2)-release : bash: [version[agent]]=agent.version: bad array subscript according to people in #bash : i get bad array subscript with 4.2 it fails in 4.2.8 -- Rich

Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)

equired_ by POSIX, despite your bogus claims to the > contrary. Okay, thanks for the clarification. I'll drop this complaint and report bugs to any implementations I find where the -- is not accepted. Sorry for wasting your time. Rich

Re: nonconformant behavior for printf(1) (you cannot interpret - as an option char)

On Mon, Nov 26, 2007 at 10:09:11PM -0700, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > According to Rich Felker on 11/26/2007 10:02 PM: > > On Mon, Nov 26, 2007 at 09:54:52PM -0700, Eric Blake wrote: > >> -BEGIN PGP SIGNED M

echo(1) non-conformant (processing -e and -E)

ns for POSIX commands which prevent potentially conformant ones in the host system's path from being used. Either the bash versions should be conformant or they should get out of the way when in standards-conformant mode. Rich

nonconformant behavior for printf(1) (you cannot interpret - as an option char)

rintf (and possibly other) builtins entirely when bash is running in POSIX/sh mode? It's a source of breakage for real valid scripts! Disabling the builtins manually is not an option for sh scripts since the mechanism to disable them is bash-specific. Rich

bash's fallback implementation of vsnprintf(3) is nonconformant and breaks printf(1)

27;ll be needing to replace snprintf anyway, but hopefully doing it with a correct implementation instead of the one that's currently included with bash. Rich

Re: builtin printf behaves incorrectly with "c and 'c character-value arguments

On Mon, Nov 05, 2007 at 10:23:43PM -0500, Chet Ramey wrote: > Rich Felker wrote: > > > I'm not sure what you mean. For a Latin-1 locale there is no > > difference, but if the locale is a different legacy locale, the > > wchar_t value (Unicode scalar value on sy

Re: builtin printf behaves incorrectly with "c and 'c character-value arguments

On Mon, Nov 05, 2007 at 09:10:29AM -0500, Chet Ramey wrote: > Rich Felker wrote: > > $ printf %d\\n \'À > > -61 > > (expected 192) > > > > This should be 192 regardless of locale on any system where wchar_t > > values are ISO-10646/Unicode. Bash is i

builtin printf behaves incorrectly with "c and 'c character-value arguments

te (and perhaps also should be renamed...). Rich