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

[Koichi Murase]

2023年2月4日(土) 19:06 Robert Elz <kre@munnari.oz.au>:
> I am fairly sure that Chet was speaking about when bash is in posix
> mode, not the default mode behaviour.

Thanks for the comments. If so, the only thing that I would like to
ask is about the possibility of allowing unspecified behaviors which
never affect the conforming scripts.

> But even when posix mode is enabled, there can be extensions, they
> just cannot alter the behaviour of a correct conforming script.

This is my point.  Allowing unspecified behaviors with the command
names being function names with slashes never affects the conforming
script because the conforming script never defines such functions.  It
doesn't break any behavior of conforming scripts.  If the script
defines shell functions with slashes in their names, that script is
not a correct conforming script anymore.  So, I thought there is room
to allow it just like `function NAME { list; }', `[[ ... ]]', and
`a[i]=v', which work even in the POSIX mode in Bash.

>  | I feel this is just an issue of the wording of the
>  | standard and its interpretation. Is it impossible that this is
>  | explicitly marked as `unspecified' in the standard?
>
> No, this one is very clear.

OK, I shouldn't have called it a wording issue.  Yes, I agree that the
wording is clear, but I wasn't sure if the wording is carefully
determined considering every corner case including the cases of
extended function namespace.  I guess there has been no discussion
about the slashes in function names because Bash seemed to have
continued to behave in the current way from 1988, so I guessed there
was an oversight about this corner case when the wording in 2.9.1 was
determined or when the non-NAME function names were first mentioned in
the standard.  It's not a wording issue but was what I intended to
mean.

2023年2月4日(土) 19:41 Robert Elz <kre@munnari.oz.au>:
> Note that POSIX isn't inventing what the shell (or anything else) should
> be (or it shouldn't ever do that, occasionally things happen) what it is
> doing is collecting the information about what shells do, distilling the
> common parts, [...]

Yes, I understand that the POSIX standard has that aspect, which is
the very reason that I asked about the possibility that the POSIX
could be modified to add a sentence about the unspecified behavior for
the command name being function names with slashes in the case the
script defined such functions based on the function-name extension by
the implementation.  Such a statement is irrelevant or doesn't change
anything for the shells that do not support defining function names
with slashes in their names.  The only relevant implementations are
the shells that accept function definitions with slashes in their
names, which are bash, zsh, yash, and mksh.  Here, we do not see a
consistent treatment, which I thought can be a reason for marking it
as `unspecified'.

>  | Wouldn't it be possible to make the result of defining the function
>  | names with slashes unspecified in a similar idea?
>
> No.   POSIX has no problem with a shell allowing you to define such a
> function.

OK, this is also mentioned by Oguz too. As I have already replied to
Oguz, just defining the function names with slashes wouldn't need to
make the entire shell behavior unspecified.

> Just defining such a function doesn't make your script fall outside
> posix, rather it is simply not necessarily going to be supported by all
> shells - so if you were aiming for a portable script, you would not do
> that.

So, does it mean that the shell scripts defining functions with their
names containing slashes are still considered correct conforming
scripts and are just not portable? But the standard says

> From XCU 2.9.5 Function Definition Command / Paragraph 3
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05
>
> [...]; 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.


> They were extensions that were known to exist (and in the reference
> shell no less) at the time the standard was written.   It is much
> harder now to add new things like that, as implementations and
> applications now have the standard that tells them what they can
> rely upon.

But, in reality, an application cannot rely on the behavior that the
functions with slashes in their names are ignored in the command
execution even when the implementation is known to allow defining such
functions, because the real behavior varies among such shells varies:
bash/zsh vs yash/mksh.  Anyway, I believe the applications defining
such functions are not conforming scripts, or at least the authors of
the scripts defining functions should know that such scripts are not
portable.

>   | 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 ».
>
> Something like that could be suggested - I actually have no idea what
> the outcome of that might be.

OK.

>   | Even if we would forget about the existing implementations and
>   | would make a standard from scratch,
>
> That wouldn't be a standard, it would be a fantasy (unless done by
> someone with the power to enforce its decisions - like a government -
> in which case it would be a law or regulation).

Yes, I know it's a fantasy so started with ``Even if xxx would''. It
was a reply to Oguz's point ``I don't think that's a good idea.''
Even if we would care about whether the idea is good or not ignoring
the existing implementation and the standard, I would think we might
still allow calling functions with slashes in their names.  If you
wouldn't try to discuss whether it is good or not ignoring the
existing implementations, you can dismiss that argument.  It was a
reply to Oguz.

--
Koichi