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: Derek Robert Price
Subject: Re: adding a new CVS_PID environment variable
Date: Fri, 07 Mar 2003 23:19:22 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02

Mark D. Baushke wrote:

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?


Well, a series of greps for the parent of a process ID until the process name is "cvs" could work, but I meant that it could be set in something close to a single step if it was set and export it in foo.sh. Then all the child scripts would have it available as CVS_PID in their environment.

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.


Well, like I said, any process in the group can find its parent, then its parent, then its parent, and so on until the parent's name is "cvs". The number of children and grandchildren it has is irrelevant when looking for a parent. Up is easier than down. Still, just having the first script called set CVS_PID should be easiest.

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 know this isn't a huge deal. I'm just opposed to adding anything to CVS that can be done fairly simply in the child.

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. :-)

Maybe. You're convincing me that you are determined, but I'm still not convinced that it is really so hard to find/set it in a child script. Even if it can be set from a child, convenience can be an argument if there is a widespread demand for the feature, but is use really so widespread? Maybe we can get some BSD folks to chime in with opinions? Is there an appropriate email list to CC? I'd be interested in hearing some other opinions from CVS users too.

Derek

--
               *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
--
This punishment is not boring and pointless.
This punishment is not boring and pointless.
This punishment is not boring and pointless...

         - Bart Simpson on chalkboard, _The Simpsons_







reply via email to

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