Re: clarification needed: shell 'exec' + function (builtin, …) vs. 'env'
Joerg Schilling via austin-group-l at The Open Group dixit: >OK, mksh pdksh and posh have te same origin. >I don't know oksh, loksh oksh is basically where mksh took off, an intermediate, pdksh without its compatibility layer and with a small amount of bugfixes; loksh is a GNU/Linux port of oksh. >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 I even referred to that as well, but as I read POSIX it defines what “command” is to include functions. Robert Elz via austin-group-l at The Open Group dixit: >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. OK, that is tricky to do _portably_… >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. Yes, historically, but not universally. >The standard is simply poorly written (I guess that no-one ever >imagined anyone being dumb enough to do it differently). Eh, doing it differently is pretty much what I’d *expect* as user. I expect that prefixing exec does not change what is actually run. That being said, the Korn shells have a way to do PATH search, so "$(whence -p commandname)" args… implements the problem from above. >My memory is that this is to be fixed in the next version. Oh? I’d like to read about this if it’s normative. (But that’d just mean the current implementation in mksh, where the legacy ksh88-style way of exec is used if set -o posix is set, can stay as-is.) >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. AND HOW DOES *THAT* DIFFER FROM exec? In fact, *env* is the one I’d expect to always run the external binaries… after all, env can be used to set up the environment in ways the shell rightfully refuses, and for this it’ll need to run through an env-changing exec* variant syscall. By contrast, prepending “exec” in the shell merely makes it so that the shell afterwards doesn’t continue, where possible optimising it as exec syscall. (But GNU bash, of course, cannot even get THAT right.) Interestingly enough, the env documentation speaks of “utility”, not “command”. I *think* this excludes functions, although it specifically mentions special built-ins aren’t supported. Is there any implementation of env that can call functions (and/or builtins) around? Otherwise I’d argue in favour of making sure that env can be used to get the external executable always, and allowing shells to use either for exec. (This is also more right because exec must always be a builtin, while env is not normally one.) I always thought the only difficulty in env is that it’s not available everywhere (e.g. older OpenBSD releases) and that some systems don’t have it in /usr/bin/ so shebangs are problematic. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
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, ???)
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, ???)
austin-grou...@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, ???)
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-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 + (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
--
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
clarification needed: shell 'exec' + function (builtin, …)
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
