Re: Incompatible seq behaviour

[Michiel Buddingh' <michiel%michielbuddingh.net@localhost>]

Brian Ginsbach <ginsbach%NetBSD.org@localhost> wrote:
> On Tue, Oct 14, 2008 at 02:10:18PM +0200, Michiel Buddingh' wrote:
> > There are various incompatibilities in behaviour between NetBSD seq,
>
> As the author I'd like to know just what the various incompatibilites
> are.  You state only one below.  Are there others?

Yes, mainly caused by the fact that neither GNU or Plan 9 seq 'infers'
a negative increment when the sequence specified goes from high to low.

GNU seq also has the 'ability'/bug to output an infinite sequence of
the same number (when the increment is zero).

I wrote a limited atf test suite and a badly tested patch at the behest
of Jeremy Reed a few days ago; I've attached it for your convenience.

> > GNU seq, and Plan 9 seq (which are the only two alternatives I'm aware
>
> Also note that NetBSD seq is included in DragonFlyBSD as well.

Noted.  That makes NetBSD, Plan 9, DragonFlyBSD and Linux the only 
platforms I know of that include seq.

> When I wrote NetBSD seq it was mostly bug-for-bug compatible with
> GNU seq.  I noted the one exception.  The incompatibility you
> mention was not an incompatibility when I wrote NetBSD seq.  Or at
> least the version I was comparing it to.  It appears that GNU seq
> has since changed its behavior to be Plan 9 seq compatible.

That's very interesting, but it sort of illustrates a point I'm
trying to make.  Understand that I'm not holding up GNU seq as a
paragon of rationality.

> > Nevertheless, looking back at the original discussion in 2005 about
> > seq's inclusion, it seems that it was included _only_ for the sake 
> > of compatibility with Linux scripts.  Unfortunely there does not seem
> > to be any standard governing its behaviour, so it's hard to come up
> > with an argument against tracking the version with the largest 
> > installed user base.
>
> I don't agree with this premise.  If it were really true then there
> would be a lot of NetBSD that looked/worked like GNU and Linux.

Don't get me wrong, I'm not a great fan of the GNU/Linux embrace and 
extend philosophy and the directions it's forcing the BSDs to take.
For example, I don't particularly see the value of including the 
asprintf utility function in libc when it can be easily duplicated 
by application programmers.

I've 'attacked' an ostensibly fine piece of software, so I suppose 
I owe you a careful enumeration of my reasons:

  * GNU/Linux dominates the installed user base.  This has huge
    implications for Open Source software development.

    I don't attach any moral judgement to the above, but I hope
    we can agree on it.

  * NetBSD is a platform with limited developer resources directed
    at it.  That means it should be careful not to dismiss large
    amounts of work committed by individuals, but also that it
    shouldn't overextend itself.

    Including a feature or utility brings with it the obligation
    of maintenance.

  * It's better not to be compatible at all, than to to be in-
    compatible in non-obvious ways.

    This, I suspect, is where we disagree, but I feel it's easily
    illustrated by the case of seq; on FreeBSD, seq is simply not
    present, and scripts using it fail.  The user can then choose
    to install GNU coreutils from ports, and use it.

    On NetBSD, Gnu coreutils seq from pkgsrc is installed as 'gseq',
    so as not to conflict with the base seq.  Base seq may then
    behave in unexpected ways.

  * The GNU people are certainly not averse to changing things when
    they feel like it; maintaining compatibility with GNU means 
    that you're forever required to follow them.

I presented three 'solutions' to the mailing list, and later off-list
I expressed that removing seq completely would be the the option of
least resistance.  Along with the tool's absence from MacOS X, 
FreeBSD and Solaris (the major non-GNU Unix platforms), it would
reaffirm the fact that seq is a non-standard utility, the presence
of which simply cannot be expected.

A fourth option comes to mind, and that is to settle on Plan 9 
behaviour, while also getting the GNU people to standardize on that
(and standardize completely, not partially as now).  Or get the GNU
and Plan 9 people to standardize on NetBSD behaviour, whatever suits
your fancy.  The GNU people have obviously changed the command once,
they may well see the reason of doing it another time it if means
better compatibility.  Much ado about a little utility, but better
than nothing.

I hope you can appreciate my position.

with kind regards,
        Michiel