To John, Dan, Rusty -- Thanks very much for your help. In this case,
directing output to an interim file gave different results than piping it
all in one line, but trying it led me to the answer. I believe the
ambiguity is in which of the processes involved in the pipes have been
started in time for ps to catch them.
The following seems to work reliably:
temp=`ps -ef`
if [ `echo $temp | grep -c $0` -gt 1 ] ; then
echo "another is running"
else
echo "all alone"
fi
thanks again
karl
At 10:02 AM 4/9/2001 -0700, you wrote:
>Well, the first thing folks should do when trying to figure out what's
>going on in a script is capture the output and see whats going on.
>
>So, for example, one might do this:
>
>cnt=0
>while [ $cnt -lt 70 ] ; do
> ps -ef | egrep -v grep > /tmp/debug.1.$$
> grep $0 /tmp/debug.1.$$ > /tmp/debug.2.$$
> echo -n `wc -l /tmp/debug.2.$$`
> let cnt+=1
>done
>echo
>
>Then go look at the files and see that sometimes you'll catch
>things like:
>
> emacs myscript
> ./myscript
> vi myscript.info
>
>(as a dumb, contrived example)
>
>In my experience, you must be very careful when grepping for command
>lines - especially if they are scripts being executed, since all too
>often you also happen to have that script open in the editor!
>
>
>One thing I've seen is where the script saves its pid in a file,
>which you then check for. Of course, you have to watch for the
>critical section there (and there is no easy way to get rid
>of it entirely, so you just have to do the best you can) (Huh?
>What critical section??? (or, What's a critical section?) see
>below) Another option would be to make a server that would
>keep track of things like that and answer the question
>'Am I the only one of me wanting to run?' - but that seems like
>a LOT of work.... Easiest thing is probably just to try to make
>sure you don't run the script TOO often (10 times in a minute
>would be a bad idea ;-), and do a 'simple' check like we've been
>discussing.
>
>
>Ok, so what's a critical section? Its a section of code (usually)
>that, if you have 2 separate threads of control execute that code
>at the same time the results can (might) be erroneous. One of the standard
>examples is : static int i; crit_sec_oops(int addme){ int j; j=i + addme;
>i=j;}
>
>Now, if thread 1 comes through, calculates the sum, then thread 2 comes
>along, caluclates the sum AND manages to store it back into i, then
>thread 1 continues along and stores ITS version into i - you just lost
>thread 2's contribution to i.
>
>Trying to have a file as your locking means leaves you a critical
>section also, but we'll leave that as an exercise for the student ;-)
