Joerg Schilling via austin-group-l at The Open Group dixit:
>here is where the original mail ended for me. Interesting that you did get
This is because m4.opengroup.org runs qmail, the arsehole under the MTAs,
which auto-converted the mail from quoted-printable to 8bit, sending it
as 8bit even to MTAs that don't offer 8BITMIME (I configured my sendmail
not to do that as well, so I got the same truncated mail back :( other
than qmail, exim is known to break the MIME and SMTP standards like that).
Here's it from my sent-mail folder, reduced to ASCII:
>>From: Thorsten Glaser <tg...@mirbsd.org>
>>Message-ID: <pine.bsm.4.64l.2012092106040.23...@herc.mirbsd.org>
>>To: austin-grou...@opengroup.org
>>Cc: miros-mksh@mirbsd.org
>>Followup-To: austin-grou...@opengroup.org, miros-mksh@mirbsd.org
>>Date: Wed, 9 Dec 2020 21:15:37 +0000 (UTC)
>>Subject: clarification needed: shell 'exec' + function (builtin, ...)
>>Reply-To: austin-grou...@opengroup.org, miros-mksh@mirbsd.org
>>
>>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
>Thorsten,
>
>do you know any shell besides mksh and zsh that call the function with this
>command?
>From IRC:
15:57 < orbea> yash matches the bash behavior fwiw
16:26 < orbea> pdksh, oksh, loksh, zsh and posh match mksh's behavior with
'exec', everything else including
ksh2020 and hsh match bash/yash
16:26 < orbea> as reproduced with: ls () { echo foo; }; exec ls
16:27 < miskatonic> and the difference is what?
16:28 < orbea> mksh prints 'foo', yash executes ls(1)
For what it's worth, the reporter agrees with my reading, that is,
that exec must run the function, then exit the shell.
>>From my understanding, calling the function is a bug.
>
>Important for me is that the Bourne Shell, ksh88 and ksh93 call ls(1), so this
>is historically correct and it was not seen as a problem by David Korn.
This is correct (that this is historically correct), but it is both
not what I'd expect as a user; prepending exec should not change
what's run; that historic behaviour also does not match my reading
of the standard.
I can live with it being open to implementations as well, but it's
best to clarify.
bye,
//mirabilos
--
<cnuke> den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt...
oder netzteile, an die man auch den monitor angeschlossen hat und die dann fuer
ein elektrisch aufgeladenes gehaeuse gesorgt haben [...] fuer lacher gut auf
jeder
LAN party | <nvb> damals, als der pizzateig noch auf dem monior "gegangen" ist
