2023年2月3日(金) 5:37 Greg Wooledge <g...@wooledge.org>: > There's a legitimate reason to support function names that contain *some* > punctuation characters beyond underscore. Hyphens, periods, colons (single > or double) -- all fine. Some people like namespace::function names, and > bash should continue to allow those.
For this reason, it would be hard to restrict all the function names that are not `NAME's at this time for backward compatibility. The Bash scripts that use these punctuation characters (-, ., :, ::) in function names are ubiquitous, and it is impractical to restrict the function names to the POSIX ones in this timing. > A case might be made that slashes should also be disallowed, It would break all my scripts, which use slashes for the pseudo-namespacing, so I'm personally unhappy if the function names would be restricted at this time. As far as I try the oldest Bash version 1.14.7 available at < https://ftp.gnu.org/gnu/bash/ > (I haven't applied reverse patches of 1.14.*), it already supports a slash in function names outside the `-o posix' mode: $ bash-1.14 -c 'func/name() { echo a; }; func/name' a so the support for the function names has a history of mostly thirty years. Maybe it is a bit off-topic, but there is a background where I use slashes in the function names: I was initially using periods for the pseudo-namespacing in my bash configurations, but a problem arose with the command/function-name completions for such a function as the number of functions increased; All the function names under the entire function tree of the namespace are generated at once. and the resulting completion list was always too long, so I wanted to restrict the generated function names to be the same namespace level as the text already in the current text buffer. Then, I found that it is very useful to organize the function names in the same way as the filename paths by including namespaces like directory names. 1) The experience of the completion of function names under namespaces becomes the same as the normal path completions, though one needs to manually implement the function name filtering using the programmable completions. 2) We may distinguish the private and public functions by the consistent naming by prefixing period to the name of the private function names and namespace names. e.g., namespace1/public-function vs namespace1/.private-function. For this reason, I personally like this naming convention very much. Of course, it could hide the executable files under subdirectories that have the same names as namespaces, but as far as we avoid using a typical subdirectory name (like `bin', `src', etc.) for the namespace name, I think it would rarely become a practical issue. At least, I've never met such a conflict. Maybe we could forbid the function names starting with a slash (like /bin/echo) while keep allowing function names to contain slashes in the second or later character positions, but it anyway breaks backward compatibility, and there is no guarantee that there are no wild Bash scripts that use the function names starting with a slash. A naive usage could be to quickly patch the behavior of an existing script by overwriting `/usr/bin/something' when the system `/usr/bin/something' is incompatible with the requirements of the current script, though it should ideally be carefully rewritten without relying on such a tentative hack. > because it > allows exported function names like /bin/echo to be inherited by a > script, potentially causing all kinds of odd behavior. 2023年2月3日(金) 9:50 Greg Wooledge <g...@wooledge.org>: > [...] but I'll > also point out that so far I have not been able to export a function > named /bin/echo through the environment and into a bash script. I'm not > sure whether it's possible -- but the failure could simply be due to a > lack of creativity on my part. It was made impossible after Shellshock, so we don't have to care specifically about it for the future Bash change of the function names. ---- By the way, Zsh allows expansions in function names in the declaration of the form `function FUNCTION_NAME { ... }'. The function is defined with the name after the expansions are performed. I actually think maybe we could also support it because this is useful for namespacing. This is an example: $ cat reply202301-011.zsh #!/usr/bin/zsh ns=mylib.util.example function $ns.func1 { echo func1; } function $ns.func2 { echo func2; } declare -f "$ns.func1" declare -f mylib.util.example.func2 $ zsh reply202301-011.zsh mylib.util.example.func1 () { echo func1 } mylib.util.example.func2 () { echo func2 }