exec

exec

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

I've just recently come across 'exec' in a few scripts.  No familiarity 
with it.  Running this:

echo before exec
exec echo exec itself
echo after exec

... I find that whether in a script or a function it zaps the terminal 
and there's no such place as 'after exec'. What are the uses of that?  
For example the script that starts xfce4 'etc/xdg/xfce4/xinitrc' ends 
with this:

      exec xfce4-session

... so 'then what'?  Hard to put the question into words, but I have a 
sort of hanging feeling, I don't know where execution goes.  For that 
matter, neither do the xfce4 people know where it goes.  ( Micro rant: 
you have yer systemd and yer xdg and yer dbus and God knows what else 
all layered on top of each other and nobody knows what's actually 
happening.) The question arises cuz I want to run scripts both just 
before and just after an xfce4 session but nobody knows how that might 
be done.  Not our problem here of course, but if I had some insights 
into 'exec' it might help.  When, where and why do we 'exec' things?

[-- Attachment #2: Type: text/html, Size: 1418 bytes --]

Re: exec

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

The *exec* builtin replaces the running shell with whatever program you
run.  The point is to avoid clogging the process table with shells that are
just hanging out waiting to do nothing but exit as soon as their child
process finishes. It's like tail-call optimization in programming languages.

In UNIX, the system call version of exec(2) is how _any_ program is run.
Normally, when you type a command without the *exec* builtin in front of
it, the shell first makes a copy of itself, and then that copy replaces
itself with the program you want, using exec(2). Putting exec in front of
it just causes the shell to skip the make-a-copy step and replace itself
right away.

In your case, the script exists to set things up in the environment and
then run xfce4-session; there's nothing for it to do after xfce4-session
completes, so it uses *exec* to tidy up.


On Mon, Jun 3, 2024 at 10:11 AM Ray Andrews <rayandrews@eastlink.ca> wrote:

> I've just recently come across 'exec' in a few scripts.  No familiarity
> with it.  Running this:
>
> echo before exec
> exec echo exec itself
> echo after exec
>
> ... I find that whether in a script or a function it zaps the terminal and
> there's no such place as 'after exec'. What are the uses of that?  For
> example the script that starts xfce4 'etc/xdg/xfce4/xinitrc' ends with this:
>
>      exec xfce4-session
>
> ... so 'then what'?  Hard to put the question into words, but I have a
> sort of hanging feeling, I don't know where execution goes.  For that
> matter, neither do the xfce4 people know where it goes.  ( Micro rant: you
> have yer systemd and yer xdg and yer dbus and God knows what else all
> layered on top of each other and nobody knows what's actually happening.)
> The question arises cuz I want to run scripts both just before and just
> after an xfce4 session but nobody knows how that might be done.  Not our
> problem here of course, but if I had some insights into 'exec' it might
> help.  When, where and why do we 'exec' things?
>
>

-- 
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 2977 bytes --]

Re: exec

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]



On 2024-06-03 07:17, Mark J. Reed wrote:
> The *exec* builtin replaces the running shell with whatever program 
> you run.  The point is to avoid clogging the process table with shells 
> that are just hanging out waiting to do nothing but exit as soon as 
> their child process finishes.
I get that.

>
> In your case, the script exists to set things up in the environment 
> and then run xfce4-session; there's nothing for it to do after 
> xfce4-session completes, so it uses *exec* to tidy up.

Sure.  But then what? I understand that if a script or function has 
nothing more to do, it may as well pre-kill itself. But the difference 
is that 'exec' kills the entire terminal, it doesn't just return to the 
prompt in a more efficient way -- which would be easy to understand, as 
above.  exec seems to pull the rug out from under itself, not just end a 
script more efficiently.  In my case, from what I've heard control seems 
to pass to dbus.  Mind, if dbus called the script then that's what one 
might expect.


[-- Attachment #2: Type: text/html, Size: 1884 bytes --]

Re: exec

[Eric Cook]

On 6/3/24 10:42 AM, Ray Andrews wrote:
>
>
> On 2024-06-03 07:17, Mark J. Reed wrote:
>> The *exec* builtin replaces the running shell with whatever program you run.  The point is to avoid clogging the process table with shells that are just hanging out waiting to do nothing but exit as soon as their child process finishes.
> I get that.
>
>>
>> In your case, the script exists to set things up in the environment and then run xfce4-session; there's nothing for it to do after xfce4-session completes, so it uses *exec* to tidy up.
>
> Sure.  But then what?
nothing, the process was replaced with xfce-session.

  I understand that if a script or function has nothing more to do, it may as well pre-kill itself. But the difference is that 'exec' kills the entire terminal, it doesn't just return to the prompt in a more efficient way
How would it return to the prompt of a shell/process that was replaced with another process?

when you have a `terminal -> shell' and you run exit/^D the terminal no longer has a child process and exits.
when you have a `terminal -> shell that does exec -> utility' and utility exits, the terminal no longer has a child process and exits.

Re: exec

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

The shell is gone. Once the program you executed is finished, there's
nothing left for you to type at. Eahat's the terminal supposed to do with
nothing running in it anymore? You can configure it to hang around so you
can see the last thing output by the last thing to run in it...

 Exec has the same impact on the shell as exit - shell go bye bye - it just
leaves another program in its place.

Mark J. Reed <markjreed@gmail.com>


On Mon, Jun 3, 2024 at 10:42 Ray Andrews <rayandrews@eastlink.ca> wrote:

>
>
> On 2024-06-03 07:17, Mark J. Reed wrote:
>
> The *exec* builtin replaces the running shell with whatever program you
> run.  The point is to avoid clogging the process table with shells that are
> just hanging out waiting to do nothing but exit as soon as their child
> process finishes.
>
> I get that.
>
>
> In your case, the script exists to set things up in the environment and
> then run xfce4-session; there's nothing for it to do after xfce4-session
> completes, so it uses *exec* to tidy up.
>
>
> Sure.  But then what? I understand that if a script or function has
> nothing more to do, it may as well pre-kill itself. But the difference is
> that 'exec' kills the entire terminal, it doesn't just return to the prompt
> in a more efficient way -- which would be easy to understand, as above.
> exec seems to pull the rug out from under itself, not just end a script
> more efficiently.  In my case, from what I've heard control seems to pass
> to dbus.  Mind, if dbus called the script then that's what one might
> expect.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2717 bytes --]

Re: exec

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 2711 bytes --]

On Mon, Jun 3, 2024 at 10:54 AM Mark J. Reed <markjreed@gmail.com> wrote:

> Eahat's the terminal supposed to do with nothing running in it anymore?
>

That was a rather creative typo for "What" at the start of that question. :)


>  Exec has the same impact on the shell as *exit* - shell go bye bye - it
> just leaves another program in its place.
>

In your tests, that other program is *echo*. Since that's a builtin, things
are a little different. In bash or ksh, *exec* only works on external
programs, so if you type *exec echo*, you'll be running */bin/echo* or
*/usr/bin/echo* (or wherever the binary lives) instead of the shell
builtin. But in Zsh, *exec*'ed builtins are still builtins; the shell
simulates the effect of *exec* by exiting after it executes the builtin
command. So *exec echo whatever* is just a shorter way of writing *echo
whatever; exit*.

But if you *exec* an external program that takes a while to run, say *exec
sleep 300*, then you can run *ps *in another window and see that the shell
from which you launched the *sleep* is no longer there; the *sleep* has
replaced it. In fact, you can see that the process ID formerly belonging to
it has been taken over:

Window 1:

*zsh% echo $$*
*42566*
*zsh% exec sleep 300*


Window 2:

*zsh% ps -fp42566*

*UID   PID  PPID   C STIME   TTY           TIME CMD*
*  501 42566 42383   0 11:05AM ttys003    0:00.11 sleep 300*



> Mark J. Reed <markjreed@gmail.com>
>
>
> On Mon, Jun 3, 2024 at 10:42 Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>>
>>
>> On 2024-06-03 07:17, Mark J. Reed wrote:
>>
>> The *exec* builtin replaces the running shell with whatever program you
>> run.  The point is to avoid clogging the process table with shells that are
>> just hanging out waiting to do nothing but exit as soon as their child
>> process finishes.
>>
>> I get that.
>>
>>
>> In your case, the script exists to set things up in the environment and
>> then run xfce4-session; there's nothing for it to do after xfce4-session
>> completes, so it uses *exec* to tidy up.
>>
>>
>> Sure.  But then what? I understand that if a script or function has
>> nothing more to do, it may as well pre-kill itself. But the difference is
>> that 'exec' kills the entire terminal, it doesn't just return to the prompt
>> in a more efficient way -- which would be easy to understand, as above.
>> exec seems to pull the rug out from under itself, not just end a script
>> more efficiently.  In my case, from what I've heard control seems to pass
>> to dbus.  Mind, if dbus called the script then that's what one might
>> expect.
>>
>>
>>

-- 
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 5356 bytes --]

Re: exec

[Ray Andrews]

On 2024-06-03 07:54, Mark J. Reed wrote:
>  Exec has the same impact on the shell as exit - shell go bye bye - it 
> just leaves another program in its place.

So I see.  So it's not just a question of a script removing itself from 
memory at the point where control passes, it's 'exit' as we see.  Still, 
the question of who gets control is there -- the computer does not shut 
off.  But again, that question would be there anyway so 'exec' doesn't 
make the question any more difficult.  I guess as far as zsh is 
concerned that's as much as can be said.

Re: exec

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

*exec* by exiting after it executes the builtin command. So *exec echo 
whatever* is just a shorter way of writing *echo whatever; exit*.

Ok, that's clear.  Polite of zsh to be consistent there.  If one types 
'exec' then one wants exec to do what it does, so treat all commands the 
same.

[-- Attachment #2: Type: text/html, Size: 505 bytes --]

Re: exec

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

Your shell is never the only process running on the computer. Certainly not
if you're using a GUI; the terminal emulator is running, to carry what you
type to the shell and what it outputs back to you. The window system is
running, to display what the terminal emulator and other windows have to
say and respond to the keyboard and mouse and so on.  When the shell exits,
the terminal may also (as I said, that's configurable), but there's no
reason for everything else to. You can just fire up another terminal and
keep going, or continue to interact with non-command-line applications like
your web browser.

In X11 setups back in the day, it wasn't uncommon for the *.xinitrc* or
whatever startup file you use to end with something like *exec xterm*, so
if *that particular instance* of *xterm* exited, then the whole window
system went away with it. But that's not typical of modern systems. And
even then the computer wouldn't shut down. You'd just be dropped back at
your original shell on the console, or if you'd also *exec*'ed *xinit*, at
a login prompt.

On Mon, Jun 3, 2024 at 11:23 AM Ray Andrews <rayandrews@eastlink.ca> wrote:

>
>
> On 2024-06-03 07:54, Mark J. Reed wrote:
> >  Exec has the same impact on the shell as exit - shell go bye bye - it
> > just leaves another program in its place.
>
> So I see.  So it's not just a question of a script removing itself from
> memory at the point where control passes, it's 'exit' as we see.  Still,
> the question of who gets control is there -- the computer does not shut
> off.  But again, that question would be there anyway so 'exec' doesn't
> make the question any more difficult.  I guess as far as zsh is
> concerned that's as much as can be said.
>
>
>
>

-- 
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 2451 bytes --]

Re: exec

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]



On 2024-06-03 08:33, Mark J. Reed wrote:

> In X11 setups back in the day, it wasn't uncommon for the *.xinitrc* 
> or whatever startup file you use to end with something like *exec 
> xterm*, so if /that particular instance/ of *xterm* exited, then the 
> whole window system went away with it. But that's not typical of 
> modern systems. And even then the computer wouldn't shut down. You'd 
> just be dropped back at your original shell on the console, or if 
> you'd also *exec*'ed *xinit*, at a login prompt.
Exactly.  My point was rhetorical -- obviously control resumes 
'somewhere' in the stack of all these GUI functions.  But it isn't easy 
to figure out where.  I even tried this:

   # start xfce4-session normally
touch /aMisc/"$(date +%F--%T)-starting xfce"
#    exec xfce4-session
     xfce4-session
touch /aMisc/"$(date +%F--%T)-stopping xfce"

... just to see if I could get some sense of flow control, but it 
doesn't work.  I never get to 'stopping'.  It feels wrong.

[-- Attachment #2: Type: text/html, Size: 1611 bytes --]

Re: exec

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

On Mon, Jun 3, 2024 at 8:34 AM Mark J. Reed <markjreed@gmail.com> wrote:

> Your shell is never the only process running on the computer.
>

 If you're using some variant of Linux (doesn't typically work on e.g.
macOS),

% pstree -s $$

will show you what's going on.  You might also try

% pstree -h

to see your process highlighted in context of everything on the system.

[-- Attachment #2: Type: text/html, Size: 795 bytes --]

Re: exec

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]



On 2024-06-03 09:06, Bart Schaefer wrote:
> On Mon, Jun 3, 2024 at 8:34 AM Mark J. Reed <markjreed@gmail.com> wrote:
>
>     Your shell is never the only process running on the computer.
>
>
>  If you're using some variant of Linux (doesn't typically work on e.g. 
> macOS),
>
> % pstree -s $$
>
> will show you what's going on.  You might also try
>
> % pstree -h
Holy Cow.  Now, if I could log that during a shutdown I'd have the whole 
thing in glorious tree format.  What a fantastic command.

[-- Attachment #2: Type: text/html, Size: 1639 bytes --]