Date: Tue, 01 Aug 2017 15:31:31 -0700
From: L A Walsh <opengr...@tlinx.org>
Message-ID: <59810143.1030...@tlinx.org>
| Since the above "stance" would put new work on some shells, I'd like
| to recommend that the above behavior be standard for new implementations
| after its approved as such, with a note that it would become a
| requirement for existing shells by 2020/1/1(?) -- some future date
| to allow, hopefully, unrushed time for implementation...(?)
Regardless of the merits (or lack thereof) of the argument, the standard
does not work like that, it is not legislation, and does not invent rules
with which implementations must comply.
The only way that the standard will ever say that "exec fn" is possible
(exec builtin is supposed to be possible now, as (almost) all builtins
are supposed to have exec*(2) versions somewhere in $PATH) is if at least
the majority of shells implement it first.
The closest it is possible right now would be for it to say that it is
unspecified whether "exec fn" runs the function and then exits, rather
that searching for fn in path, and just failing to find it, and continuing.
Whether even that is reasonable, or whether exec should be required to
perform an exec*() system call (of something) and fail (set exit status and
continue running the script that called it) is still not decided.
Certainly most shells seem to be in the latter category.
kre
