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

[BUG] 'exec' runs shell functions and builtins

[Martijn Dekker]

In mksh (and pdksh), 'exec' looks up shell functions and builtins before
external commands, and if it finds one it appears to do the equivalent
of running the function or builtin followed by 'exit'. This turns out[1]
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.

This means that
(exec commandname arguments ...)
is a POSIXly correct way of guaranteeing the execution of an external
command without specifying the path.

In pdksh this is definitely a bug as this behaviour differs from ksh88
which pdksh is supposed to be a clone of. The POSIX spec is also based
on ksh88 behaviour.

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"
replaces the shell process as the first executes a shell function and
the second (within the function) executes a mksh builtin.

testFn() {
exec print "this shell execs both functions and builtins"
}
PATH=/dev/null
exec testFn

Expected output: something like "testFn: not found".
Actual output: "this shell execs" etc.

- M.

[1] https://www.mail-archive.com/austin-group-l@opengroup.org/msg01469.html

[2]
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_20_14