Re: Function definition syntax inconsistencies

[Jan Schampera]

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.