On 10/23/2014 05:53 PM, Eric Blake wrote: > On 10/23/2014 10:39 AM, Eric Blake wrote: >> POSIX is considering standardizing the Solaris/BSD behavior of 'tail -r' >> rather than adding the GNU extension of 'tac' as a separate utility: >> http://austingroupbugs.net/view.php?id=877 >> >> This bug report serves as a reminder that we need to add 'tail -r' >> support to coreutils, as well as a request for reviewers for the current >> state of the proposal to make sure that it is not an onerous burden for >> adding that code. >> > > Implementation-wise, I'm thinking the easiest thing might be to turn > tac.c into a shared library-style file (similar to how copy.c is shared > among multiple programs), add a 'tac -n' option that limits output to a > fixed number of "lines" (or rather, a fixed number of occurrences of > '--separator'-delimited segments), then have the new 'tail -r' call into > the library code with separator hard-coded to newline, along with > sufficient checks that tail's new -r can only be used with -n with no > sign on the number (at least, as a first cut; we can certainly support > more combinations than what POSIX wants to require, if we can determine > sane semantics and easy implementations for those combinations).
The above approach sounds sensible if we were to do this. Now the only reason I see would be for compat with solaris and BSD. I don't think they should have included that functionality though as there isn't much complementary with the other tail functions (being incompat with -f for example) and so is better split out as a separate util. The only small advantage of integration is a tiny perf benefit when specifying a number of lines, but really `tail -r -n$num $file` is of minimal improvement over `tac $file | head -n$num` (though would be better than `tail -n$num | tac` as it avoids buffering). As a side note I see that solaris doesn't even support non seekable input mode (though BSD does): $ printf "%s\n" 1 2 3 | tail -r -2 tail: cannot open input Pádraig.