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

[Koichi Murase]

 2023年2月4日(土) 17:14 Oğuz <oguzismailuysal@gmail.com>:
> 4 Şubat 2023 Cumartesi tarihinde Koichi Murase <myoga.murase@gmail.com> yazdı:
>>
>> Wouldn't it be possible to make the result of defining the function
>> names with slashes unspecified in a similar idea?
>
> If you mean like declaring that a shell's overall behavior be unspecified

I didn't mean that the overall behavior is unspecified. By ``a similar
idea'', I meant that, similarly to XCU 2.4 and 2.10.2/7b (as listed
just before the question ``Woundn't it ...''), the standard might
declare that the behavior of the related parts becomes unspecified.
Changing the behavior related to the function names wouldn't make the
behavior of the shell entirely unspecified, though the impact is
admittedly wider than e.g. just defining a function with « function
NAME { list; } » syntax.

> But then how would you execute a program that resides in, for example, the 
> current directory portably? `(exec ./program)`?

If the script would intend to be portable, the script doesn't define a
function named `./program' to begin with, so one can safely call any
programs in the current directly portably. Also, the name conflicts
are not specific to this type of function name but can happen more
frequently with the simple NAME as the size of the namespace is
limited. In that case, maybe the user wants to intentionally replace
the utility of that name with a shell function, but a user might also
intentionally replace the utility specified by a pathname containing
slashes intentionally.

> I don't have any personal reason to support or not support what you propose, 
> but that names of functions and pathnames of executables can clash even under 
> POSIX mode doesn't feel right.

I think this is the point to discuss. I actually think that that is
also a valid way of thinking if we could carefully design the behavior
of Bash thirty years ago, but now I'm not sure if it would be
beneficial to change the behavior that has existed for thirty years. I
believe this behavior hasn't caused any real problems because portable
scripts do not define functions that have a slash in their name. With
old versions of Bash, one could export functions with slashes through
environment variables, but now it is also disabled after Shellcheck.

As far as I test, there are four implementations that allow defining
functions with slashes: Bash and Zsh allow executing the functions
(even in their POSIX modes), and mksh and Yash don't allow executing
them by default. I'm not sure if we can count Yash in thinking about
reasonable behavior because Yash intends to strictly conform to the
standard and is not designed for reasonable behaviors.

If a non-POSIX (ksh-like) shell script defines any functions with
names that have a slash and conflict with the real executable files
the script wants to run, the script should be responsible for any
problems caused by it. If the script wants to run the executable, the
script obviously shouldn't define the function with the same name as
the executable path. Also, in reality, the script currently cannot
expect that either one (the function or the executable file) is called
consistently and portably in Bash, Zsh, mksh, and Yash when there is a
conflict.

--
Koichi