Date: Fri, 3 Feb 2023 15:55:34 -0500 From: Chet Ramey <chet.ra...@case.edu> Message-ID: <a8dbbd44-e17a-3d83-32c0-17de98797...@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