bug-cvs
[Top][All Lists]
Advanced

[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: Fri, 07 Mar 2003 16:44:06 -0800

Derek Robert Price <derek@ximbiot.com> writes:

> Mark D. Baushke wrote:
> 
> >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.
> >
> 
> In this example, a single ps -eaf |grep type check and setting of the
> CVS_PID env variable would serve just as well.

What logic do you use to find the root of your current process group?
cvs commit causes the commitinfo to run the script foo.sh, in turn
foo.sh invokes bar.sh which invokes baz.sh and it is baz.sh that needs
to save some information for the loginfo step that is run after all the
commits are complete. It is possible that baz.sh may get moved in the
execution order over time. What does it use to find the process id of
the cvs processid of a process that the loginfo step will still be able
to 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.
> >
> 
> Huh?  This last sentence is confusing.

Sorry about that... There is no guarentee that the script run by
commitinfo, verifymsg or loginfo processing does not have multiple
children processes or grandchildren processes or indeed to know how many
levels of processes it is to get you back to the parent cvs that is the
process group leader.

> >>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 single ps -eaf |grep per script call, so once per directory.  It's
> one thing if the scripts can't get the information somewhere else, but
> CVS does the extra processing even when the variable isn't being used
> if the change gets made.

The extra processing consists of a getpid() call that is already being
done in the server side of the code and a setenv() call so that children
processes inherit the environment variable. If this is too much, I
suppose a configure option could be introduced to do this extra work
only when the user wants it done and it could default to off.

> I see this point, but if the workaround is simple enough, I'd rather
> convince the BSD folks to use it and lose their hack.

Well, let me know if my clarification of the above helped the case any
or not. Somehow I doubt the BSD folks will drop the existing patch. :-)

        Later,
        -- Mark




reply via email to

[Prev in Thread] Current Thread [Next in Thread]