[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: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?
> * 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.
Main Index |
Thread Index |