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. > > [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. > > $ 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 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. If so, I honestly would like to block this new behavior. If changes are incrementally applied in two separate releases, by 1) first allowing more special characters in function names without quote removal in Bash 5.3, and then 2) turning on quote removal in Bash >= 5.4, it becomes a source of unnecessary compatibility issues. Scripts using the extended function namespace written for Bash 5.3 would soon be broken in future releases, so the 5.3 behavior would be useless. My first request is to turn on the quote removal finally, if more characters will be allowed in the name of the function definition. It is necessary to make the function namespace mostly the same as the namespace for the commands. I wouldn't request that it should happen in 5.3, but it may be turned on in any future release >= 5.3. 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. Otherwise, it would become a source of compatibility issues. Also, to me, the behavior to create a function named «'a b c'» instead of «a b c» seems simply strange. If the quote removal of the name of a function definition is not added in 5.3, I'd like to request the support for special characters like « ' » and « " » in the function name be postponed. Or, if « ' » and « " » in the name of the function definition will be allowed in 5.3, I'd like to request turning on quote removal of the name of the function definition in 5.3. > > 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. Fair enough. Even if it would be implemented, I agree that such a big change shouldn't happen at this stage of rc2. -- Koichi
