Running commands synchronously from a Unix program
John R Ramsden
but in a Unix program how easy is it to run another external
command (i.e. not "time" or some command run by the shell),
and then have the calling program wait for its completion
rather than soldiering on as it would after, say, forking?
In fact, is this what system() or one of the exec() family
of calls does anyway? Maybe I should try some experiments
instead of bothering readers here. But it's too late now,
I've typed the message :-)
Cheers
---------------------------------------------------------------------------
John R Ramsden (j...@redmink.demon.co.uk)
---------------------------------------------------------------------------
The new is in the old concealed, the old is in the new revealed.
St Augustine.
---------------------------------------------------------------------------
Ken Pizzini
>I hope this question isn't insultingly easy or in the FAQ,
>but in a Unix program how easy is it to run another external
>command (i.e. not "time" or some command run by the shell),
>and then have the calling program wait for its completion
>rather than soldiering on as it would after, say, forking?
Strange choice of newsgroups. May I recommend
comp.unix.programmer for future questions in this
vein?
Anyway...
>In fact, is this what system() or one of the exec() family
>of calls does anyway?
The exec() family replaces the currently running process with
the processed named in the exec() arguments. So from the
perspective of the program calling exec(), there is no
opportunity to wait for the newly started program to finish,
because the instance of the program calling exec() ceases to
exist. This is the only way a new program gets started in unix,
but by itself I don't think that it matches what you're asking
for.
The fork() call clones the currently running process into two
almost identical copies which run independently of each other.
This is the only way a new process gets started in unix, but
again, taken in isolation, does not seem to be what you're after.
(Incidentally, I would like to emphasise the distinction drawn
between "program" and "process" in each of the final sentences
of those two paragraphs.)
The system() function internally does a fork() and then the
child branch of the fork() does an exec(). The parent branch of
the fork() immediately calls one of the wait() family of calls
to await the completion of the child process. So, if I
understood your question properly, system() would be one
reasonable way of making a synchronous call to an external
program. It is not completely synchronous though --- there is
the breif interval between the fork() and the parent's call to
wait() where both processes are potentially running in parallel,
but it's pretty darn close to synchronous.
Anyway, the triad described above for the system function ---
fork()/exec*()/wait*() --- is the crux of any mechanism for
starting off a new external program and awaiting its completion.
It is what the shell does when you type a foreground command.
When you run a background command from the shell it merely omits
the wait(). When you "wait" for a background process to finish,
the shell then does the wait() that it earlier omitted.
(And now, in a futile attempt to make this at least a little
on-topic for comp.unix.shell...)
In fact, you can find each of the three components are available
seperately in the shell, even though the default behavior
(running a process in the foreground) is to use all three of the
triad:
fork a new copy of the current shell instance: parenthesis
exec a new program, replacing the current shell: "exec"
wait for a previously fork'd process to complete: "wait"
--Ken Pizzini
John R Ramsden
>
> John R Ramsden <j...@redmink.demon.co.uk> wrote:
> >
> > I hope this question isn't insultingly easy or in the FAQ,
> > but in a Unix program how easy is it to run another external
> > command (i.e. not "time" or some command run by the shell),
> > and then have the calling program wait for its completion
> > rather than soldiering on as it would after, say, forking?
>
> Strange choice of newsgroups. May I recommend
> comp.unix.programmer for future questions in this
> vein?
Yes I thought c.u.shell was borderline, although c.u.sco.programmer
seemed reasonable. But I'll certainly take your advice for general
Unix questions in future. (contd)
> > In fact, is this what system() or one of the exec() family
> > of calls does anyway?
>
> The exec() family replaces the currently running process with
> the processed named in the exec() arguments.
I had a feeling that was the case. So in effect exec "overlays"
the calling program (albeit perhaps running in a new process).
That's definitely not what I'm after.
> The fork() call clones the currently running process into two
> almost identical copies which run independently of each other.
> This is the only way a new process gets started in unix, but
> again, taken in isolation, does not seem to be what you're after.
Not this time.
> The system() function internally does a fork() and then the
> child branch of the fork() does an exec(). The parent branch
> of the fork() immediately calls one of the wait() family of
> calls to await the completion of the child process.
Aha! So system() is certainly the function I should use.
Anyway, very many thanks for your prompt and helpful reply Ken.
I would have RTFM, honest, but I'm working at a customer site,
far from any decent bookshop, where (a) any manuals have long
since been lost or stolen and (b) some over-zealous SA deleted
the relevant man pages to save a few Mbytes; so this hasn't
been an easy option.
P.S. All I need to figure out now is how to contact an inetd
Daemon on Unix from a Windows VB program (an Excel VB macro).
I wonder what group would be best to ask for help with that?
Ken Pizzini
>k...@halcyon.com (Ken Pizzini) wrote:
>> Strange choice of newsgroups. May I recommend
>> comp.unix.programmer for future questions in this
>> vein?
>
>Yes I thought c.u.shell was borderline, although c.u.sco.programmer
>seemed reasonable.
True, c.u.s.p isn't _too_ far fetched, but the question had
nothing SCO-specific about it. C.u.shell seemed very odd
though, given that your question related to C programming in
a unix environment.
>> The exec() family replaces the currently running process with
>> the processed named in the exec() arguments.
>
>I had a feeling that was the case. So in effect exec "overlays"
>the calling program
Yes.
> (albeit perhaps running in a new process).
Only if you called fork() first.
>P.S. All I need to figure out now is how to contact an inetd
>Daemon on Unix from a Windows VB program (an Excel VB macro).
>I wonder what group would be best to ask for help with that?
Depends on what the problem you are having is. If it's a
problem with inetd not responding properly then some comp.unix
newsgroup is indicated; if the problem is with programming VB to
make the connection then either the appropriate comp.lang or
comp.os.ms-windows group is indicated. If it really isn't clear
which one is the problem, ask a unix group for help debugging
your inetd spawned program and a VB and/or Windows group for
help on the VB app and the Windows networking setup.
--Ken Pizzini
comp.lang.basic.visual.misc
comp.os.ms-windows.networking.tcp-ip
comp.os.ms-windows.programmer.networks
comp.os.ms-windows.programmer.win32
comp.unix.admin
comp.unix.programmer