Re: 5.3: Why is <(cmd) allowed in func names of func defs?

2025-06-11 Thread Robert Elz
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 expan

Re: exec3.sub never finishes with huge argmax

2025-06-11 Thread Chet Ramey
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 o

Re: 5.3: Why is <(cmd) allowed in func names of func defs?

2025-06-11 Thread Koichi Murase
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 >

Re: static build fails with 5.3 rc2

2025-06-11 Thread Matthias Klose
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 o

Re: 5.3: Why is <(cmd) allowed in func names of func defs?

2025-06-11 Thread Koichi Murase
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 perio

Re: static build fails with 5.3 rc2

2025-06-11 Thread Chet Ramey
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, UTe

Re: [ PATCH ] NEWS: Make it clear that fltexpr is a *loadable* builtin

2025-06-11 Thread Chet Ramey
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 contribut

Re: Meta: `help cut` doesn't document what -a does

2025-06-11 Thread Chet Ramey
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 ^^^ Slac

Re: 5.3: Why is <(cmd) allowed in func names of func defs?

2025-06-11 Thread Andreas Schwab
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 <(e

Re: 5.3: Why is <(cmd) allowed in func names of func defs?

2025-06-11 Thread 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 requir

Re: 5.3: Why is <(cmd) allowed in func names of func defs?

2025-06-11 Thread 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

Re: Building bash 5.3, rc2, warning about mktemp()

2025-06-11 Thread Chet Ramey
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

Re: Building bash 5.3, rc2, warning about mktemp()

2025-06-11 Thread Chet Ramey
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

static build fails with 5.3 rc2

2025-06-11 Thread Matthias Klose
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__)

Re: static build fails with 5.3 rc2

2025-06-11 Thread Greg Wooledge
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 her