Re: 'exec' runs shell functions and builtins

[Martijn Dekker]

Op 08-08-17 om 00:49 schreef Thorsten Glaser:
> I completely disagree, especially when combined with other wording.

Well, Geoff Clare did say the existing wording is broken in any case.

If the goal is compatibility with pre-existing practice (in this case,
ksh88) and the majority of other shells which follow it, then the exact
wording is irrelevant anyway.

> But, well, POSIX was never among the more useful standards…

Since you seem to despise it with such a passion, I honestly wonder why
you haven't simply ripped out POSIX compatibility mode a long time ago.
Are there compelling reasons why you have to keep bothering with it?

- M.

Re: 'exec' runs shell functions and builtins

[Thorsten Glaser]

Robert Elz dixit:

>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

Yes, but the others in this thread want to allow portable scripts
to rely on the exec builtin always resulting in a PATH search.
This is extra effort on my side *and* limiting.


Martijn Dekker dixit:

>Another fact is that pdksh was intended to be a clone of ksh88. Thus,

Not fully, and never exactly. With mksh that’s no part of the
mission statement any more anyway, although I believe it has
not been in pdksh for a while before its death in 1999 either.

>Every other shell except zsh acts like ksh88. And the zsh devs just
>fixed the problem for its POSIX mode the other day.

This sucks…

>Since you appear to feel strongly about this, maybe a compromise would
>be to make mksh act like ksh88 for POSIX mode only.

Yeah, let’s add more conditional code… I just did that ☹

>| The use of "program" and "overlaid the shell" here means that the
>| standard clearly does not allow the execution of built-in utilities and
>| functions.

I completely disagree, especially when combined with other wording.

But, well, POSIX was never among the more useful standards…

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Re: 'exec' runs shell functions and builtins

[Thorsten Glaser]

Martijn Dekker dixit:

>> And this is utter nonsense, the builtin does replace the shell process,
>
>No. On mksh, 'exec builtin' is exactly equivalent to 'builtin; exit'.
>The builtin is run in the existing shell process. No
>replacing/overlaying of the shell process takes place. It's easy to
>verify this in the source code.

This is an implementation detail. Whether it’s running the same
binary is independent of this.

Compare:

ln -s $(which mksh) print
PATH=.
exec print foo

This does the same, except the “replacing the shell by the builtin”
without an actual exec is cheaper. The *functionality* of the program
is still substituted from shell to builtin.

bye,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Re: 'exec' runs shell functions and builtins

[Joerg Schilling]

Martijn Dekker  wrote:

> Op 02-08-17 om 22:17 schreef Thorsten Glaser:
> > Robert Elz dixit:
> > 
> >> The only way that the standard will ever say that "exec fn" is possible
> >> (exec builtin is supposed to be possible now, as (almost) all builtins
> >> are supposed to have exec*(2) versions somewhere in $PATH) is if at least
> > 
> > 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.
>
> Actually, we have word from Geoff Clare, who is authoritative on this
> matter, that the intention of POSIX was to standardise the pre-existing
> behaviour of ksh88.[*]
>
> As both Geoff and I have verified with our own copies of ksh88 (mine on
> a Solaris 10.3 VM), 'exec' on ksh88 always overlays the shell process
> with an external command using an exec*(2) syscall. It never runs a
> shell function or a builtin.

And since this is the same behavior as seen with a traditional Bourne Shell,
and ksh93, this is obviously the "right" method.

> Another fact is that pdksh was intended to be a clone of ksh88. Thus,
> pdksh failed to clone ksh88's 'exec' properly.

There are several deviations between mksh and ksh88. Some of them could 
definitely be seen as bugs.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Re: 'exec' runs shell functions and builtins

[Martijn Dekker]

Op 26-07-17 om 00:41 schreef Thorsten Glaser:
> Martijn Dekker dixit:
> 
>> This behaviour also appears to be contrary to the documentation in
>> mksh(1) ("The command is executed without forking, replacing the shell
>> process"). The test script below demonstrates that neither "exec"
> 
> And this is utter nonsense, the builtin does replace the shell process,

No. On mksh, 'exec builtin' is exactly equivalent to 'builtin; exit'.
The builtin is run in the existing shell process. No
replacing/overlaying of the shell process takes place. It's easy to
verify this in the source code.

- M.

Re: 'exec' runs shell functions and builtins

[Joerg Schilling]

Thorsten Glaser  wrote:

> Whether ?echo? is a builtin or not is an implementation detail.
> Heck, things like ?true?, ?false?, ? are (and others can be)
> implemented in some operating systems by symlinking them to the
> shell executable (either ksh93 *or* mksh? not even considering
> busybox).

echo was made a builtin in the early 1980s already for performance reasons.

true/false have been added by some shells to speed up "configure" ;-)

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Re: 'exec' runs shell functions and builtins

[Thorsten Glaser]

Robert Elz dixit:

>  | This specifically means that builtins MAY be made available
>  | to exec, and that thatbs an expected modus operandi.
>
>It means nothing of the kind.   The System Interfaces volume of POSIX.1-2008
>is the part that defines the system calls.

There’s no “exec” system call, so that’s the wrong part
you’re searching in for this.

>What the text you quoted is saying (if you had quoted it all) is that
>all of the built-in utilities (except the special built-ins) must be
>able to be accessed by execle(2) (and its sibling interfaces.)
>
>Note not may, must.

Yes, that *too*, but it also says that they *may* be builtins.

>Aside from the possibility that the sh exec special-builtin might be
>intended to make an exec*() system call (the spec does not say that)

Note that the exec built-in utility does not need to perfom
an exec*() system call.

>  | Heck, you can exec a function!
>
>That is where we started.   That is, that is the question.  Can you?

Of course you do, see the definition of “command” near the
top of the shell section.

bye,
//mirabilos
-- 
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”

Re: 'exec' runs shell functions and builtins

[Thorsten Glaser]

Martijn Dekker dixit:

>And under what theory should 'exec' run a shell function?

Read up on what a “command” can be, pretty far up in
the Shell part.

Although I did not manage to get a pipeline or loop run.
Not sure if that’s a bug, but looking at the way statements
are parsed, probably not.

bye,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy

Re: 'exec' runs shell functions and builtins

[Martijn Dekker]

Op 25-07-17 om 23:41 schreef Thorsten Glaser:
> Martijn Dekker dixit:
> 
>> This behaviour also appears to be contrary to the documentation in
>> mksh(1) ("The command is executed without forking, replacing the shell
>> process"). The test script below demonstrates that neither "exec"
> 
> And this is utter nonsense, the builtin does replace the shell process,

And under what theory should 'exec' run a shell function?

- M.

Re: 'exec' runs shell functions and builtins

[Thorsten Glaser]

Martijn Dekker dixit:

>to be a bug in POSIX terms; 'exec' is supposed to launch a program that
>overlays the current shell[2], implying the program launched by 'exec'
>is always external to the shell.

The built-in utility is “the program implementing command”,
and, with exec, it is not returning to the shell.

So, NO.

bye,
//mirabilos
-- 
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was disappointed that there is no makefile │ but somehow the Build.sh is
the least painful built system i've ever seen │ honours CC, {CPP,C,LD}FLAGS
properly │ looks cleary like done by someone who knows what they are doing

Re: 'exec' runs shell functions and builtins

[Thorsten Glaser]

Martijn Dekker dixit:

>This behaviour also appears to be contrary to the documentation in
>mksh(1) ("The command is executed without forking, replacing the shell
>process"). The test script below demonstrates that neither "exec"

And this is utter nonsense, the builtin does replace the shell process,

>replaces the shell process as the first executes a shell function and
>the second (within the function) executes a mksh builtin.

and you can even execute builtins by symlinking mksh to them,
try e.g. a symlink from mksh to print some day.

//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