exit value (MORE INFO)
Richard van de Stadt
stadt at cs.utwente.nl
Wed Nov 14 20:08:34 AEST 1990
With this posting I want to explain with an example why I want to know
the exit value of a process that was started in background. From reactions
of some of you (thank you very much) I understand that the question was a
bit vague.
First of all I'm not a newcomer to UNIX (know it since 1983).
I didn't ask how to get an exit value of a process, because I already
know that's in $?. I also know that the process id of the last process
started in background is in $!.
When I worked at Philips Telecomunication and Data Systems, one of my
tasks was system management of some Philips P9000 computers.
For a 'normal' user it was rather complicated to format a floppy disk,
so I wanted to write a shell script to automate the various actions.
In order to get a floppy formatted the following had to be done:
For floppies that were previously formatted it was straightforward:
One had to insert a floppy disk and then type the commands
'attent /dev/dk1' to let the system get the name of the floppy,
'dvstat /dev/dk1' to see what the name of the floppy was,
'dkformat /vol/<name_of_floppy>' to start the format process.
(Once tape and disknames are known to the system, they are called volumes,
and their names used as references).
So all commands could be started after each other in foreground. From the
output of dkformat one could see if the process had ended successful. Also
$? contained a value not equal to zero if something went wrong.
The trouble comes when you want to format a new ('maiden') floppy.
After inserting a new floppy, the format command had to be entered first,
since 'attent /dev/dk1' does not work for floppies that have no name yet:
'dkformat -m /vol/<new_name>' (m for maiden).
The format command then waits for the 'attent /dev/dk1' command to be entered,
after which the format process is really starting.
If you have only one terminal, where only one command shell can be active,
you have to start dkformat in the background, to be able to enter
'attent /dev/dk1'.
If you build a script around this you want to know if the process has
finished correctly. Started by hand, one could see if the format process
had ended correctly by looking at the output messages given.
I wanted to write a script that tells a user to insert a floppy, press
return after doing so. Then starting up the format process (in background)
and exit, so the user can go on doing other things. After the format process
is ready a message is shown on the screen whether the floppy has been
formatted successfully or unsuccessfully.
So what I wanted was something like:
-------------------------------------------------------------------------
#! /bin/sh
#name of script: floppyformat
doit () { # a function
attent /dev/dk1 #find out if -m option must be used (new floppy)
case $? in
0) # not a new floppy
dkformat /vol/name_of_floppy >/dev/null 2>&1 #no output on screen
exitval=$?
break ;;
*) # a new floppy
dkformat -m /vol/new_name >/dev/null 2>&1 & #no output on screen
sleep 10 # be sure process is started
# actually done by looping on pid
attent /dev/dk1 # give what dkformat is waiting for
wait # wait for format process to have finished
exitval='exit_value_of_last_process_started_in_background' ;;
esac
case $exitval in
0) echo "Floppy was formatted successfully" ;;
*) echo "<beep>Format process failed. Try other floppy"
esac
} # end of function
echo -n "Insert floppy and press return "
read return
doit & #start format process in background and exit immediately
------------------------------------------------------------------------
I went around the problem by redirecting the output of dkformat to a
temporary file and later searching this file for some specific string
that indicated that the format process had been successful.
The script above is not the original, since it's been a bit too long
to remember all the details. It's the idea what it't about.
Hope things are a bit clearer now
Richard
--
R.R. van de Stadt (Richard)
Email: stadt at cs.utwente.nl
More information about the Comp.unix.questions
mailing list