>From the earlier message (just replying to this one to get the
new Subject: which fits better)...
zsan...@gmail.com said:
| I can work around function names needing to be valid shell 'name's by
That one bash could easily fix if it wanted to, there's never been a
POSIX requirement that only "name"s can be used as function names.
What it does require is that
name() ...
be a function definition, whereas what
+++() ...
might mean is just unspecified, so applications intending to be
portable should only use a "name" there, but the implementation can
treat the latter as a syntax error, or as defining a function called
"+++" (the sane thing to do), or as something different if they desire.
The standard says:
The function is named fname; the application shall ensure that it
is a name (see XBD Section 3.216) and that it is not the name of a
special built-in utility. An implementation may allow other
characters in a function name as an extension.
and that second sentence has been there since at least Posix Issue 4 (1994)
(the first has been rewritten a few times, but it isn't the relevant one.)
The only thing that really can't appear in a function name is '/' - and it
isn't because it would be an error to define it that way, but because the
execution rules don't allow finding a function with a '/' in its name
(that's also why using the name of a special built-in doesn't work) - so
those only working (if they do at all) in non-posix mode would be
reasonable, rejecting anything else (including things like operators, if
quoted, in both definition and execution) makes no sense - anything that
can be a command name which could be found by a PATH search ought to be
able to be a function name, in posix mode as well as not in it.
kre
