Date: Sat, 4 Feb 2023 16:42:08 +0900
From: Koichi Murase <myoga.mur...@gmail.com>
Message-ID:
<CAFLRLk872wMgrNHxtWHD-xhF8UHJre-bzniE2LKxrqTw=yb...@mail.gmail.com>
| * 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''
That's because those things were originally ksh extensions, and the
shell that POSIX decided to use as its basic shell was mostly ksh.
Just some of what it had was dropped, as other shells hadn't copied
that, and it wasn't considered important enough to force them to do so.
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, and telling applications "you can rely upon this working
in this way" - which also then tells new implementations what they are
required to implement (some of this stuff is so bizarre that it is
almost incomprehensible - but it was implemented that way originally,
and scripts were written to work with it as implemented, so no-one has
ever been able to clean up some of the worst weirdness ever since).
| 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. As you would have seen from my earlier message, the NetBSD
shell allows just about anything at all as a function name. The one
thing that it rejects is a '/' in the name - just because if a function
with a name like that were defined, it would be useless, as we follow
that part of the command search & exec rules as specified (it makes things
easier for 99.99% of the users).
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.
| 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.
They're allowed because posix expressly allows them - because the ksh
of the time implemented those (before there was any written standard to
conform to).
| 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.
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. So no conforming application anywhere will call a
function "function" or "select" because those are known to possibly
be reserved words.
| 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 �.
Something like that could be suggested - I actually have no idea what
the outcome of that might be.
| 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).
Incidentally, while I understand your desire to make function namespaces
using '/' (though some other character, maybe @ or % or something might
have been a better choice) but how does your system work with global
variables that those functions might need? Variable names have a very
tight syntax, which really cannot be extended (or not very much, some
shells allow '.' in var names - but that's about all that's possible).
kre
