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