The Exec Command

xaos52 · 2016-02-04 14:09:42

You might be interested in what the real bash gurus have to say about this.
When to use exec to replace the shell?

Horizon_Brave · 2016-02-04 17:16:47

johnraff wrote:

echo abc > $(grep xyz)
This is meaningless I'm afraid. $(command) is a string that encapsulates the standard output of command. You can't redirect anything to a string! It must be a file, or something that looks like a file and can hold the content you send to it.
Ah ok, so no matter what $(cmd) will always be a string with no real "value".

Now the >(command1;command2...) and <(command;more...) syntax: this is called process substitution and does look like a file to things that send (with > ) or receive (with < ) to/from it. See:
http://mywiki.wooledge.org/ProcessSubstitution
http://wiki.bash-hackers.org/syntax/exp … proc_subst

Thanks! So The first syntax of $(cmand) is an example of Command Substitution. And the second syntax of >(commands..) or <(commands) is process substitution... Sheesh..The Bash shell reminds me of my girlfriend..once you think you have her pegged down, she throws you a curve ball that leads you to re-comtemplating your life...

xaos52 wrote:

You might be interested in what the real bash gurus have to say about this.
When to use exec to replace the shell?

Equal thanks! The response in that thread by "bob", really helped!

Horizon_Brave · 2016-02-04 18:07:28

So just for completeness I'm going to post Bob Proulx's edited response here just to wrap this topic up.

Bob Proulx wrote:

"that isn't to say that there aren't good reasons to still use
exec to replace the current shell. Wrappers are one place. When NOT
using exec when you look through the 'ps -efH' listing you will see
each and every process. This is a good thing to do every so often.
It is possible that you will see some long list of processes that
surprise you for being there.
A wrapper that is purely transient to
set a few environment variables or whatever can justifiably exec the
real program. Why not? It saves some noise. It is arguably the most
correct thing to do. If you don't it probably won't break anything
however."
"It is a small point of resource optimization to replace the last
command in a shell script with an exec so that the resources used by
the shell are freed immediately. Not so important now. Still a
respectable thing to do. But just not very important now. But if the
behavior required is that the current shell is completely gone then
using exec to achieve the required behavior is still the correct thing
to do."

And the following is a really cool use case for exec, by Greg Woolege.

Greg Woolege wrote:

When you set up a service for daemontools to manage, you have to
create a program named "run" in a certain directory. This program
can be written in any language, but shell script is traditional.
It should execute your service, in the foreground, with no funky monkey
business. The daemontools service manager is the parent of your "run"
program/service, so it knows immediately when you exit, and it can launch
another instance of you automatically (unless you tell it not to).
In order for all of this to work, that parent/child relationship is
essential. If you write a shell script named "run" that simply executes
"/sbin/yourdaemon", then the service manager is the *grandparent* of
your daemon, instead of the parent. That means it can't monitor you.
It has no idea whether you're still running.
So, instead of simply executing yourdaemon, a run script must use exec.
Here's an actual example:
$ cat /service/ebase/run
#!/bin/sh
TCLLIBPATH=/opt/ebase5/lib
HOME=/home/ebase
export TCLLIBPATH HOME
cd "$HOME" || exit
exec setuidgid ebase /opt/ebase5/bin/ebased -foreground 2>&1
This same principle applies to runit, systemd unit files, etc. Of course,
systemd is a bloated mutant godzilla version of daemontools, and doesn't
use shell scripts, instead preferring its own custom configuration
syntax that you have to learn from ground zero... but the concept is
still the same.

Last edited by Horizon_Brave (2016-02-04 18:11:28)

tknomanzr · 2016-02-04 18:55:03

so if I run exec /bin/bash <somescript> in cron it will ditch the parent sh and simply execute my bash script? For example, I use an rsync script in cron to run scheduled backups. It is easy to tell when the cron job is running because sh will float up in my processes list in conky. However, being an rsync script it's not like portability is a major concern. I have always just created bash scripts to execute from cron so I don't have to muck about with sh and spawned the extra process.

Horizon_Brave · 2016-02-04 19:36:19

tknomanzr wrote:

so if I run exec /bin/bash <somescript> in cron it will ditch the parent sh and simply execute my bash script? For example, I use an rsync script in cron to run scheduled backups. It is easy to tell when the cron job is running because sh will float up in my processes list in conky. However, being an rsync script it's not like portability is a major concern. I have always just created bash scripts to execute from cron so I don't have to muck about with sh and spawned the extra process.

That's actually an interesting question... I'm going to try this is a few, if you put an exec command in a crontab job. Since it's cron that runs the command, would the exec kill cron...or kill bash?

tknomanzr · 2016-02-04 20:06:48

Cron actually executes its commands from /bin/sh, which is why this interests me.

Horizon_Brave · 2016-02-05 00:26:01

tknomanzr wrote:

Cron actually executes its commands from /bin/sh, which is why this interests me.

Hmm I couldn't get anything conclusive... I tried to add

exec /testscript.sh to the crontab file for it to run. IT looks like for crontab you can't pass it actual commands like exec /testscript.sh you can only pass it scripts directly. So I tried again with the exec command inside the testscript.
It worked, it ran the script, but the cron process never died. Doing a systemctl status cron showed that cron was still active and loaded, with an uptime of as long as my pc has been on. So I'm assuming the exec command in testscript, just killed testscript itself. Not sure how else to test this to see the effect of exec on cron...

#21 2016-02-04 14:09:42

Re: The Exec Command

#22 2016-02-04 17:16:47

Re: The Exec Command

#23 2016-02-04 18:07:28

Re: The Exec Command

#24 2016-02-04 18:55:03

Re: The Exec Command

#25 2016-02-04 19:36:19

Re: The Exec Command

#26 2016-02-04 20:06:48

Re: The Exec Command

#27 2016-02-05 00:26:01

Re: The Exec Command

Board footer