Re: posix vs default mode nonsense

[Robert Elz]

>From the earlier message (just replying to this one to get the
new Subject: which fits better)...

zsanter@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