Dashes in function names: Undocumented?

[Matthew Persico]

I put a bug report into an emacs group because the bash syntax highlighter
failed to recognize functions whose names have dashes in them.

The maintainer came back with this:

I can reproduce this behaviour, but is it really a bug? Aren't the
names with '-' invalid?
The Bash Reference Manual says:
name
A word consisting solely of letters, numbers, and underscores, and
beginning with a letter or underscore. Names are used as shell
variable and function names. Also referred to as an identifier.
https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html

I looked at the manual and I didn't see positive or negative
acknowledgement that dashes can be used in function names. But it does work.

Update to manual?

name
A word consisting solely of letters, numbers, and underscores, and
beginning with a letter or underscore. Names are used as shell
variables. Also referred to as an identifier.

function name
A word consisting solely of letters, numbers, underscores, dashes, and
beginning with a letter or underscore. Function names are used to label
shell
functions.

--
Matthew O. Persico

[Eli Schwartz]

On 8/12/20 10:51 AM, Matthew Persico wrote:
> I put a bug report into an emacs group because the bash syntax highlighter
> failed to recognize functions whose names have dashes in them.
>
> The maintainer came back with this:
>
> I can reproduce this behaviour, but is it really a bug? Aren't the
> names with '-' invalid?
> The Bash Reference Manual says:
> name
> A word consisting solely of letters, numbers, and underscores, and
> beginning with a letter or underscore. Names are used as shell
> variable and function names. Also referred to as an identifier.
> https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html
>
> I looked at the manual and I didn't see positive or negative
> acknowledgement that dashes can be used in function names. But it does work.
>
> Update to manual?

The bash-20191127 snapshot updated the manpage documentation for a
function definition (to align with reality). It is now defined as:

function fname [()] compound-command [redirection]

and includes the description:

When in posix mode, fname must be a valid shell name and may not be the
name of one of the POSIX special builtins. In default mode, a function
name can be any unquoted shell word that does not contain $.

For context:

word - A sequence of characters considered as a single unit by the
shell. Also known as a token.

name - A word consisting only of alphanumeric characters and
underscores, and beginning with an alphabetic character or an
underscore. Also referred to as an identifier.

> name
> A word consisting solely of letters, numbers, and underscores, and
> beginning with a letter or underscore. Names are used as shell
> variables. Also referred to as an identifier.
>
> function name
> A word consisting solely of letters, numbers, underscores, dashes, and
> beginning with a letter or underscore. Function names are used to label
> shell
> functions.
>


--

Eli Schwartz
Bug Wrangler and Trusted User

[Matthew Persico]

On Wed, Aug 12, 2020 at 11:06 AM Eli Schwartz <esch...@archlinux.org>
wrote:

Thanks. I will take your word for it, as I cannot seem to find that text at
https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html, unless
that is not the canonical location for the manual.

--
Matthew O. Persico

[Eli Schwartz]

On 8/12/20 11:51 AM, Matthew Persico wrote:
> Thanks. I will take your word for it, as I cannot seem to find that text at
> https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html, unless
> that is not the canonical location for the manual.

The canonical location is surely the source code:
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=091c6bc481bd2b405e39b6ad5967eb4fa2aab597

The link you're using claims to have been last updated on 12 May 2019,
and I definitely would not rely on it being updated with every commit.

You could get the html doc as a plaintext file from
https://git.savannah.gnu.org/cgit/bash.git/plain/doc/bash.html?h=devel
and then open it in an HTML viewer (opening the link in a browser does
not work on its own because it is Content-Type: text/plain;)

--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

[Chet Ramey]

On 8/12/20 12:01 PM, Eli Schwartz wrote:
> On 8/12/20 11:51 AM, Matthew Persico wrote:
>> Thanks. I will take your word for it, as I cannot seem to find that text at
>> https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html, unless
>> that is not the canonical location for the manual.
>
> The canonical location is surely the source code:
> https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=091c6bc481bd2b405e39b6ad5967eb4fa2aab597
>
> The link you're using claims to have been last updated on 12 May 2019,
> and I definitely would not rely on it being updated with every commit.

The manual on savannah describes the current major release, as does the
manual on www.gnu.org.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU ch...@case.edu http://tiswww.cwru.edu/~chet/

[Robert Elz]

Date: Wed, 12 Aug 2020 11:05:40 -0400
From: Eli Schwartz <esch...@archlinux.org>
Message-ID: <f53f8a84-ac66-6d61...@archlinux.org>

| When in posix mode, fname must be a valid shell name and may not be the
| name of one of the POSIX special builtins. In default mode, a function
| name can be any unquoted shell word that does not contain $.

There's no need for the posix mode test here, in posix mode a function
with the same name as a special builtin won't be found (the special builtin
is located first) but it doesn't need to be an error to define it (posix
does not require that).

Further this works fine in bash, simply do something like

set +o posix
exec() { printf %s\\n 'exec called'; }
exec /bin/sh
set -o posix
exec /bin/sh

and watch what happens (it helps if /bin/sh is not bash, if it is,
use something different to make it easier to determine what occurred).

Further, posix permits extensions to the syntax for function names as
an extension - applications cannot assume that anything which is not a
name (as defined) will work in any arbitrary conformant shell, but there
is no requirement on the shell validate that function names are "name"s
in the POSIX sense (it is of course allowed for them to do so).

For extended function names, a shell can allow what it likes, so "everything
except '$') is certainly permitted. I'm not sure why '$' needs to be
prohibited though (unless it is just to avoid the noise from people who
don't understand why things aren't doing what they expecr), in

func$3() { command-list; }

the '$' is not expanded, no word expansions happen to the function name
in a function definition, and while

func$3 arg

will certainly not invoke that function ($3 would be expanded there),

func\$3 arg

would invoke it (or 'func$3' or $'func$3' or whatever).

Going the other way, it might make some sense however to prohibit '/'
in a function name, as there is truly no way to invoke such a function,
any command name containing a '/' anywhere bypasses all that part of the
lookup process and is simply exec()'d via the filesystem.

kre

[Chet Ramey]

On 8/13/20 3:32 AM, Robert Elz wrote:
> Date: Wed, 12 Aug 2020 11:05:40 -0400
> From: Eli Schwartz <esch...@archlinux.org>
> Message-ID: <f53f8a84-ac66-6d61...@archlinux.org>
>
>
> | When in posix mode, fname must be a valid shell name and may not be the
> | name of one of the POSIX special builtins. In default mode, a function
> | name can be any unquoted shell word that does not contain $.
>
> There's no need for the posix mode test here, in posix mode a function
> with the same name as a special builtin won't be found (the special builtin
> is located first) but it doesn't need to be an error to define it (posix
> does not require that).

It's an application restriction that bash chooses to enforce: "the
application shall ensure that it is a name (see XBD Name) and that it is
not the name of a special built-in utility."

It's a non-fatal error; some shells, like dash and ksh93, make it a fatal
syntax error to define a function with the same name as a special builtin.

Chet