Donald Sharp wrote:
> Have a control file that tracks directory names based on the
> original cvs invocation pid. The commitinfo script would
> write to this file the location of it's temp directory.
Where do you propose to keep the control file? How do you know what
cvs' original invocation pid is? If you can come up with a suitable
random answer (i.e. the name of a directory that won't stomp on some
already existing directory under heavy cvs or inetd load), then I don't
need all this PID stuff at all--or the control file, for that
matter--because wherever the control file would be written would itself
be a suitable place for all the scripts to communicate with one another.
The problem is that the usual bits that you'd use to ensure a random
tempdir/tempfile name aren't really available to you across scripts.
That is:
1. You might say that the control file should be kept in something like
/tmp/mastercontrol_$$. But of course the commitinfo's $$ is different
from the loginfo's $$, and there's no way to correlate them.
2. So you might say that the control file should be kept in something
like /tmp/mastercontrol_`date run through some filter`. But obviously
that's not random enough; multiple cvs commits would blow that one away.
3. You might say that the control file should be kept in something like
/tmp/mastercontrol_$parent_pid_via_getppid. But commitinfo's getppid()
is different from loginfo's getppid().
So the control file I don't think solves the problem as it's hamstrung
by the very same thing that I'm trying to solve. :-(
The hackish thing I'm leaning towards is parsing some ps -ef output,
armed with getppid (in the case of loginfo). That should let me figure
out what process it was that forked and execed, which would lead me back
to the correct temp directory. I figure this hit in performance should
be OK since the commit at this point has already happened and we're just
doing something with the log message.
Cheers,
Laird
