[Top][All Lists]

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

Re: [PATCH] {master} tests: more consistent checks about invalid options

From: Ralf Wildenhues
Subject: Re: [PATCH] {master} tests: more consistent checks about invalid options
Date: Tue, 11 Jan 2011 21:32:49 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

* Stefano Lattarini wrote on Tue, Jan 11, 2011 at 09:22:26PM CET:
> On Tuesday 11 January 2011, Ralf Wildenhues wrote:
> > >  AUTOMAKE_fails -Wno-error --output-dir=foo
> > > -$EGREP '(invalid|unrecognized) option.*--output-dir' stderr
> > > +grep 'unrecognized option.*--output-dir' stderr
> > 
> > This strikes me as wrong.  Why would you have written the test like this
> > in the first place if there wasn't a good reason for this?
> > (And just the time required to think about this, track down the reason
> > for the original choice, etc., wastes more than would have been gained
> > by this patch IMVHO.)
> >
> > Maybe because Getopt::Long::GetOptions could throw a (differently
> > spelled) error itself?
> >
> That's what I was suspecting myself when I wrote this hunk; so, instead
> of risking some spurious failure in later on-field testing, I preferred
> to be a bit lax in the grepping of the error message (after all, both
> "invalid option" and "unrecognized option" are good and clear messages).
> But then I saw that the similar tests aclocal.test and automake.test
> are stricter in their grepping of error messages, and no failure has
> been reported against them as of today -- so I realized that such a
> laxness was uncalled for.  And being more consistent wouldn't hurt,
> either.
> And this patch was borne.

You must mean "born" (borne means something different) here.

>  Does this explanation clarifies things?

Yes: it clarifies that you still have too much time on your hands to
spend on really unimportant stuff, thereby delaying more useful work.


reply via email to

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