Re: unset does not remove functions like a[b] unless -f is specified

[Koichi Murase]

2023年2月3日(金) 5:37 Greg Wooledge <greg@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 <greg@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
  }