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
> subcommand.
>
> pseudo code:
>
> void _exit( int status )
> {
> #ifdef LIMITED_EXIT_CODES
> status = status ? EXIT_FAILURE : 0;
> #endif
>
> exit( status );
> }
I'm for a combination of those two solutions. Return a proper diff error code on
systems
that can handle it and 0 for different or same and 1 for errors on other systems. This
does mean that ERROR_EXIT will have to be redefined to 2 or greater on systems which
can
handle it, which should be easy enough for existing scripts to deal with, perhaps with
minor fixes. Any objection to ERROR_EXIT = 119 (Linux BASH defines 127 to "command not
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
probably
add in the BASH builtin default of 2 meaning improper usage, too, just for kicks. A
system's possible error codes should be easy to discover with configure. I'd even do
half the work on this if you don't want to since I think I know where all the code
pieces
should go, assuming you were telling the truth about diff in diff.c returning the
correct
code, but you do the docs and test cases. :)
diff is defined in SUSV7 as returning '2' specifically for trouble, not >=2. Same goes
for both diff & diff3 under Linux 2.2.X. Not sure that's relevant, but something to
consider.
cc'd bug-cvs for comments.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
Confucius say, "Man who live in glass house dress in basement."
_______________________________________________
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
