Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: worley@alum.mit.edu (Dale R. Worley)
Newsgroups: gnu.bash.bug
Subject: How functions are defined
Date: Mon, 27 Apr 2020 22:03:47 -0400
Lines: 63
Approved: bug-bash@gnu.org
Message-ID: <mailman.1445.1588039435.3066.bug-bash@gnu.org>
References: <87pnbsfjss.fsf@hobgoblin.ariadne.com>
NNTP-Posting-Host: lists.gnu.org
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Received-SPF: softfail client-ip=2001:558:fe21:29:69:252:207:41; envelope-from=worley@alum.mit.edu; helo=resqmta-ch2-09v.sys.comcast.net
Precedence: list
Xref: csiph.com gnu.bash.bug:16252

While I was looking at the details of parsing function definitions, I
tripped on something I should have noticed long ago.  In the function
definition

    function foo() {
        command
    }

the '{' should not be recognized as the start of a group, because it is
not in one of the positions in which reserved words are documented to be
recognized:

   Reserved words are words that have a special meaning to the shell.  The
   following words are recognized as reserved when unquoted and either the
   first  word  of a simple command (see SHELL GRAMMAR below) or the third
   word of a case or for command:

   ! case  do done elif else esac fi for function if in select then  until
   while { } time [[ ]]

And if you pursue this further, it turns out that according to the
documentation, the only way to write a function body is with (...) or
((...)), as a function body is a shell_command, and those are the only
two tokens which start shell_commands that are not reserved words.

(IIRC, looking into the parsing code, you can see a line which is
executed when the function head has been parsed that turns on a flag
that allowed reserved words to be recognized.)

There's also the wording problem that a reserved word is never "the
first word of a simple command", as reserved words are never part of
simple commands.

So the first amendment that is needed is that "the first word of a
simple command" needs to be "where the first word of a simple command
could be", or something like that.

But that doesn't fix function definitions, because their bodies can't be
simple commands.  So there needs to be a further case in the rule.

Also, looking at the compound commands, "select" is like "for" and
"case" in that its third word is the reserved word "in".  There are also
situations where "do" is used where a simple command can't begin.

So it seems the reserved rule is more accurately:

       Reserved words are words that have a special meaning to the
       shell.  The following words are recognized as reserved when
       unquoted and either (1) where the first word of a simple command
       could be (see SHELL GRAMMAR below), (2) the third word of a case,
       for, or select command, the (3) first word of the body of a function
       definition, or (4) after a semicolon or newline:

IIUC there are two places where the documentation needs to be updated,
bash/doc/bash.1 and bash/doc/bashref.texi.  But the above wording is a
lot more complex than I'd like.  Does anyone have suggestions for a
clearer way to say this that is still accurate?

... Looking at this again, I think (1) and (3) can be replaced by "the
first word of a command (see SHELL GRAMMAR below)", which helps.

Dale