[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Maxium command line args?
From: |
Derek R. Price |
Subject: |
Re: Maxium command line args? |
Date: |
Mon, 12 Mar 2001 14:21:57 -0500 |
No, but I had some further thoughts on the matter. I still only see this as a
short term fix, but how about if the behavior changes on a pipe ('|') as the
first
character rather than something so specific as xargs or the name of some
environment variable?
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:dprice@openavenue.com OpenAvenue ( http://OpenAvenue.com )
--
Of liberty I would say that, in the whole plenitude of its extent, it is
unobstructed action according to our will. But rightful liberty is
unobstructed action according to our will within limits drawn around us by the
equal rights of others. I do not add 'within the limits of the law,' because
law is often but the tyrant's will, and always so when it violates the right of
an individual.
- Thomas Jefferson to I. Tiffany, 1819.
Forrest Aldrich wrote:
> Did anything ever come of this?
>
> Forrest
>
> At 11:23 AM 3/1/2001 -0500, you wrote:
> >Forrest Aldrich wrote:
> >
> > > we use CVS to maintain our DNS data. We also use a DNS regression
> > > suite (see http://www.quick.com.au/help/dns.html) to do pre-commit
> > > checks - very handy.
> > >
> > > The above toolset includes facilities for generating PTR records.
> > > If/when we re-configure said tool, it can cause a few hundred in-addr
> > > zone files to change.
> > >
> > > This typically causes the pre-commit checks to fail as the OS command
> > > line length is exceeded when cvs attempts to run the regression suite
> > > in that directory.
> > >
> > > The patch below (to cvs-1.10) modifies precommit_proc() such that if
> > > the pre-commit filter command begins with "xargs" or _PATH_XARGS, then
> > > it is run using run_popen() rather than run_exec().
> >
> >Hmm. I think the long term fix for this is to use XML or CGI or the like to
> >always pass any data needed by the child on stdin. There was a discussion
> >on this
> >matter on one of the lists sometime over the last couple months.
> >
> >I don't like this as a long term fix because the *info hooks should work
> >in some
> >uniform manner and, at the least, the verifymsg and loginfo hooks already
> >accept
> >data on stdin.
> >
> >I might not object to something like this as a temporary fix, though. What
> >do
> >other people think?
> >
> >Derek