On Tue, Dec 18, 2018 at 12:16:58PM +1100, Simon Burge wrote:
> Greg Troxel wrote:
>
> > a...@100acres.us 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
