Looking for alternate to the “exec” command

[Raymond E. Lilly]

I have two procedures that must run synchronously and want to execute them both in a single shell script. The procedures themselves run with the “exec” command. By design, “exec is executed in place of this shell without creating a new process”. In other words, the second procedure will not run if I use “exec”. Can someone suggest a way to avoid this without creating multiple scripts?

[James R. Ferguson]

HI:

Run each process in the background:

#!/usr/bin/sh
process1 &
PID1=$!
process2 &
PID2=$!
...

The shell special vairable '$!' is the PID of the last process placed in the background. See the 'sh-posix' manpages for more information.

Regards!

...JRF...

[James R. Ferguson · Accepted solution]

Hi (again):

Perhaps this example will help:

# cat ./proc.sh
#!/usr/bin/sh
./proc_1 &
PID1=$!
./proc_2 &
PID2=$!
echo "...two processes started -- ${PID1} ${PID2}"
wait ${PID1}
echo "process-1 ${PID1} done with rc=$?"
wait ${PID2}
echo "process-2 ${PID2} done with rc=$?"

# cat ./proc_1
#!/usr/bin/sh
sleep 20
exit 1

# cat ./proc_2
#!/usr/bin/sh
sleep 10
exit 0

# ./proc.sh
...two processes started -- 14061 14062
process-1 14061 done with rc=1
process-2 14062 done with rc=0

...That is, you can do synchronous work; wait for all processes to terminate; and interrogate the return code of each process when it terminates.

Regards!

...JRF...

[Steven Schweda]

> I have two procedures [...]

Define "procedures". Shell scripts?

I'm confused (which is not unusual). Can you
supply a test case? I'd expect any program
or script which is run by a top-level shell
script to get its own process to wreck. I
would not expect it to wreck its parent
process. Now, if you did
. script2
instead of (plain)
script2
then _that_ could cause trouble if "script2"
contained an "exec" (because then it would
not be run in its own process).

[Raymond E. Lilly]

Tried to be brief, let me clarify the situation if I can;

I'm using the exec command in a shell script. The script starts a database client connection which runs a batch job. The command line in the script looks like this: exec $PATH/bin/_prog (plus all the stuff required to run the batch against a specific database).

file _prog
_prog: ELF-64 executable object file - PA-RISC 2.0 (LP64)

existing script:
- set a path, term and environment variables
- change to a working directory
- exec $PATH/bin/_prog (launch db client connection for processing batch_A)

modification I wish to achieve:
- set a path, term and environment variables
- change to a working directory
- exec $PATH/bin/_prog (launch db client connection for processing batch_A)
-- validate results of batch_A
-- conditionally run exec $PATH/bin/_prog (launch db client connection for processing batch_B)

The script never gets to the validation step since exec launches in the current process. According to the man pages on my system it looks like this is the expected behavior:

man exec

The exec*() system calls, in all their forms, load a program from an ordinary, executable file into the current process, replacing the current program.


I've tested the same script without the exec command ($PATH/bin/_prog instead of exec $PATH/bin/_prog) and the script completes. This proves the issue is the exec command AND that I should verify dropping the exec command as a solution with our application provider. So far I have not discovered any adverse affects. I'd still like to find a shell scripting solution that allows the use of the exec command and satisfies my end to start dependency.

[James R. Ferguson]

Hi (again):

> ...I should verify dropping the exec command as a solution with our application provider. So far I have not discovered any adverse affects. I'd still like to find a shell scripting solution that allows the use of the exec command and satisfies my end to start dependency.

I showed you how to start multiple processes in a shell script and wait() for their completion. This is probably the simplest way to create synchronous processes and control/wait/test their execution. Have you evaulated my suggestion as originally posted?

Regards!

...JRF...

[Raymond E. Lilly]

Yes, I did evaluate your suggestion. It's a winner! Turns out that all I needed to understand was that running exec in a background process trumps it's default behavior to load a program into the current process, replacing the current program.

I rearranged your examples to meet my needs:
# cat ./proc.sh
#!/usr/bin/sh
exec ./proc_1 &
PID1=$!
wait ${PID1}
echo "process-1 ${PID1} done with rc=$?"
if [ $? -eq 0 ]
then
exec ./proc_2 &
PID2=$!
wait ${PID2}
echo "process-2 ${PID2} done with rc=$?"
else
exit
fi

Excellent solution. Thanks!

[Patrick Wallek]

I'm not sure why you insist on using the 'exec' in this script. To me it does not make any sense.

Why not simplify and just do:

I rearranged your examples to meet my needs:
# cat ./proc.sh
#!/usr/bin/sh
./proc_1
echo "process-1 done with rc=$?"
if [ $? -eq 0 ]
then
./proc_2
echo "process-2 done with rc=$?"
else
exit
fi

The 'exec' and 'wait' seem superfluous in this context since you just want to make sure proc_1 completes with RC=0 before starting proc_2.

[James R. Ferguson]

Hi (again) Ray:

I'm glad to have helped.

You do _NOT_ need to 'exec' the process at all. It is much clearer to the reader of your script if you don't. Simply do:

./proc_1 &

...as I originally showed. RUnning in the background enables you to spawn mutliple processes synchronously.

Regards!

...JRF...

[Raymond E. Lilly]

Thanks to all who responded.

[Raymond E. Lilly]

.