Hi Todd, in view of your arguments and sthen@'s OK, i'm also OK with this going in. I think a bit of code cleanup and copy editing in the manual page may be useful afterwards, but that can be done in the tree, no need for playing patch ping pong.
See below for answers to the individual points. If you think any of these can already be trivially handled by your initial commit, feel free to do so. Otherwise, we can reconsider after the commit. Also note that this thing is UTF-8 neutral even though many other utilities processing separators are not. The -f, -s, and -t arguments can contain UTF-8 and it just works. No need to call setlocale(3) or inspect LC_*. Yours, Ingo Todd C. Miller wrote on Mon, Nov 16, 2020 at 10:08:08AM -0700: > 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 That's probably true. > and characterizing jot as a "standard utility" is simply not accurate. Oops. You are right, it's a BSD utility, not a standard utility. Seems like i got too used to having it around. >> $ 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? Granted that this can be subsumed under "bug-compatible" and that the FreeBSD behaviour makes more sense. Even though: $ /usr/local/plan9/bin/seq 3 -1 10 ; echo $? 0 >> $ 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. How stupid of me. I'm running the kernel+libc combo poisoning printf(%n) in writeable memory, so i should really inspect /var/log/messages when something hits abort(3), or running that stuff is useless. You are right, with gnulib inside coreutils fixed, i see the some output as you do. So no discrepancy here. $ /usr/local/plan9/bin/seq 3 0 10 ; echo $? seq: zero increment 1 >> $ 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. I fully agree that the FreeBSD behaviour is more useful, even though $ /usr/local/plan9/bin/seq 3 1 ; echo $? 0 If this goes in now, we are probably far enough away from a release to notice if anything in ports builds depends on the GNU behaviour - which does not seem very likely. If the FreeBSD behaviour causes problems, we can decide what to do later. >> $ 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. Fair enough. Besides, %a is documented as ambiguous. Strangely, the GNU form matches the description in our manual page (minimal length of the mantissa) while our printf(3) output does not (it seems to maximize the exponent instead, which is the same as minimizing the *size*, not the *length* of the mantissa). By the way, Plan 9 does not seem to support -f '%a' at all. >> $ 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 Yes, so there is no issue here. >> $ 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. The more serious problem here is whether the -s argument should appear after each number or merely between numbers. That is not a matter of bug compatibility but a serious difference in behaviour. Both the FreeBSD and the GNU manual page say "separate", so maybe the trailing separator in FreeBSD seq can be regarded as a bug. The GNU behaviour also makes more sense because the FreeBSD behaviour of "printing after" can simply be achieved by appending the -s argument to the format string. So the only useful application of -s would be to suppress the line break, and for that, -s would not need an option argument. A trailing newline is always printed by GNU seq, even in `gseq 1` where there is no separator. So the NetBSD and GNU behaviour of also printing a trailing newline with "-s something" makes more sense to me than the FreeBSD behaviour of omitting the trailing newline when -s doesn't contain any. Another reason that is better is that seq(1) can be considered a text file utility, and text files must have a trailing newline according to POSIX. Note that neither the FreeBSD nor the GNU manual match the behaviour of either of them. The text in the FreeBSD manual - in particular the remark about when -t is useful - would only make sense after changing "separate" to "after each number". The GNU menual fails to mention the trailing newline. >> $ 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 doesn't either. Maybe having escape support anyway is more useful than not having it. It seems more likely that somebody relies on escape support than that somebody might rely on \n or \t going through unmolested. > Plan 9 seq has no -s option. Given that all of NetBSD, FreeBSD, and GNU provide -s, having -s is probably useful. >> $ 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. Actually, i don't like printing novels when --help is given because that requires maintaining three versions of the documentation (usage, --help, and manual page), and when you have both usage() and manual page at hand, the --help output is next to useless. But maybe --help should do the same as -h, i.e. omit the line seq: unknown option -- help >> $ 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. Fair enough, so that should stay as it is. This difference is maybe also unlikely to cause issues. > 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. Agreed.
