static build fails with 5.3 rc2
This change --- ../bash-5.3~rc1/lib/readline/terminal.c 2025-01-24 16:45:27.0 +0100 +++ lib/readline/terminal.c 2025-05-16 14:51:07.0 +0200 @@ -102,12 +102,20 @@ static int tcap_initialized; -#if !defined (__linux__) && !defined (NCURSES_VERSION) -# if defined (__EMX__) || defined (NEED_EXTERN_PC) +/* Systems for which PC/BC/UP are defined in the curses library and need an + extern definition here. */ +#if !defined (__linux__) && !defined (__gnu_hurd__) && !defined (NCURSES_VERSION) +# define NEED_EXTERN_PC +#endif /* !__linux__ && !__gnu_hurd__ && !NCURSES_VERSION */ + +#if defined (__EMX__) +# define NEED_EXTERN_PC +#endif + +#if defined (NEED_EXTERN_PC) extern -# endif /* __EMX__ || NEED_EXTERN_PC */ +# endif /* NEED_EXTERN_PC */ char PC, *BC, *UP; -#endif /* !__linux__ && !NCURSES_VERSION */ /* Some strings to control terminal actions. These are output by tputs (). */ char *_rl_term_clreol; breaks a static bash build: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libtinfo.a(lib_termcap.o):(.bss+0 x8): multiple definition of `UP'; ./lib/readline/libreadline.a(terminal.o):/usr/include/termcap.h:56: fir st defined here /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libtinfo.a(lib_termcap.o):(.bss+0 x0): multiple definition of `BC'; ./lib/readline/libreadline.a(terminal.o):/usr/include/termcap.h:57: fir st defined here /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libtinfo.a(lib_tputs.o):(.bss+0x6 ): multiple definition of `PC'; ./lib/readline/libreadline.a(terminal.o):/usr/include/termcap.h:55: first defined here
Re: exec3.sub never finishes with huge argmax
On 6/7/25 4:42 PM, Joel Ebel via Bug reports for the GNU Bourne Again SHell wrote: I appreciate the effort to make the test run more efficiently and faster, and that's probably a good idea, but I think there still needs to be a way out. I didn't express just how huge our ARG_MAX is. It's 2^62 or 4.6 exabytes. I don't think there's any way to reasonably expect that this test will complete with that environment, so I still need a way of skipping the test. So `getconf ARG_MAX' returns 4611686018427387904? I can do something with that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: 5.3: Why is <(cmd) allowed in func names of func defs?
Date:Wed, 11 Jun 2025 10:07:37 -0400 From:Chet Ramey Message-ID: <7ef0aaf1-e56e-433e-9d29-4ad232871...@case.edu> | That's the function name. In general, a function name is a WORD that | does not undergo any word expansions, not even quote removal. Not doing expansions I understand, though there's no general reason they shouldn't be done there, but quote removal I'd suggest is essential, otherwise there's no way to get white space into the function name, without also embedding quoting characters in it. Of all the chars that one might want to allow in function names, I'd put white space near the top, and quoting chars down near the bottom (though of course, quoted quotes would work, just as they do in command invocation). So, I'd strongly suggest doing (at least) quote removal on the word which is to be the function name, so it matches the syntax for command invocation -- other than other expansions, which is why the NetBSD sh currently also prohibits unquoted or double quoted $ and ` in function names - as at invocation time they'd be expanded, but at definition time they aren't - at least currently). kre
Re: 5.3: Why is <(cmd) allowed in func names of func defs?
On 6/3/25 11:57 AM, Koichi Murase wrote:
xx. <( and >( can now be used in function names.
What is the background of this change? This was added in commit
315095ad, and to the best of my knowledge, an email on the mailing
list in the same period and related to this change would be Ref. [1]
from kre.
I wrote:
"There's no good reason to reduce the possible function namespace below
what's allowed for external commands."
[1] https://lists.gnu.org/archive/html/bug-bash/2023-02/msg7.html
There is a very good reason to allow function names to contain almost
any character at all. [...]
However, the interpretation of the bare `<(' and `>(' in Bash 5.3
seems to contradict the design discussed in Ref. [1].
Because it was kre's message and suggestion.
Bash 5.3
interprets the bare <( and >( as an introducer of process
substitutions, and the defined function has the source code of the
parsed process substitution.
$ bash-devel -c '<(echo hello) () { echo hello; }; declare -F'
declare -f <(echo hello)
That's the function name. In general, a function name is a WORD that
does not undergo any word expansions, not even quote removal. Previous
versions of bash used to audit function names for prohibited characters;
bash-5.3 reduces the number of prohibited characters.
However, Ref. [1] discusses the function definition of the form like «
'<()' () { ...; } » (instead of « <() () { ...; } » which was
Implemented in Bash 5.3):
OK.
Note that no expansions are specified to happen on the function name
in a function definition, so $var() isn't ever going to create a function
named by the value of var - you need eval for that. Because of that
the NetBSD shell requires any function definition which contains something
that looks like a var/command/arith expansion to be quoted such as to make
it clear the user knows that isn't going to happen - we'd reject the $var()
case, but allow '$var'() or \$var() (but not "$var"() - "\$var"() works
however.)
Bash doesn't perform quote removal on function names.
In Bash 5.3, the defined function name isn't even the literal process
substitution, but a somewhat prettified version (which is non-trivial
to predict):
$ bash-devel -c $'<(\n # ignored\necho hello\n) () { echo
hello; }; declare -F'
declare -f <(echo hello)
The idea is that you parse a word as a potential process substitution,
which requires calling the parser to determine whether or not it's valid
and where the closing paren appears. At that point, you don't know
whether or not it's going to be used as a function name. Process
substitutions and command substitutions are reconstituted as an equivalent
text version of the parsed command, which in this case leaks through to
the word that's used as the function name.
What would be the use case of this feature, and what is the rationale
for this design?
The rationale is to expand the function namespace closer to that of
commands. There isn't anything forcing you to use them.
The current behavior doesn't seem to make sense to me. If it was
implemented after Ref. [1], « '<(echo hello)' () { echo hello; } »
should have been supported but not « <(echo hello) () { echo hello;
}.».
But that would have required bash to perform quote removal on function
names, and I wasn't going to go that far.
Ref. [1] argued that "$" expansions should not happen in the function
name in the function definition, but in my opinion, there is room to
optionally support expansions in the function names of function
definitions (such as « "$namespace::func"() { ...; } » as I suggested
a few times on the mailing list in the past).
OK, but that's not what we're doing here, and I wasn't willing to go
that far for bash-5.3.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: 5.3: Why is <(cmd) allowed in func names of func defs?
On 6/3/25 4:35 PM, Robert Elz wrote: A function name should remain a shell "word" - including being possibly partly or fully a quoted word, after all, if it contains operator chars, white space, or quoting chars, then it will need to be quoted to be invoked, it seems eminently sensible to require such a thing to be quoted when defined as well. That wouldn't have been backwards compatible, so I didn't add quote removal. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Building bash 5.3, rc2, warning about mktemp()
On 6/10/25 11:29 AM, Oğuz wrote: On Tuesday, June 10, 2025, Stan Marsh wrote: This is not an answer. This is just someone blowing off steam. This came up a few times and the answer is always along the lines of "it works fine, ignore the warning". Here's a link to a recent discussion about it: https://lists.gnu.org/archive/html/bug-bash/2021-01/msg00112.html It's still a well-meaning but spurious warning. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Building bash 5.3, rc2, warning about mktemp()
On 6/10/25 6:54 PM, Robert Elz wrote: ps: in general, usually, mktemp() isn't the best interface to use, there are race conditions, but whether that matters depends upon just what it is being used for, Sometimes you need to generate a name for a file system object that isn't a regular file (or, if you have mkdtemp, a directory). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [ PATCH ] NEWS: Make it clear that fltexpr is a *loadable* builtin
On 6/10/25 1:37 AM, Duncan Roe wrote: Hi NEWS announces the new fltexpr builtin but doesn't mention you have to enable it. Reasonable. BTW, fltexpr is so much closer to let than to expr, wouldn't it be better called letflt? (Not fltlet - that sounds like a baby flt :) There was a contributed builtin named `flet' (it's probably still available on github) that I didn't use any of, so I wanted to stay away from similar names. You can define a `letflt' alias, of course. I don't like that name at all. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: static build fails with 5.3 rc2
On 6/11/25 5:41 AM, Matthias Klose wrote: This change I'll revert that change, I think, or at least do it a different way that addresses the original report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: 5.3: Why is <(cmd) allowed in func names of func defs?
On Jun 11 2025, Chet Ramey wrote:
>> Bash 5.3
>> interprets the bare <( and >( as an introducer of process
>> substitutions, and the defined function has the source code of the
>> parsed process substitution.
>>$ bash-devel -c '<(echo hello) () { echo hello; }; declare -F'
>>declare -f <(echo hello)
>
> That's the function name. In general, a function name is a WORD that
> does not undergo any word expansions, not even quote removal.
Without quote removal, a lot of WORDs that can be command names (which
undergo quote removal) cannot be used as function names.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: Meta: `help cut` doesn't document what -a does
On 6/6/25 11:43 PM, Duncan Roe wrote: On Fri, Jun 06, 2025 at 10:27:56AM -0400, Chet Ramey wrote: They're always built and installed when you use `make install'. The problem, of course, is users (some) or distros (all) who don't use a ^^^ Slackware does simple `make install', but rather some other installation or packaging mechanism. Wouldn't it be a lot easier for everyone if `make` compiled the supported examples instead of `make install` doing it? There has always been `make loadables' if you want to play around with the examples. Not everyone does. The business of installing the loadables and headers on `make install' came later as the result of feature requests. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: 5.3: Why is <(cmd) allowed in func names of func defs?
2025年6月11日(水) 23:07 Chet Ramey :
> On 6/3/25 11:57 AM, Koichi Murase wrote:
> >> xx. <( and >( can now be used in function names.
> >
> > What is the background of this change? This was added in commit
> > 315095ad, and to the best of my knowledge, an email on the mailing
> > list in the same period and related to this change would be Ref. [1]
> > from kre.
>
> I wrote:
>
> "There's no good reason to reduce the possible function namespace below
> what's allowed for external commands."
Yes, I understood the background for extending the function namespace,
but what I didn't understand was the background for the specific
behavior of <() and >() inside the name of the function definition in
5.3-rc2 and devel.
> > [1] https://lists.gnu.org/archive/html/bug-bash/2023-02/msg7.html
> >
> >> There is a very good reason to allow function names to contain almost
> >> any character at all. [...]
> >
> > However, the interpretation of the bare `<(' and `>(' in Bash 5.3
> > seems to contradict the design discussed in Ref. [1].
>
> Because it was kre's message and suggestion.
So, it's intentionally different from what was suggested, but the
decision and the reasoning behind it hadn't been explained in a reply
to the thread, so further discussions about the implemented design
were exempted at that time. Then, we are discussing it now.
> >$ bash-devel -c '<(echo hello) () { echo hello; }; declare -F'
> >declare -f <(echo hello)
>
> That's the function name. In general, a function name is a WORD that
> does not undergo any word expansions, not even quote removal.
Here, I assume you talk about the existing implementations of Bash by
the term "in general" (because it does undergo quote removal in other
shells in which « ' » is allowed in the function name, and also
because you mentioned below that you wouldn't go so far as «
"$namespace::func"() { ...; } » in Bash 5.3).
> Previous
> versions of bash used to audit function names for prohibited characters;
> bash-5.3 reduces the number of prohibited characters.
In my understanding, the cases in which the quote removal would change
the value of the WORD have been excluded by the auditing. In that
sense, even though it is how Bash implemented the function definition,
there wasn't any way to observe that the WORD did not undergo the
quote removal. This means that it hasn't been a part of the language
effectively.
> >> Note that no expansions are specified to happen on the function name
> >> in a function definition, so $var() isn't ever going to create a function
> >> named by the value of var - you need eval for that. Because of that
> >> the NetBSD shell requires any function definition which contains something
> >> that looks like a var/command/arith expansion to be quoted such as to make
> >> it clear the user knows that isn't going to happen - we'd reject the $var()
> >> case, but allow '$var'() or \$var() (but not "$var"() - "\$var"() works
> >> however.)
>
> Bash doesn't perform quote removal on function names.
Regardless of the current Bash behavior, what I want to request is to
perform quote removal as other shells do. It is also the least
astonishing behavior. To me, the current behavior that e.g. « 'a b c'
() { ...; } » creates a function named «'a b c'» (which needs to be
called by « "'a b c'" » or « \'a\ b\ c\' ») is definitely surprising. It
must be natural to create a function named «a b» (which can be called
by « 'a b c' » or « a\ b\ c »).
> The idea is that you parse a word as a potential process substitution,
> which requires calling the parser to determine whether or not it's valid
> and where the closing paren appears. At that point, you don't know
> whether or not it's going to be used as a function name. Process
> substitutions and command substitutions are reconstituted as an equivalent
> text version of the parsed command, which in this case leaks through to
> the word that's used as the function name.
I think it can be parsed as a process substitution, but on the
evaluation stage of the function definition, it should emit an error.
> > What would be the use case of this feature, and what is the rationale
> > for this design?
>
> The rationale is to expand the function namespace closer to that of
> commands.
OK, that is the rationale for the feature. How about the rationale for
the design that WORD doesn't undergo quote removal? I think there
isn't a reason that we need to support extended function namespace in
the current specific way in the devel branch and 5.3-rc2. Rather, with
quote removal, the function namespace becomes the same as that for the
commands.
> There isn't anything forcing you to use them.
Users are not forced to use them, but at the same time, users are
allowed to use them once it is released in Bash 5.3. Then, I'll be
forced to handle these in my framework.
> > The current behavior doesn't seem to make sense to me. If it was
> > implemented after Ref. [1], « '<(echo hello)' () { echo hello; } »
> > should ha
Re: static build fails with 5.3 rc2
On Wed, Jun 11, 2025 at 11:41:30 +0200, Matthias Klose wrote: > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libtinfo.a(lib_termcap.o):(.bss+0 > x8): multiple definition of `UP'; > ./lib/readline/libreadline.a(terminal.o):/usr/include/termcap.h:56: fir > st defined here > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libtinfo.a(lib_termcap.o):(.bss+0 > x0): multiple definition of `BC'; > ./lib/readline/libreadline.a(terminal.o):/usr/include/termcap.h:57: fir > st defined here > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/14/../../../x86_64-linux-gnu/libtinfo.a(lib_tputs.o):(.bss+0x6 > ): multiple definition of `PC'; > ./lib/readline/libreadline.a(terminal.o):/usr/include/termcap.h:55: first > defined here I believe this is the same problem as seen in this thread: https://lists.gnu.org/archive/html/bug-bash/2025-06/msg00017.html
Re: static build fails with 5.3 rc2
On 11.06.25 17:14, Chet Ramey wrote: On 6/11/25 5:41 AM, Matthias Klose wrote: This change I'll revert that change, I think, or at least do it a different way that addresses the original report. thank you. so maybe that should be a proper autoconf check to see if these are defined in some other library like libncurses or libtinfo
Re: 5.3: Why is <(cmd) allowed in func names of func defs?
2025年6月11日(水) 23:10 Chet Ramey :
> On 6/3/25 4:35 PM, Robert Elz wrote:
> > A function name should remain a shell "word" - including being possibly
> > partly or fully a quoted word, after all, if it contains operator chars,
> > white space, or quoting chars, then it will need to be quoted to be
> > invoked, it seems eminently sensible to require such a thing to be
> > quoted when defined as well.
>
> That wouldn't have been backwards compatible, so I didn't add quote
> removal.
Are there actual cases where the quote removal would change the
behavior of existing scripts that worked in Bash <= 5.2? In my
understanding, in Bash <= 5.2, any function names that could be
affected by quote removal haven't been allowed, so there shouldn't be
compatibility issues caused by turning on the quote removal.
$ bash-5.2 --norc
$ a\b\c() { echo yes; }
bash-5.2: `a\b\c': not a valid identifier
$ 'abc'() { echo yes; }
bash-5.2: `'abc'': not a valid identifier
$ "abc"() { echo yes; }
bash-5.2: `"abc"': not a valid identifier
--
Koichi
