From: Greg Troxel <gdt%lexort.com@localhost>
> Brian Ginsbach <ginsbach%netbsd.org@localhost> writes:
>
>> 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'.
>
> Interesting about FreeBSD and MacOS, and history.
>
> So would you propose changing the man page to describe the traditional
> BSD seq behavior instead?
I just tested seq on Mac and FreeBSD. Brian is right: they both behave like the
original NetBSD seq. GNU's seq from April 1999 uses the proposed behavior.
This makes me to wonder which behavior is the least astonishing. :-)
This is a bit of lobbying for the new behavior. With -s and -t, I can recover
the original behavior with the new. However, I'm not sure if I can mimic the new
behavior with the original.
What would you think of -s setting both separator and terminator if no -t is
provided? This would be closer to the original behavior, but enable the
following:
~$seq -s , 1 3
1,2,3,
~$seq -s , -t '\n' 1 3
1,2,3
~$
Aran
PS: Brian, I use seq all of the time. Thank you.
Attachment:
pgpi_sEZImydB.pgp
Description: PGP signature