I agree more clarification is desirable. The reason I see as why the function
isn't executed is it may be treating it as an invoke of "sh -c ls", because ls
is a function, but this new sh does not inherit that definition so it looks on
path instead and finds the utility.
On Wednesday, December 9, 2020 Thorsten Glaser via austin-group-l at The Open
Group <austin-group-l@opengroup.org; miros-m...@mirbsd.org> wrote:
Hi *,
I’ve got a report in IRC by a user who spotted a cross-shell difference.
In my opinion, the invocation…
sh -c 'ls() { echo meow; }; exec ls'
… is supposed to output "meow\n and return to the caller with a zero
errorlevel.
Some shells execve() the ls(1) binary instead.
In particular, this was ksh88 behaviour, according to the comments
found in the pdksh-originating mksh source code.
My reading of this is:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#exec
⇒ exec is specified with 'command'
⇒ it will replace the shell with 'command' and never return to the shell
(note this does NOT mandate an actual execve(2) syscall or something)
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09
A command is one of the following:
* Simple command (see [134]Simple Commands)
* Pipeline (see [135]Pipelines)
* List compound-list (see [136]Lists)
* Compound command (see [137]Compound Commands)
* Function definition (see [138]Function Definition Command)
In the subsequent section 2.9.1 Simple Commands, Command Search and Execution,
step 1.c. finds the function.
Therefore, I believe that exec shall invoke the function, then terminate
the shell with the function’s $? as exit status.
(For builtins, 1.a. and 1.d. and 1.e.i.a. will find them.)
Thanks in advance,
//mirabilos
--
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
