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.htmlThere 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