[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cvs questions...
Derek R. Price
Re: cvs questions...
Fri, 01 Dec 2000 11:58:43 -0500
Donald Sharp wrote:
> On Thu, Nov 30, 2000 at 01:56:38PM -0500, Derek R. Price wrote:
> > Donald Sharp wrote:
> > > On Thu, Nov 30, 2000 at 11:56:43AM -0500, Derek R. Price wrote:
> > > > Well, it wouldn't be a meaningful error code since many CVS errors,
> > > > such as
> > > > missing or corrupt configuration files or bad CVSROOT, can cause CVS to
> > > > exit with a status of 1. Redefining EXIT_FAILURE for all of CVS to some
> > > > value >= 2 might do the trick, but you're probably going to bump into
> > > > people depending on the 1 exit code already. I believe there is also a
> > >
> > > Actually, I wasn't proposing redefining EXIT_FAILURE, I was proposing
> > > that when cvs diff get's run it actually reports the error code that
> > > it wants to report. If you go and look at some of the old code, cvs
> > > used to report these error messages on diff failure, it now doesn't.
> > You missed my point here. There is all sorts of shared code that calls
> > error(1,0,...) and will exit long before the diff function in diff.c is ever
> > called. It exits for reasons like bad CVSROOTs, missing config files, etc.
> > Thus,
> > you could easily fix things so that the err value passed out by the diff
> > function
> > was the exit code of main, but an exit value of '1' might still also mean
> > that the
> > application exited before the diff code was ever called because it didn't
> > follow the
> > same path to exit().
> > Thus my point about redefining EXIT_FAILURE to some value higher than 1.
> > Last time
> > I mentioned this I was quickly jumped on by at least one other CVS
> > developer for
> > making things less portable as some systems don't allow exit codes other
> > than
> > SUCCESS & FAILURE (usually 0 & 1, but I'm told it's ocassionally 1 & 0,
> > though I've
> > seen no evidence for this in the CVS source). See my other comments in the
> > last
> > email about my objections to restricting CVS to 1 & 0 exit codes for these
> > reasons
> > of portability.
> Ok -
> I'll change my arguement then ;). How about making cvs diff return
> 0 - Files were different or Files were same.
> 1 - Some sort of error occurred.
> As it currently stands when files are different it is returning a '1'
> which is implying a failure.
> Or how about we put code in there that determines if we are on a
> system that only allows '0' or '1' and forcing all exit()'s to
> be either a '0' or '1', else return what was returned from the
> pseudo code:
> void _exit( int status )
> #ifdef LIMITED_EXIT_CODES
> status = status ? EXIT_FAILURE : 0;
> exit( status );
I'm for a combination of those two solutions. Return a proper diff error code
that can handle it and 0 for different or same and 1 for errors on other
does mean that ERROR_EXIT will have to be redefined to 2 or greater on systems
handle it, which should be easy enough for existing scripts to deal with,
minor fixes. Any objection to ERROR_EXIT = 119 (Linux BASH defines 127 to
found", 126 to "command found but not executable" & 128+N to "command
terminated on fatal
signal N" and I thought I'd leave them a little extra room for expansion)? I'd
add in the BASH builtin default of 2 meaning improper usage, too, just for
system's possible error codes should be easy to discover with configure. I'd
half the work on this if you don't want to since I think I know where all the
should go, assuming you were telling the truth about diff in diff.c returning
code, but you do the docs and test cases. :)
diff is defined in SUSV7 as returning '2' specifically for trouble, not >=2.
for both diff & diff3 under Linux 2.2.X. Not sure that's relevant, but
cc'd bug-cvs for comments.
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden OpenAvenue ( http://OpenAvenue.com )
Confucius say, "Man who live in glass house dress in basement."
- Re: cvs questions...,
Derek R. Price <=