This is similar to the GNU utility of the same name: it prints its input
in reverse. The command-line options, however, are inspired by cat, not
by GNU tac.
Details
Details
- Reviewers
- None
- Group Reviewers
srcmgr
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 69255 Build 66138: arc lint + arc unit
Event Timeline
Comment Actions
This is cool, I was just wishing we had a tac the other day!
| usr.bin/tac/tac.1 | ||
|---|---|---|
| 2 | This hyphen was for a parser Warner wrote and abandoned long ago. We removed it from the style guides. | |
| 5 | style(9) and the licensing guide show the updated style, you want to do the copyright before the SPDX, and the license text is no longer recommended. | |
| 37 | Iiuc? | |
| 83 | You can replace all of the text in this section with .Ex -std, which produces identical text | |
Comment Actions
While I'm generally supportive of adding a more discoverable alternative to the standard tail -r (as expressed elsewhere), and applaud your constant efforts on test cases, I find the proposed implementation problematic:
- It's an entirely separate program whereas it's basically a combination of functionality that exists in tail and in cat (more details below). It's only ~100 C lines, but it may be 90 lines too many (see again below).
- It sucks a file entirely in memory before outputting anything, so is not friendly to big files, and even less to pipes.
- It uses fread() where it could use mmap() (doesn't matter for regular files now, but will once the previous point is fixed).
- It's not CAPSICUMized.
Why I'm mentioning all this? After all, some will say: Something is better than nothing, and it could be improved upon later. That has some merit, but I don't think it weights much given there exists an alternative that in less than 10 C lines solves *all* of these problems, and it's basically a slight modification to tail(1) so that tail called via tac will just behave like tail -rq. This is exactly what NetBSD has done, as can be seen here: tail.c rev 1.17 to 1.18. Re-indentation aside, that's basically adding less than 10 lines of C, and dumb ones at that.
Compared to the implementation here, doing this has a small drawback: The lack of options -b, -n and -s. But (as you said elsewhere), for a single file, the same effect can be obtained by tac <file> | cat [-bns]. Only for multiple files passed to tac a shell script loop would be necessary to number each file separately. If you really want to have this specific behavior with numbering/squeezing on multiple files without resorting to a bit of shell scripting, then I'd suggest instead to implement these options in tail, where I think they would be more useful. tac(1) not having these options could even be seen as an advantage, as GNU's tac(1) does not have any of them (less non-compatibility).
All-in-all, I think we'd do better to modify tail(1) than to add a new C program that will then need improvements to reach parity on a number of points.
| usr.bin/tac/tac.1 | ||
|---|---|---|
| 41 | Slightly more accurate formulation. | |