Re: Incompatible seq behaviour

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

On Tue, Oct 14, 2008 at 02:34:34PM +0200, Michiel Buddingh' wrote:
> Hubert Feyrer <hubert%feyrer.de@localhost> wrote:
> > On Tue, 14 Oct 2008, Michiel Buddingh' wrote:
> > > 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.
> >
> > What is your suggestion to handle the case you describe?
> 
> Either:
> 
> * Work on Bug-for-Bug compatibility with GNU seq (as the original
>   author puts it).  If this is deemed the best solution, I'm willing to
>   invest some time in this.  Alternatively, match the behaviour of
>   Plan9 seq, but I'm not sure this is preferable.

This may make sense in certain instances.  There is no reason that
it must be 100% bug-for-bug compatible with GNU.  I think that any
incompatibilities should be judged on a case by case basis.

> * Remove seq from the base system, make it available as a
>   package.  FreeBSD doesn't include a seq by default, I'm not sure about
>   Solaris or OS X.

This doesn't really seem like a solution.  NetBSD doesn't have system
packages as yet.

> * import seq from GNU coreutils

Again, this is really a non-starter for a BSD system.

> 
> Of course, there may be NetBSD-specific scripts that depend on the 
> established behaviour.
> 
> It's obvious that the original author was aware of the issues and tried
> as best as he could to impose a bit of logic on an otherwise fairly
> idiosyncratic and non-standard utility, but ultimately I don't think
> having a third, incompatible variant is all that useful.

This isn't true either.  It can be very useful.  It can move the
currently accepted practice.  Without a competing implementation
then the de facto standard becomes GNU.  This means that only GNU
gets to establish accepted practice.

> 
> mvg,
> Michiel

--
Brian Ginsbach