Re: clarification needed: shell 'exec' + function (builtin, ???)
Hallo Jörg.
Joerg Schilling wrote in
<2020124507.zccfs%sch...@schily.net>:
|"Steffen Nurpmeso via austin-group-l at The Open Group" wrote:
|> Joerg Schilling wrote in
|> <20201210004945.i3n8e%sch...@schily.net>:
|>|Steffen Nurpmeso wrote:
|>|> this is an iconv(3)-related error that was fixed in later version
|>|> of the mailer you use. The very error came up on the ML this
..
|>|You are correct,
|>
|> Yep -- unfortunately.
|
|I meanwhile discovered (from a hint in another mail in this thread \
|that I canot
|answer) that the trigger may be an embedded nul character.
|
|The s-nail error message was:
|
| "Failed to prepare composed message"
So you could not fully read it .. and tried to respond to the
"half-seen" message nonetheless?
Regardless, it is fixed in the version that will become obsolete
tomorrow.
|and the mail display (before I tried to answer) stopped before the \
|line that
|contained that nul character. Again saving the mail to a file and using \
|iconv(1)
|did result in "useful" converted output.
|
|There seem to be two things that need to be handled in a way that never \
|causes
|a mail (regardless of the content) to prevent reading or answering.
|
|- EILSEQ should not result in shortened mails or errors that abort
| work completely for that mail.
|
|- Characters that cause EILSEQ should be transformed into "something"
| in the output that at least is a hint for that problem.
Ah, it is not that alone, people are playing games and inject
invalid bytes in base64 streams and such. We handle these cases
well for a remarkable long time, when viewed in context.
It is a pity that the software is not yet at a point where we can
simply log such occurrances though, even though we can join
successive error messages in the style known from syslog. (At the
beginning we did, but it could have caused hundreds of log
messages.)
|I am not sure whether that helps, but I remember from my experiences from
|mkisofs that iconv() from glibc has a bug and ignores *outbytesleft. This
|frequently results in reading or writing too much data.
In the software i maintain i found references to problems
regarding character sets and iconv(3). I have seen _very_ strange
names like (that is phantasie) western-subset-european-10646 or
something like that (that was on UnixWare). How could anyone deal
with that portably?
Decades ago i was hm foolishly prowd of my
way of generating character set names, because we normalized them
splitting at boundaries which included numbers (so utf-8 and utf8
would end up as one entry "utf 8" to test). One decade ago the
Python people did not like it (and also separate(d) with
hyphen-minus not whitespace which i found strange.
Today (what a ridiculous regress!) i have to write code like
static char const * const names[] = {"csASCII", "cp367", "IBM367", "us",
"ISO646-US", "ISO_646.irv:1991", "ANSI_X3.4-1986", "iso-ir-6",
"ANSI_X3.4-1968", "ASCII", "US-ASCII"};
to find out whether anything is actually defined in US-ASCII,
because no official interfaces exist which give someone a hint.
Ciao,
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: clarification needed: shell 'exec' + function (builtin, ???)
"Steffen Nurpmeso via austin-group-l at The Open Group" wrote: > Hallo Jörg, all, > > Joerg Schilling wrote in > <20201210004945.i3n8e%sch...@schily.net>: > |Steffen Nurpmeso wrote: > |> this is an iconv(3)-related error that was fixed in later version > |> of the mailer you use. The very error came up on the ML this > |> year[1], basically you use LATIN1 on your box, as could be > |> expected, but Thorsten is known to be a Unicode character > |> "junkie", so to say. > | > |You are correct, > > Yep -- unfortunately. I meanwhile discovered (from a hint in another mail in this thread that I canot answer) that the trigger may be an embedded nul character. The s-nail error message was: "Failed to prepare composed message" and the mail display (before I tried to answer) stopped before the line that contained that nul character. Again saving the mail to a file and using iconv(1) did result in "useful" converted output. There seem to be two things that need to be handled in a way that never causes a mail (regardless of the content) to prevent reading or answering. - EILSEQ should not result in shortened mails or errors that abort work completely for that mail. - Characters that cause EILSEQ should be transformed into "something" in the output that at least is a hint for that problem. I am not sure whether that helps, but I remember from my experiences from mkisofs that iconv() from glibc has a bug and ignores *outbytesleft. This frequently results in reading or writing too much data. Jörg -- EMail:jo...@schily.net Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Re: clarification needed: shell 'exec' + function (builtin, ???)
[I bring back austin-group-l, ok?
Thorsten Glaser wrote in
:
|Steffen Nurpmeso dixit:
|
|> #include
|> #include
|> #include
|> #include
|> int main(void){
|> char inb[16], oub[16], *inbp, *oubp;
|> iconv_t id;
|> size_t inl, oul;
|>
|> memcpy(inbp = inb, "a\303\244c", sizeof("a\303\244c"));
|> inl = sizeof("a\303\244c") -1;
|
|Not -1 otherwise oub will not be NUL-terminated and end with junk:
|
|$ ./a.out
|Converting 4
|GOT
Sure thing. Just like below. Normally stack pages are cow forked
from zero if i understand that right. But maybe i do not.
|Without the trailing NUL, stateful conversation may also be
|incomplete…
|
|> oul = sizeof oub;
|> oubp = oub;
|>
|> if((id = iconv_open("ascii", "utf8")) == (iconv_t)-1)
|> return 1;
|
|Throws 1 because you need "utf-8", but with it, see above.
Well names and iconv are a thing. Especially regarding Unicode
(and nl_langinfo(CODESET), if i remember UnixWare right).
|> fprintf(stderr, "Converting %lu <%s>\n",(unsigned long)inl, inbp);
|> if(iconv(id, , , , ) == (size_t)-1){
|>fprintf(stderr, "Fail <%s>\n", strerror(errno));
|>return 2;
|>}
|> fprintf(stderr, "GOT <%s>\n", oub);
|> iconv_close(id);
|> return 0;
|>}
|>
|>you should get replacement characters out of the box?
|
|Citrus iconv agrees. Its manpage says:
|
| If the string pointed to by *src contains a character which is valid
| under the source codeset but can not be converted to the destination
| codeset, the character is replaced by an "invalid character" which
| depends on the destination codeset, e.g., '?', and the conversion \
| is con-
| tinued. iconv() returns the number of such "invalid conversions".
That was my thinking.
Thanks for confirming this.
--End of
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: mail encoding not-fun (was Re: clarification needed: shell 'exec' + function (builtin, ???))
Thorsten Glaser via austin-group-l at The Open Group wrote in : |Steffen Nurpmeso via austin-group-l at The Open Group dixit: | |>|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). |> |>Naaah, not true Thorsten. At least this time. | |This one *is* correct, as I got the broken message back as well. |It contains an embedded NUL. | |But apparently, this was not the cause of J�rg’s problem ☻ Evil, you. Hey, i live also on IRC since ~1.5 years for the first time ever, and on this Linux-Distro (just released 3.6 two days ago) here is someone active from Düsseldorf, and i now sometimes listen to La Düsseldorf from La Düsseldorf. (Of course Neu! and Lilo Engel are less populist.) Lots of longing for the 70s here. Tja. All he would need to do would be to upgrade to a newer version, i think i innocently prod him two times on that. |>Related to my MUA. |[…] |>I have been able to save the mail as file and to run iconv(1) on the \ |>content. | |oic | |>Maybe a problem is that the first missing line is a line with a character \ |>that |>is not part of ISO-8859-1 | |Yes, of course, I have been writing in UTF-8 for a while. Not so here, even though i have ~/.kent.xmodmaprc keycode adjustments for some German and French quotation marks, i find it hard to go "random Unicode". I usually use altgr/g-a in vim and the look in UnicodeData.txt to find the codepoint ;) |[00:02] gecko: benutzt du emacs ? |[00:03] nö [00:03] nur n normalen mac Graphical selection may be a winner here, indeed. |[00:04] argl [00:04] ne den editor | -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.) --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: clarification needed: shell 'exec' + function (builtin, ???)
Hallo Jörg, all,
Joerg Schilling wrote in
<20201210004945.i3n8e%sch...@schily.net>:
|Steffen Nurpmeso wrote:
|> this is an iconv(3)-related error that was fixed in later version
|> of the mailer you use. The very error came up on the ML this
|> year[1], basically you use LATIN1 on your box, as could be
|> expected, but Thorsten is known to be a Unicode character
|> "junkie", so to say.
|
|You are correct,
Yep -- unfortunately.
|I have been able to save the mail as file and to run iconv(1) on the \
|content.
Yes, we temporarily did not restart for ILSEQ, if your prompt
would include "set prompt='\${^ERRNAME}', for example, you would
have seen that an error happened.
But of course we are tolerant for weird base64, so we should be
tolerant for weird iconv, thus i "restored the original
behavirour", so to say.
That reminds me of iconv weirdness regarding hard-to-test
replacement characters, which makes testing really hard. Wasn't
there an issue on that going on, being able to specify it
explicitly, and whether it stands for an entire character or for
by-byte sequences would be a great improvement.
While talking about iconv, i got closed glibc bug[1] as "resolved
invalid", but wouldn't you all agree that in the following
#include
#include
#include
#include
int main(void){
char inb[16], oub[16], *inbp, *oubp;
iconv_t id;
size_t inl, oul;
memcpy(inbp = inb, "a\303\244c", sizeof("a\303\244c"));
inl = sizeof("a\303\244c") -1;
oul = sizeof oub;
oubp = oub;
if((id = iconv_open("ascii", "utf8")) == (iconv_t)-1)
return 1;
fprintf(stderr, "Converting %lu <%s>\n",(unsigned long)inl, inbp);
if(iconv(id, , , , ) == (size_t)-1){
fprintf(stderr, "Fail <%s>\n", strerror(errno));
return 2;
}
fprintf(stderr, "GOT <%s>\n", oub);
iconv_close(id);
return 0;
}
you should get replacement characters out of the box?
I said by then
$ /tmp/zt
Converting 4
Fail
whereas musl gives
$ ./zt
Converting 4
GOT
and i still think musl is totally right (also by giving only one
replacement character.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=22908
|Maybe a problem is that the first missing line is a line with a character \
|that
|is not part of ISO-8859-1
Yes, transliteration should possibly be possible.
On the other hand, if i change the above to
if((id = iconv_open("ascii//TRANSLIT", "utf8")) == (iconv_t)-1)
i get
Converting 4
GOT
and with
if((id = iconv_open("ascii//TRANSLIT", "utf8")) == (iconv_t)-1)
we are back at the error.
Ciao,
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: clarification needed: shell 'exec' + function (builtin, ???)
Robert Elz wrote, on 10 Dec 2020: > > This has been discussed (somewhere) before It was discussed on this list and resulted in bug 1157 (which was applied in Issue 8 draft 1). -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
mail encoding not-fun (was Re: clarification needed: shell 'exec' + function (builtin, ???))
Steffen Nurpmeso via austin-group-l at The Open Group dixit: > |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). > >Naaah, not true Thorsten. At least this time. This one *is* correct, as I got the broken message back as well. It contains an embedded NUL. But apparently, this was not the cause of J�rg’s problem ☻ >Related to my MUA. […] >I have been able to save the mail as file and to run iconv(1) on the content. oic >Maybe a problem is that the first missing line is a line with a character that >is not part of ISO-8859-1 Yes, of course, I have been writing in UTF-8 for a while. bye, //mirabilos -- [00:02] gecko: benutzt du emacs ? [00:03] nö [00:03] nur n normalen mac [00:04] argl [00:04] ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
Re: clarification needed: shell 'exec' + function (builtin, ???)
Steffen Nurpmeso wrote: > this is an iconv(3)-related error that was fixed in later version > of the mailer you use. The very error came up on the ML this > year[1], basically you use LATIN1 on your box, as could be > expected, but Thorsten is known to be a Unicode character > "junkie", so to say. You are correct, I have been able to save the mail as file and to run iconv(1) on the content. Maybe a problem is that the first missing line is a line with a character that is not part of ISO-8859-1 Jörg -- EMail:jo...@schily.net Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Re: clarification needed: shell 'exec' + function (builtin, ???)
This has been discussed (somewhere) before - but in the context of being able to guarantee that the filesystem command is run, and not anything else. Specifying the full path will do that, but to do that portably means the script needs to do its own PATH search, and that's ugly. The overall conclusion is that (exec command) is the best way to do it. That requires that exec only ever run filesystem commands, which is what it did historically. The standard is simply poorly written (I guess that no-one ever imagined anyone being dumb enough to do it differently). My memory is that this is to be fixed in the next version. Note that the sometimes suggested "env command" isn't guaranteed to work, env just sets up the environment, for the command, then runs it. There's no reason that env cannot be built into a shell, and if it is, then being able to run finctions and builtin commands (particularly with env -i) is a very useful ability to have. kre
Re: clarification needed: shell 'exec' + function (builtin, ???)
austin-group-l@opengroup.org wrote in : |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). Naaah, not true Thorsten. At least this time. Related to my MUA. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: clarification needed: shell 'exec' + function (builtin, ???)
Hallo Jörg, Joerg Schilling wrote in <2020120933.yyo5w%sch...@schily.net>: |"shwaresyst via austin-group-l at The Open Group" wrote: ... |> Hi *, | |Hi, | |here is where the original mail ended for me. Interesting that you did get |more content. Is there any idea, why I received only the first line \ |from the |original mail? this is an iconv(3)-related error that was fixed in later version of the mailer you use. The very error came up on the ML this year[1], basically you use LATIN1 on your box, as could be expected, but Thorsten is known to be a Unicode character "junkie", so to say. commit a9ec20d6 Author: Steffen Nurpmeso AuthorDate: 2020-04-23 17:29:57 +0200 Fix: "revert" [ab0cd3b8] from 2017-10-20.. (Claus Assmann).. (FIX iconv for main body part (since EVER!) (Doug McIlroy, Random832)..) was nonsense in sofar as we now generated ILSEQ errors, but without giving any error message, so that users (without nice *prompt*) normally had no indication of what happened, but looked at a partial message. This is inacceptible, so instead simply use replacement until we possibly have a better way out at some later time. This changeset is in v14.9.19. [1] https://www.mail-archive.com/s-mailx@lists.sdaoden.eu/msg01013.html P.S.: i will release v14.9.20 before Christian Christmas, and that should just work neatly on SchilliX, too, including readily prepared catman manual (to be downloaded as an extra). --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: clarification needed: shell 'exec' + function (builtin, ???)
"Thorsten Glaser via austin-group-l at The Open Group"
wrote:
> 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).
Thank you for this information.
> >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)
OK, mksh pdksh and posh have te same origin.
I don't know oksh, loksh
> I can live with it being open to implementations as well, but it's
> best to clarify.
Well, the Bourne Shell man page says:
The command specified by the arguments is executed in
place of this shell without creating a new process. ...
The POSIX text is:
If exec is specified with command, it shall replace the shell
with command without creating a new process. ...
So the main statement in both is that the command is executed in place of
the shell. This seems to be obviously a hint that the shell cannot run
anymore and thus the function cannot be executed.
Jörg
--
EMail:jo...@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/
Re: clarification needed: shell 'exec' + function (builtin, ???)
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
>>Message-ID:
>>To: austin-group-l@opengroup.org
>>Cc: miros-m...@mirbsd.org
>>Followup-To: austin-group-l@opengroup.org, miros-m...@mirbsd.org
>>Date: Wed, 9 Dec 2020 21:15:37 + (UTC)
>>Subject: clarification needed: shell 'exec' + function (builtin, ...)
>>Reply-To: austin-group-l@opengroup.org, miros-m...@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
--
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 | damals, als der pizzateig noch auf dem monior "gegangen" ist
Re: clarification needed: shell 'exec' + function (builtin, ???)
"shwaresyst via austin-group-l at The Open Group"
wrote:
>
> 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 wrote:
> Hi *,
Hi,
here is where the original mail ended for me. Interesting that you did get
more content. Is there any idea, why I received only the first line from the
original mail?
...
> 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.
Thorsten,
do you know any shell besides mksh and zsh that call the function with this
command?
>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.
Jörg
--
EMail:jo...@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/
RE: clarification needed: shell 'exec' + function (builtin, …)
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 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
