Ingo Schwarze <[email protected]> writes: > 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.
I noticed that despite the OKs the code didn't submitted. Should we revive this diff now and continue in the tree? I have vested interest: I don't want to fix up lang/ghc test suite which is full of seq(1). Thanks Greg > > 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.
