On 10/23/2014 08:03 PM, Eric Blake wrote: > On 10/23/2014 12:35 PM, Pádraig Brady wrote: >> >> 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. > > Yeah, today's Austin Group call included a debate about whether > standardizing 'tac' would be smarter than 'tail -r', but the consensus > among those on the call was that since:
I understand these 3 arguments, though don't necessarily agree with any. > 1. more implementations already have 'tail -r' than 'tac' More implementations but definitely not more installations. POSIX should prefer the most popular interface in my biased opinion. > 2. standardizing new requirements to an existing utility is easier than > adding a completely new utility (if only slightly, due to less paperwork) meh, paperwork should not impact on interface > 3. GNU code tends to be the most adaptable True, though while pragmatic should also not dictate interface. Saying that, I'm 50:50 for implementing `tail -r` for compat reasons. > therefore, 'tail -r' won the vote, and the result of the meeting was an > action to me to see how adaptable GNU really is, and whether we can > indeed quickly implement 'tail -r'. > >> >> 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). > > The fact that we DON'T have 'tac -n' is what intrigues me most; that's > the one thing that 'tail -r -n' can do in a single process that GNU > can't. Of course, it is trivial to implement it by doing what tac has > always done and then stop output after -n is exceeded, and easy on > seekable files as well. But on non-seekable files, it may lend to an > interesting optimization where knowing that the output will be limited > to n lines makes it easier to set up a rolling window of the most recent > n lines seen rather than having to dump out to a temporary file when the > file proves to be larger than the current hueristics of when tac stays > in memory. -n wouldn't really have any impact on that better implementation. I.E. ideally we should have an adaptive buffer internally that after 128KiB or so (the current io_blksize()) would start buffering to file, irrespective of -n. That would deal with large lines and large -n. Generally such an adaptive switch is optimal in various utils, to operate efficiently with small inputs, but scalably with large ones. >> 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 > > Careful, which tail are you testing? From your output, I'm guessing you > are trying to open the file named './-2' rather than limiting -r to a > line count. We made several observations during the Austin Group that > /usr/bin/tail and /usr/xpg4/bin/tail behave differently. > > $ /usr/bin/tail -rc > usage: tail [+/-[n][lbc][f]] [file] > tail [+/-[n][l][r|f]] [file] > $ printf "%s\n" 1 2 3 | /usr/bin/tail -2r > 3 > 2 > $ printf "%s\n" 1 2 3 | /usr/xpg4/bin/tail -r -n2 > 3 > 2 > $ printf "%s\n" 1 2 3 | /usr/xpg4/bin/tail -r -2 > 3 > 2 Ugh right, that's the case here too. How confusing. thanks, Pádraig.
