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

[Robert Elz]

    Date:        Fri, 3 Feb 2023 15:55:34 -0500
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <a8dbbd44-e17a-3d83-32c0-17de987973ad@case.edu>

  | There's no good reason to reduce the possible function namespace below
  | what's allowed for external commands.

Agreed.

  | However, bash allows,
  | and has always allowed, function names to contain slashes when running in
  | default mode. This has been true for over 30 years.

I never knew that, and I've been using bash probably all of that time.

  | It's kind of redundant, since POSIX doesn't allow the application to have
  | function names that contain slashes in the first place.

Well, kind of - a portable application cannot assume that function names
that are not "name"s will work - but the shell is allowed to support more
than that:

        An implementation may allow other characters in a function name
        as an extension.

and if the application knows that the implementation permits it, is able to
make use of whatever extra characters the implementation allows.   The
script would not be portable, or not to all conforming shells, but that
might not matter.

But a posix conforming shell will still never execute a function that
has a '/' in its name, even if it has extended the character set for
function names, and allows '/' in that set.   In posix mode (any shell
that conforms) has no wriggle room on that one.  ./a.out is required
to execute the "a.out" file in the current directory, and the existence
of a function named "./a.out" isn't permitted to stop it, even if the
implementation allows a function of that name to be defined.   Scripts
should be able to rely upon that.

  | Earlier versions of the standard required the function name to be a NAME,
  | while acknowledging extensions were possible.

It still does.   There are a few places in the standard where extensions
are strongly hinted at as being possible - and many other places where
various implementations have extended things that the standard doesn't
even hint at (eg: the ${var/...} extensions that exist - POSIX doesn't
even suggest that those added operators are possible, but if not defined
to mean something they would just be errors - so implementations can add
that kind of thing safely (no conforming application will accidentally be
using that syntax expecting something else to happen).

The point of all of this is that if all shells started adopting a MUCH
wider character set for function names, perhaps the next revision of the
standard (not the one coming next year or whenever - but the one after
that, Issue 9, perhaps in the mid or late 2030's [I am guessing]) might
be able to alter the definition so the function name is just a word, rather
than a NAME, ie: the same syntax as a command-name in a simple command.

kre