[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: adding a new CVS_PID environment variable
From: |
Mark D. Baushke |
Subject: |
Re: adding a new CVS_PID environment variable |
Date: |
Tue, 25 Feb 2003 16:10:03 -0800 |
Derek Robert Price <derek@ximbiot.com> writes:
> Mark D. Baushke wrote:
>
> >Hi Folks,
> >
> >The FreeBSD folks have had a CVS_PID environment variable in their
> >version of cvs since 1997-05-15 and they got it from the OpenBSD folks
> >before that. It is a simple addition. Here is my port of this feature.
> >
>
> Can you provide some examples why is would be useful to have the PID
> of the parent process?
Doing something like log_accum in an environment to collect all of the
changes for a given commit into a single e-mail message and send it, but
NOT using perl might be one reason.
The place where I saw this used was when there were multiple levels of
shell scripts being used for the commitinfo/verifymsg/loginfo triggers
and they wanted to use the log_accum trick of being able to find
intermediate results between those triggers.
Consider a trigger that does something like this:
DEFAULT $CVSROOT/CVSROOT/path-to-some-command
where path-to-some-command does
-> run a check to see if the user is administratively allowed to
commit or not (possibly checking for a valid
-> run a child-script
-> runs a script to checks for the copyright being up-to-date
-> runs a script to check the code has been run thru ident
-> runs something like the commit_prep example where child-script
rather than the 'cvs' process is really the parent
If the ${CVS_PID} variable is available, then there is less need to be
worried about some check in a child script scribbling information into a
file that a subsequent log_accum equivalent script will eventually find.
> The c "getppid" function is defined by POSIX, BSD 4.3, and SVID to
> return the PID of the parent process. Isn't there some shell
> equivalent?
I do not know of any for the various shells that exist. However, even if
there was a way to find the partent of the current script, that does not
imply that it is the cvs parent.
Also, there is nothing to guarentee that the script fired off by the
commitinfo/verifymsg/loginfo trigger.
> At the least, something like `ps -eaf |grep $$' should be
> usable. What's the point of including this in the CVS code?
Yes, there are possibilities that exist for many operating systems to
let you try to figure out which cvs process is the root of your current
scripts.
They are not very portable as solutions go (try to figure out cleaner
tests than the ones I wrote for sanity.sh and then get it running on the
same number of targets hosts for which cvs may be compiled). Then try to
figure out how much extra processing would end up getting done by each
of the trigger scripts to communicate in that way.
A final point, I would consider it useful if the divergent versions of
CVS that exist could somehow make it back together (when you have a
heterogeneous computing environment it is nice to use the same tools
across all f your machines if possible). This is a small feature that
seems to be useful to the FreeBSD cvs community. Why not make it
available to the cvshome.org community as well?
Thanks for your consideration of this patch.
Enjoy!
-- Mark