bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unset does not remove functions like a[b] unless -f is specified


From: Chet Ramey
Subject: Re: unset does not remove functions like a[b] unless -f is specified
Date: Fri, 3 Feb 2023 15:55:34 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.0

On 2/2/23 6:38 PM, Robert Elz wrote:
     Date:        Thu, 2 Feb 2023 15:36:30 -0500
     From:        Greg Wooledge <greg@wooledge.org>
     Message-ID:  <Y9wezobgTznjV0h8@wooledge.org>

   | There's a legitimate reason to support function names that contain *some*
   | punctuation characters beyond underscore.

There is a very good reason to allow function names to contain almost
any character at all.   See below.

There's no good reason to reduce the possible function namespace below
what's allowed for external commands.



   | A case might be made that slashes should also be disallowed,

That (and \0) are the exceptions.   But not because:

   | because it allows exported function names like /bin/echo to be
   | inherited by a script,


Bash doesn't import functions with slashes in their names.

which is harmless, unless the shell is badly breaking the command
execution rules of POSIX (zsh does I believe) but because for any
shell that follows those rules, it is impossible to invoke a function
with a '/' in its name.

Bash doesn't allow them to be created in POSIX mode. However, bash allows,
and has always allowed, function names to contain slashes when running in
default mode. This has been true for over 30 years.

The rules for executing commands require that any command name with a
'/' in it simply be handed to exec*() as is - it can never be a built
in command, can never be a function, and never searches PATH.

It's kind of redundant, since POSIX doesn't allow the application to have
function names that contain slashes in the first place.


That POSIX explicitly says the name space for function names is allowed
to be extended is a strong hint that it ought to be - and definitely means
that this is not an extension that needs to be disabled in "posix mode".

Earlier versions of the standard required the function name to be a NAME,
while acknowledging extensions were possible. I don't think it changed to
be an application requirement until 2001, at which point it wasn't useful
to change. After all, at that point we were almost ten years in with posix
mode!

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]