Incompatible seq behaviour

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

There are various incompatibilities in behaviour between NetBSD seq,
GNU seq, and Plan 9 seq (which are the only two alternatives I'm aware
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.

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.

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.

mvg,
Michiel