Why can't you just go through the process of getting the pid twice?
For example:
donsharp-u5:350> /bin/ps -ef | grep 13059
sharpd 13059 5569 0 10:00:33 pts/11 0:00 gnut
donsharp-u5:351> /bin/ps -ef | grep 5569
sharpd 5569 5568 0 Jul 31 pts/11 0:00 csh
sharpd 13120 7974 0 10:07:37 pts/4 0:00 grep 5569
sharpd 13059 5569 0 10:00:33 pts/11 0:00 gnut
gnut's pid is 13059. It's parents pid is 5569. 5569 parents pid
is 5568( csh ).
Do a ps and search the output. I'm willing to bet there's already
a perl cpan module that can do this...
Why wouldn't this work?
Keep the control file in a well known location /tmp
might be fine. But I would actually think about creating
a special directory just for cvs to place this information...
donald
On Thu, Aug 03, 2000 at 09:53:19AM -0400, Laird Nelson wrote:
> 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
