How to wait for a forked process in bash script

How to wait for a forked process in bash script

Post by Pepijn Kente » Sun, 09 Nov 2003 00:32:35



Hi All.

I'm sure this is a simple quiestion but I can't find the answer.

I'm running a the following bash script:

# program that generates pdf files
avgtool --v-axis-type=logarithmic *.avgfile
if [ $? -ne 0 ] ; then exit $error_in_avgtool ; fi

# program that generates pdf files
avgtool --v-axis-type=linear *.avgfile
if [ $? -ne 0 ] ; then exit $error_in_avgtool ; fi

# zip all pdf files
zip "avgfiles.zip" *.avgfile *.pdf
if [ $? -ne 0 ] ; then exit $error_in_zip ; fi

# end of script

When I look in the resulting zip file I find that 1 of the PDF files is
empty (size=0). My guess is that the programs are forked and the zipping
begins before the generation of the PDF files is finished.

Is this true? And if so, how can I prevent a command to start before the
previous is finished? I've searched the advanced bash scripting guide
and tried with the wait command and with 'and lists'.

Regards, Pepijn Kenter.

 
 
 

How to wait for a forked process in bash script

Post by Barry Margoli » Sun, 09 Nov 2003 00:44:16




Quote:>Hi All.

>I'm sure this is a simple quiestion but I can't find the answer.

>I'm running a the following bash script:

># program that generates pdf files
>avgtool --v-axis-type=logarithmic *.avgfile
>if [ $? -ne 0 ] ; then exit $error_in_avgtool ; fi

># program that generates pdf files
>avgtool --v-axis-type=linear *.avgfile
>if [ $? -ne 0 ] ; then exit $error_in_avgtool ; fi

># zip all pdf files
>zip "avgfiles.zip" *.avgfile *.pdf
>if [ $? -ne 0 ] ; then exit $error_in_zip ; fi

># end of script

>When I look in the resulting zip file I find that 1 of the PDF files is
>empty (size=0). My guess is that the programs are forked and the zipping
>begins before the generation of the PDF files is finished.

>Is this true? And if so, how can I prevent a command to start before the
>previous is finished? I've searched the advanced bash scripting guide
>and tried with the wait command and with 'and lists'.

Unless you put a command into the background with the "&" character, the
next command doesn't run until the previous one finishes.  It's possible
that avgtool forks a child process and the main process exits right away,
but this isn't likely; the only programs that typically behave this way are
daemons.

What happens if you run avgtool manually from the command line -- does the
prompt come back right away or does it wait for the command to finish?

In any case, if avgtool is forking a child, there isn't really a good way
for the shell to detect this.  It can only wait for its child processes,
not grandchildren.

--

Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

How to wait for a forked process in bash script

Post by Pepijn Kente » Sun, 09 Nov 2003 02:59:27


Quote:> Unless you put a command into the background with the "&" character, the
> next command doesn't run until the previous one finishes.  It's possible
> that avgtool forks a child process and the main process exits right away,
> but this isn't likely; the only programs that typically behave this way are
> daemons.

> What happens if you run avgtool manually from the command line -- does the
> prompt come back right away or does it wait for the command to finish?

> In any case, if avgtool is forking a child, there isn't really a good way
> for the shell to detect this.  It can only wait for its child processes,
> not grandchildren.

Thanks for your response.

The avgtool forks gnuplot and then pipes output to the gnuplot child.
When I invoke the avgtool on the command line the prompt waits for the
command to finish.

Pepijn.

 
 
 

How to wait for a forked process in bash script

Post by GROG » Sun, 09 Nov 2003 07:03:51



Quote:>> In any case, if avgtool is forking a child, there isn't really a good way
>> for the shell to detect this.  It can only wait for its child processes,
>> not grandchildren.

> The avgtool forks gnuplot and then pipes output to the gnuplot child.
> When I invoke the avgtool on the command line the prompt waits for the
> command to finish.

At work we have a similar problem with a print merge program, forking
subprocesses for multiple pages. We finally came up with a way of
using a utility called lsof to watch for any processes with open files
in the specific (separate) temp directory. Once there are none, then
we know the merge is finished and the parent script could continue.

Simply, the wait portion of the script is like this:

    childscript &
    while lsof +d /wrkdir | grep childscript > /dev/null 2>&1; do
        sleep 1;
    done
    [..continue on...]

HTH

--
GROG! \|/          Real programmers don't document; if it was hard

--oOO-(_)-OOo--    
EMAIL: grog [at] beevomit [dot] org

 
 
 

How to wait for a forked process in bash script

Post by Pepijn Kente » Tue, 11 Nov 2003 17:45:40




>>>In any case, if avgtool is forking a child, there isn't really a good way
>>>for the shell to detect this.  It can only wait for its child processes,
>>>not grandchildren.

>>The avgtool forks gnuplot and then pipes output to the gnuplot child.
>>When I invoke the avgtool on the command line the prompt waits for the
>>command to finish.

> At work we have a similar problem with a print merge program, forking
> subprocesses for multiple pages. We finally came up with a way of
> using a utility called lsof to watch for any processes with open files
> in the specific (separate) temp directory. Once there are none, then
> we know the merge is finished and the parent script could continue.

> Simply, the wait portion of the script is like this:

>     childscript &
>     while lsof +d /wrkdir | grep childscript > /dev/null 2>&1; do
>         sleep 1;
>     done
>     [..continue on...]

> HTH

I've got a similar solution now: I just sleep for half a second. This
works for me because once the parent is done executing, the child
process will terminate itself shortly.

Thanks, Pepijn Kenter.