Re: patch: contrib/compare_tests

[Zack Weinberg]

> Andrew Pinski wrote:
> > > I was lazy today and decided to use compare_tests.  Guess what, it doesn't
> > > work on recent coreutils/sort (i.e. the one on FC5).
> > 
> > This is the same problem as tail and head.  Someone should tell Coreutils
> > that again they broking stuff that should work no matter what environment
> > variable is set.
> > 
> > Also Redhat (and all other distros) should think about bycotting GNU
> > Coreutils until they fix this bug.
> 
> Coreutils is just implementing the decisions of the Austin Common
> Standards Revision Group.

We are aware.  The decision is no less wrong for having been made by a
standards body.

As I and others have explained the past umpteen times this has come
up, these shell scripts have to work with a variety of legacy Unixes
whose default shell utilities do not support, *and will never support*,
the new syntax.  Out of fear of breaking third-party scripts, they
added the new features only to an alternative set of tools (often,
but not always, /usr/xpg4/bin)  We can neither assume the user has
the alternative set in their PATH, nor add it automatically (it would
be wrong to override a /usr/local/bin/sort that the user has installed,
frex.)

Maybe, 20 years from now, these legacy systems will be dead, and we can
assume -k will work.  I shan't be holding my breath.

> If someone posted here that e.g. g++ rejected code that was not valid
> C++0x the response would be exactly the same, "fix your code" not "g++
> is buggy for not accepting this broken code and should be boycotted."

The difference is that it's *possible* to fix broken C++, even if one has
to maintain interoperability with legacy compilers.  The preprocessor
continues to exist in C++ for a reason.

...I suppose we might consider a patch that did something clever like
figure out which command line syntax this system's sort actually
supports.  However, you'd be signing up to maintain that for all
time against all manner of bizarre variations on the rule.  As
someone who's done such things, I advise against it.

> > >      On older systems, `sort' supports an obsolete origin-zero syntax
> > >   `+POS1 [-POS2]' for specifying sort keys.  This obsolete behavior can
> > >   be enabled or disabled with the `_POSIX2_VERSION' environment variable
> > >   (*note Standards conformance::), but portable scripts should avoid
> > >   commands whose behavior depends on this variable.  For example, use
> > >   `sort ./+2' or `sort -k 3' rather than the ambiguous `sort +2'.

bug-coreutils: this advice is wrong.  Portable scripts *must* use
'sort +2' if they want the effect of 'sort -k 3', and GNU sort
should neither describe that syntax as obsolete nor disable it
under any circumstances.  Same goes for every other command line
syntax that 1003.1-2001 tries to obsolete.

zw

p.s. Don't bother trying to convince me I'm wrong about the aforementioned
legacy unixes, unless you have access to every version of every legacy OS
that GCC still supports.  I have been around this particular dead horse
plenty of times already, thank you, and I know whereof I speak.