[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Laird Nelson
Subject: Re: CVS_USER
Date: Tue, 10 Oct 2000 07:45:26 -0400

----- Original Message -----
From: "Jim Kingdon" <address@hidden>
> CGI uses environment variables to pass things to the scripts, and I
> guess I don't really see a problem with using environment variables.
> Although they seem to be non-portable, they aren't, really.  NT and
> VMS have them (or something which the libraries make look the same to
> the programs), for example.

Yes, and then people don't have to remember what arguments to add to
their commitinfo files ("was it the *commitinfo* script that gets the
CVSROOT as the first implicit argument and then the filenames, or was
that the taginfo script?  Damn, where's the Cederqvist?").  CGI IMHO is
a good analogy here; no matter how well specified the types of arguments
are (i.e. whether it's $USER or %u) I'd rather just have all that stuff
show up in the environment for me to use if I see fit.  Then I just have
to memorize a few environment variables instead of remembering
arguments, their order and their quote characters across the various
*info files.

> The main kludginess associated with having CVS process the shell
> commands is that it is unexpected - people don't easily remember just
> what substitutions CVS makes or does not make.  And it is one of those
> things where you get into quoting hell, where CVS does its processing,
> the shell does its, perl/awk/sed/etc (if you call them next) does its,
> and so on.  It is worse with "$" than "%", though.  I really regret
> that $USER hack I put in (it seemed like a good idea at the time :-)).

Yes, exactly.  +1 and all that.  :-)

> Furthermore, last time this came up, everyone seemed to like the
> CVS_USER patch.  Or so is my recollection.  I'm a little surprised no
> one (except you, Derek) is saying anything this time.  Should I be
> asking on devel-cvs?

{loud noises, horns, etc.} That's one of the few patches we've actually

Incidentally, look at which
solves this problem by making it easy to write perl objects that handle
the {commit,log,tag}info processing in a consistent manner.  A plugin,
no matter whether it was fired by commitinfo or verifymsg or loginfo
(and they all take different arguments in different orders) looks the
same and has access to the same information.  To enable this behavior,
the launcher/wrapper program is REALLY complicated, relying on some
Entries file parsing to fill in the blanks.

While we're on the subject, any environment variable that would allow
access to the new revision number PRIOR to the commit taking place would
be wonderful.


reply via email to

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