Re: Incompatible seq behaviour

[Brian Ginsbach <ginsbach%NetBSD.org@localhost>]

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?

> 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.

> of).  Most notable is the fact that both GNU seq and Plan9 seq produce
> no output when given a single non-positive argument, whereas NetBSD seq
> then assumes a default second argument of 'one'.
> 
> This leads to differences even in fairly idiomatic scripting use,
> , e.g:
> 
>       for i in `seq $MAX`; do
> 
> Will produce different results.
> 
> In all fairness, the author of NetBSD seq seems to have been aware of
> these issues, and has documented them well.

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.

I guess I'm willing to defer to Plan 9 behavior in this case as
the "standard".  I'm not fully convinced of the utility of the
change.  I'd still like to, if possible, preserve the more rational
(logical) current behavior.

> 
> 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.

> 
> While logical in its own right, NetBSD seq does not behave like any
> other seq out there, and in its current form is probably not preferable
> to either including GNU coreutils seq, or having no seq at all.

I'm pretty sure that adding any part of GNU coreutils isn't going to
happen.  This is a BSD system after all.

> 
> mvg,
> Michiel

--
Brian Ginsbach