Re: printf fails in version 5.2.026-3
Apparently the patch needed to fix this was the one Florian Weimer posted in november 2023, in "C compatibility issue in the configure script" <8734oqnlou@gentoo.org> (if you don't have the mail history: https://lists.gnu.org/archive/html/bug-bash/2023-11/msg00104.html) Maybe some compiler change triggered this now. -- Daniel lublin.se
Re: printf fails in version 5.2.026-3
The message ID with the patch in question was of course <87leasmvoo@oldenburg.str.redhat.com> -- Daniel lublin.se
Re: printf fails in version 5.2.026-3
Daniel Lublin writes: > Apparently the patch needed to fix this was the one Florian Weimer > posted in november 2023, in "C compatibility issue in the configure > script" <8734oqnlou@gentoo.org> (if you don't have the mail history: > https://lists.gnu.org/archive/html/bug-bash/2023-11/msg00104.html) > > Maybe some compiler change triggered this now. Yes, GCC 14 makes various things stricter - for the better - and this can affect configure scripts. Arch didn't, as far as I know, do a mass-rebuild when adding GCC 14, which means these issues now only show up when a package gets updated for unrelated reasons. I consider this to not have been the ideal strategy. We did try to advertise what people should do, but you can only shout so much.
Re: [@]@A weird behaviour when IFS does not contain space
Emanuele Torre writes:
> [...]
> Today, I have noticed that if IFS is set to a value that does not
> include space, [@]@A will expand to a single value
> [...]
> As an aside, [*]@A always expands to the declare command joined by
> space, even if the first character of IFS is not space; I think that is
> a bit confusing, and surprising, but maybe that is done intentionally:
> "intended and undocumented"(?).
IMHO, the second observation is what should happen: The construct
"${a[*]@A}", like almost all variable expansions, produces a *character
string*, and then the characters are parsed into words and interpreted.
In this case, the string contains spaces between the characters that are
generated for each array member. But if IFS doesn't contain a space,
then that string of characters isn't split into multiple words.
Although perhaps "${a[*]@A}" should operate like "${a[*]}" does
(according to my very old man page):
If
the word is double-quoted, ${name[*]} expands to a single word with the
value of each array member separated by the first character of the IFS
special variable, [...]
That is, the blocks of the result string should be separated by the
first character of IFS.
The first case is more complicated. The man page says for "${a[@]}":
[...] ${name[@]} expands each element of name to a sepâ
arate word.
This is the one case where the results of a variable expansion can't be
modeled simply as replacing the variable reference with a string of
characters (which are then parsed). It suggests that "${a[@]@A}" should
automagically generate a separate word for each element of the array a,
regardless of the value of IFS.
Dale
Re: waiting for process substitutions
Reading this discussion, I notice a subtlety. If you execute: $ command-A >( command-1) <( command-2 ) $ command-B when command-B executes, command-2 must have terminated already because command-A wouldn't have seen the EOF from command-2 until command-2 terminated. (OK, I am assuming here that command-A did read its second argument until EOF, and that's not guaranteed.) But there's no guarantee that command-1 has terminated; all that command-B can depend on is that EOF was *sent* to command-1. However, the documentation talks of $! possibly being the PID of command-1 etc., but my (old) manual page doesn't describe how $! could be set to be the PID of command-1, or even how a script could determine the PID of command-1 in order to set $! to that number. (Although it does describe that if $! is the PID of command-1, then "wait without id" will wait for $!.) Dale
