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

[Chet Ramey]

On 6/11/25 12:17 PM, Koichi Murase wrote:

2025年6月11日(水) 23:07 Chet Ramey <chet.ra...@case.edu>:

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.

Why would that be any different? `<' and `>' used to be treated like `$',
which bash has always disallowed in function names for some reason that's
been lost to history, but they don't need to be.

[1] https://lists.gnu.org/archive/html/bug-bash/2023-02/msg00007.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.

If only you had brought it up sometime in the past 2.5 years. Then maybe
we could have had a discussion that would have affected bash-5.3. As it
is, I've backed out the change. I think kre's suggestion is a good one,
and appropriate for a future bash version.

    $ 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).

Yes, both shells that allow quotes in function names perform quote removal.
Most existing shells don't allow function names to contain quotes.

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.

You mean quote removal on function names hasn't been part of the language?
You're right, in the sense that POSIX says nothing about it, and most
shells don't perform it. But until there is a release that allows quote
characters in function names, you don't need to perform quote removal.

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.

The only shells that do this are zsh and the NetBSD shell.

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 »).

That won't be in bash-5.3.

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.

That's the historical behavior, yes, and that's how it will be in 5.3.

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.

OK.

My second request is that "more characters in the function name" and
"quote removal of the function name" should be implemented in the same
release version.

This is reasonable. The best way to get there is to back out the changes
in bash-5.3 and wait for a future release.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    c...@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature