Thanks for your replies. I didn't want to raise a portability and POSIX
discussion. I know about that. I was referring to either a bug in the
Bash manual or a bug in the Bash code, nothing else.
Let's try to rephrase that a bit (the topic is not POSIX nor portability):
The Bash manual allows the syntax of the function definition as follows:
-----------------------------
[ function ] name () compound-command [redirection]
This defines a function named name. The reserved word function is
optional. If the function reserved word is supplied, the parentheses
are optional. [...]
-----------------------------
That means for me, extracted, I have the following options:
1. name ()
2. function name ()
3. function name
They all work fine, EXCEPT:
When you use the third form shown above and use the subshell-grouping
compound command '(...)' as function body, then it doesn't pass the parser:
-----------------------------
$ function name (echo)
bash: syntax error near unexpected token `echo'
-----------------------------
That's the reason I think there's a bug, either in the description or in
the code. Since the rest of the behaviour of function definitions is
very consistent as described in the manual, I assume it's a bug in the code.
That's all about this bugreport, it wasn't about Bash allowing/not
allowing any standard/nonstandard features, it simply was about Bash not
being consistent in this one case.
J.
