[MUD-Dev] Mail from mud Zoran's final Imp

[Shawn Halpenny]

On Tue, 6 Jan 1998, JC Lawrence wrote:

> On Fri, 2 Jan 1998 11:12:08 PST8PDT 
> Shawn Halpenny<malachai at iname.com> wrote:
> 
> > On Thu, 1 Jan 1998 coder at ibm.net wrote:
> 
> >> [ catch SIGCHLD from the spawned mailing process to snag errors ]
> 
> > Isn't it easier to check the return value from system(), since the
> > wait() call inside system() is already waiting for the child to
> > exit?  Checking whether it exited successfully, failed because of
> > something user-controllable, or died on some nasty signal is where
> > the WIFxxxx macros come in handy (see /usr/include/sys/wait.h).
> > Since you're using system() instead of doing the fork() and exec()
> > yourself, remember that there can be a difference in the returned
> > status if it was the shell that was abnormally terminated instead of
> > the command process.
> 
> Bugger, I forgot the WIF* macros.
> 
> Note: You're going to need to do either a fork()/system()/exit() or a
> fork()/exec()/exit(), and it really doesn't matter which except that
> the latter is cheaper on page space.  Either way you need the fork
> such that the main process doesn't have to wait for the child.

Certainly.  In a similar vein, what about having a completely separate
daemon (a separate, standalone process, associated with the MUD only by its
method of communication--it was never a child process of the MUD)
who reads a socket (or FIFO, etc.) for commands to be executed and in
similar fashion reports back the results.  No forking necessary in the MUD at
all for this to work, and the daemon can be quite compact (all it must do
is fork()/exec()/exit() with the command given to it over the comm
channel).  If executing system commands is something that one must do
fairly often, would this be a more efficient approach?

--
Shawn