Date: Wed, 2 Aug 2017 20:17:54 +0000 (UTC)
From: Thorsten Glaser <t...@mirbsd.de>
Message-ID: <pine.bsm.4.64l.1708022017080.15...@herc.mirbsd.org>
| I repeat: the exec builtin does *not* have anything to do with
| requiring the C code of the shell (could be COBOL for all I know)
| to actually call an exec*(2) syscall.
I agree, what the function is called, and the language in which the shell
is written, is irrelevant - but the intent of "exec" is your opinion, not
a fact, and one which, had it been asked 40 years ago, might not have
resulted in the answer you are hoping for.
Again, I have no particular feeling about which is right, I suspect that
there is no right answer - and that the only rational result is that portable
scripts cannot expect to be able to exec a function (or any builtin that is
not in the filesystem - what should "exec break" do really - and what if there
is no loop to break out of?) but that shells would not be prohibited from
extending "exec" to be able to do more than replace the shell with a
(perhaps different, "exec /bin/sh" is of course possible) image from the
filesystem -- even though doing the exec sys call is almost certainly what
was intended as the meaning for "exec" originally. (How any shell actually
implements that is none of the standard's business however, of course.)
kre
