Hi,
On Sun, Sep 17 at 07:18, Terry Coles wrote:
> On Saturday, 16 September 2017 19:09:27 BST Bob Dunlop wrote:
> > exec rdate -v 192.168.0.2
>
> This only occurred to me last night. When I put the command into my script
> without preceding it with 'exec' it appears to work. According to the
> references I've found for exec, (including its man page), the command allows
> you to wrap the arguments of the target command so that the underlying code
> receives them correctly. My rdate command includes one switch and one
> argument, so how come it works without the exec prefix?
In this case the exec is entirely optional. Force of habit on my part
from years of working on tightly constrained machines. Exec is a shell
built in command so better often to check the particular shells man page.
Anyway the relevant part of the manual is "If command is specified, it
replaces the shell.". So when you run a command without the exec prefix the
parent shell creates a subshell clone of itself (an expensive operation),
then this subshell runs the command by exec'ing it. The exec prefix tells
the parent shell not to bother with the subshell creation but to directly
exec the target command itself.
The exec system call basically replaces the existing process (in this case
the shell or subshell) with the new target command (rdate) with the target
inheriting all the original processes resources including it's process ID.
The cost of that "creating a subshell clone" used to be really horrendous,
which was why BSD went to the trouble of creating the vfork() system call
in an attempt to reduce this overhead. The vfork man page has some
interesting history for people into kernel mechanics.
--
Bob Dunlop
--
Next meeting: Bournemouth, Tuesday, 2017-10-03 20:00
Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/
New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
