#!/usr/bin/perl
#this file test the hypothesis that multiple copies of the script "d.pl" were running.   This is unlikely to cause a real image to be replaced by a zero byte image.
#It runs the script hyp2.pl and passes a command line argument that sleeps for $ARGV[0] seconds instead of taking a picture.   Thus we have
#run first copy sleeping for X seconds in the background
#sleep for Y seconds
#run second copy sleeping for Y seconds.  

#we'll se what happens
printf("Starting job 1\n");
`./hyp2.pl $ARGV[0]&`;
printf("Sleeping for %d secs\n",$ARGV[1]);
`sleep $ARGV[1]`;
printf("Starting second job\n");
`./hyp2.pl $ARGV[2]`;

#The output doesn't show up as there is a level of indirection.  Here is what happens.  When this script is called like ./hyptest1.pl 30 10 1 
# it calls the first one which takes a picture (lets assume correctly, with sync).
# then it waits 30 seconds to model the time it takes to write the picture.
# during that time (approx 10 seconds later), the second version runs, this time with no delay to model the camera.
# It will immediatly convert whatever is in pork.ppm into the jpegs, which if pork.ppm is zero bytes, are zero byte images.  It will try to grab the same number as the first script.
# At the end of the conversion (which is quick, particularly for zero byte files, it will erase pork.ppm.  
# Thus the net effect is to erase pork.ppm at some point through the process.
# What happens here depends on a few things.  If nothing has been written yet, this will have no effect.  The new changes in the script however, will lock out the other process from writing to the same location, so in this case the making of output files read only is BAD.
#If a partial output was done, then the program ppm2all.c will give an error message since it was unable to read enough bytes.  Then a zero byte output file would be generated.  However, an error message would appear on the screen, and zgv would not display an image.
# If it is done writing (an extremmely unlikely scenario), they will operate on the same data, and weird things would start happening.  It is possible the first script could finish, and then the second would mess things up as it didn't finish reading, but that requires the computer to run zgv before it does a context switch to the second script. 
#CONCLUSION
# So the conclusion is: It is unlikely that two copies of the script caused this problem.  This is supported by the fact that it was very cold, and the operator was trying to type as little as possible.  When I was present (TB), no one was changing consoles.
# As well, the operator would have to ignore two error messages, and not notice that no image was displayed.  Because the second copy would run so much faster (except possibly for the third case discussed right above the conclusions), it is virtually impossible for the image to be overwritten.  For it to happen five times is severly unlikely as the operator would have too, five times, run the script twice during a good picture.