Re: Proposed modification to seq

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

On Tue, Dec 18, 2018 at 12:16:58PM +1100, Simon Burge wrote:
> Greg Troxel wrote:
> 
> > aran%100acres.us@localhost writes:
> >
> > > The seq command behaves a little differently than I expect.  I needed a comma
> > > separated list of integers, but seq gave me this:
> > >
> > >  $seq -s , 1 3
> > >  1,2,3,$
> > >
> > > Notice the extra comma and no trailing return.  The comma is troublesome for my
> >
> >  [ ... ]
> >
> > It could just be a bug.  But the man page is inconsistent.
> >
> > I suspect there is almost no use of -s.  But I wonder.
> >
> > If this change makes seq with -s behave like GNU seq, and more closely
> > aligns with seq's own man page, that seems like a reasonable thing.
> 
> GNU coreutils seq does this:
> 
> 	otos:~ 2057> seq -s , 1 3
> 	1,2,3
> 
> Looking at their seq.c:
> 
> 	/* The string used to separate two numbers.  */
> 	static char const *separator;
> 
> 	/* The string output after all numbers have been output.
> 	   Usually "\n" or "\0".  */
> 	static char const terminator[] = "\n";
> 
> with no option to change the terminator option.
> 
> I agree that Aran's suggested change looks a good idea.
> 
> Cheers,
> Simon.

It has been a while since I wrote that code but my recollection is
that it isn't necessarily a bug. That GNU copied and changed the
meaning of -s (again provided my recollection is correct) isn't
surprising either. I'd need to dig back to see what GNU seq had 20
years ago when I originally wrote seq.

I will agree that the -s behavior may violate POLA.

The default "separator" is a newline ('\n').  The -s was to change
this to something else but not assume that the last "separator" be
a terminating newline.  This is why I added the -t option.

The current -s option allows for using interesting separators like
'\r' (carriage return) for a "spinning counter".

Note that FreeBSD has picked up the NetBSD version of seq (and by
that so has Apple for OSX). GNU shouldn't necessarily be considered
as the 'standard'.

-- 
Brian Ginsbach