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

[Koichi Murase]

2023年2月4日(土) 15:38 Oğuz <oguzismailuysal@gmail.com>:
> 4 Şubat 2023 Cumartesi tarihinde Koichi Murase <myoga.murase@gmail.com> yazdı:
>>
>> Is Bash required to strictly follow the POSIX
>> standard even for non-POSIX shell scripts that use Bash extensions?
>
> It promises POSIX compatibility in POSIX mode, and POSIX says
> >If the command name contains at least one <slash>, the shell shall execute a 
> >non-built-in utility

Yes, I've also checked the POSIX wording, but should that rule also be
applied to the extensions? That is the question ``Is Bash required to
strictly follow ... that use Bash extensions?".

There are similar cases that the interpretation of the command names
can be changed from what is defined by POSIX. The `function' keyword
introduces a special syntax for the function definition, and `[[' also
introduces a special syntax, but these may be interpreted as command
names according to the standard. Also, array assignments `a[i]=x' may
be interpreted as a command name. Actually, for these cases, the POSIX
standard prepares loopholes of marking them `unspecified' as

* XCU 2.4 ``The following words may be recognized as reserved words on
some implementations (when none of the characters are quoted), causing
unspecified results: [[ ]] function select''

* XCU 2.10.2/7b ``If all the characters in the TOKEN preceding the
first such <equals-sign> form a valid name (see XBD Name), the token
ASSIGNMENT_WORD shall be returned. Otherwise, it is unspecified
whether rule 1 is applied or ASSIGNMENT_WORD is returned.''

Wouldn't it be possible to make the result of defining the function
names with slashes unspecified in a similar idea? That is what I was
thinking when I asked the question in the last sentence of my previous
reply.

> I think he meant he'll change that for POSIX mode only though

That makes more sense, but if I'm allowed to express my preference, I
would still be happy if the behavior for the functions with slashes in
their names is kept even in the POSIX mode just as ``function name {
list; }'' and ``[[ expr ]]'' is allowed even in the POSIX mode of
Bash.

I'm maintaining a framework that can be used from the users'
environment where the shell options are not under the control of the
framework, and the POSIX mode might be turned on by the users. The
framework has provided support even with the POSIX mode because it can
temporarily turn off the POSIX mode only during its loading time. This
is possible because Bash has allowed calls of the already-defined
functions with non-POSIX names even in the POSIX mode.

I understand that the reason that Bash can support ``function name {
list; }'' and ``[[ expr ]]'' even in the POSIX mode is that the POSIX
prepares the specific loopholes for them, but I guess the background
of the loopholes is that these are accepted extensions. So, I would be
happy if there would be room for the standard to change the wording of
XCU 2.9.1 so that « the result is unspecified when there is a matching
function name with slashes when the implementation extends the
function namespace as allowed in XCU 2.9.5/para3 ».

Zsh in the ``emulate sh'' mode also seems to continue to support the
calls of functions with slashes in their names. Even if we would
forget about the existing implementations and would make a standard
from scratch, I tend to think it would be reasonable to allow the
calls of functions with slashes in their names as far as defining such
functions is allowed.

--
Koichi