On Mon, 16 Nov 2020 16:14:31 +0100, Ingo Schwarze wrote:
> are you really sure this is a good idea? The version you sent is
> wildly incompatible with GNU sed. So we add a non-standard utility
> that exhibits different behaviour on different systems even though
> a standard utility already exists for the purpose?
I don't think we need to be bug-compatible with GNU seq and
characterizing jot as a "standard utility" is simply not accurate.
> $ seq 3 -1 10 ; echo $?
> seq: needs positive increment
> 1
> $ gseq 3 -1 10 ; echo $?
> 0
This is not valid usage, you cannot get to 10 from 3 with a negative
increment. We could silently exit like GNU seq if that is desirable
but is silently ignoring a usage error really what we want?
> $ seq 3 0 10 ; echo $?
> seq: zero increment
> 1
> $ gseq 3 0 10 ; echo $?
> gseq: Abort trap (core dumped)
> 134
I get the following:
gseq: invalid Zero increment value: ‘0’
Try 'gseq --help' for more information.
> $ seq 3 1 ; echo $?
> 3
> 2
> 1
> 0
> $ gseq 3 1 ; echo $?
> 0
GNU seq uses a default increment of 1 even if first > last.
Personally, I think using a default increment of -1 makes more sense
in the above case, but we can easily make this match the GNU behavior
if we desire.
> $ seq -f '%a' 3
> 0x1p+0
> 0x1p+1
> 0x1.8p+1
> $ gseq -f '%a' 3
> 0x8p-3
> 0x8p-2
> 0xcp-2
The BSD seq output is consistent with printf(1), GNU seq is not.
I'd classify this as a GNU bug.
> $ seq -f '%i' 3
> seq: invalid format string: `%i'
> $ gseq -f '%i' 3
> gseq: Abort trap (core dumped)
I get:
gseq: format ‘%i’ has unknown %i directive
> $ seq -s / 3 ; echo $?
> 1/2/3/0
> $ gseq -s / 3 ; echo $?
> 1/2/3
> 0
The missing newline appears to be a bug in the FreeBSD seq, NetBSD
seq works correctly.
> $ seq -s '.\n' 3 ; echo $?
> 1.
> 2.
> 3.
> 0
> $ gseq -s '.\n' 3 ; echo $?
> 1.\n2.\n3
> 0
GNU seq does not support C-style escapes such as \n and \t.
Plan 9 seq has no -s option.
> $ seq -s / -t '\n' 3 ; echo $?
> 1/2/3/
> 0
> $ gseq -s / -t '\n' 3 ; echo $?
> gseq: unknown option -- t
> Try 'gseq --help' for more information.
> 1
> $ seq --help
> seq: unknown option -- help
> usage: seq [-w] [-f format] [-s string] [-t string] [first [incr]] last
> $ gseq --help
> [... prints a novel ...]
Looks like a bug in BSD seq.
> $ seq 0 .5 1
> 0
> 0.5
> 1
> $ gseq 0 .5 1
> 0.0
> 0.5
> 1.0
BSD seq output is consistent with Plan 9 but different from GNU.
I'm happy to fix the actual bugs. I think we should be trying to
match GNU seq behavior where possible so we can use seq in ports.
- todd
