[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Incompatible seq behaviour
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.
Main Index |
Thread Index |