4 Mar
2020
4 Mar
'20
11:25 p.m.
I missed knowing about tac till now. I’ve used tail -r since
1982 when Yost pointed out that tail -r|rev was equivalent
to a toy recursive C program I had written to reverse a file.
He was almost right!
rev(){int c=getchar();if(c==EOF)return;rev();putchar(c);}
On Mar 4, 2020, at 8:19 AM, John P. Linderman
<jpl.jpl(a)gmail.com> wrote:
The "statute of limitations" must have passed long ago, so I confess to having
been the author of the original tac (cat in reverse). I was working on a project that
wrote log files, but the logs were very "bursty". Minutes might go by without
any activity, followed by a burst of logging activity. We often wanted to see the most
recent burst of activity, so "tail -f" wouldn't do the job. It would show
the next burst of activity, which might not occur for quite some time. Somebody posted a
functional equivalent on some netnews group, but it was ghastly. I think it did seeks of
-1 characters at a time to accumulate each line. That would have been fast enough to feed
our pathetic 1200 baud terminals, but it would have beat the system to death, and that
would have been a disservice to other users. My version did reads of 512 bytes on 512-byte
boundaries, so it put much less load on the system. I couldn't bear to see something
like the netnews version
get adopted. The software release process at the Labs was a bureaucratic nightmare, so I
"tossed my version over the wall", into the arms of Andy Tanenbaum, as I recall.
He made it public, attributed to "an unknown author".
I don't know how Rob Pike got ahold of it, but he recognized that mailbox files had
the same bursty growth. Unlike our log files, whose contents were acceptably
understandable in reverse order, mail messages were hard to read in reverse order, so he
proposed making it possible to recognize the headers at the start of each mail message,
and put the entire message out in readable order. I think that was a useful option, but
the irony of Rob adding an option to "tac" was hard to overlook.
The version out there now was rewritten by Jay Lepreau, it seems:
/*
* tac.c - Print file segments in reverse order
*
* Original line-only version by unknown author off the net.
* Rewritten in 1985 by Jay Lepreau, Univ of Utah, to allocate memory
* dynamically, handle string bounded segments (suggested by Rob Pike),
* and handle pipes.
*/
Dynamic buffer allocation rather than relying on the time-honored 512-bytes-is-enough
assumption was a positive, as was supporting Rob's suggestion. Handling pipes strikes
me as a waste of code, but hey, anything is better than that version I replaced.
> On Wed, Mar 4, 2020 at 9:15 AM Nelson H. F. Beebe <beebe(a)math.utah.edu> wrote:
> Arnold Robbins writes:
>
> >> There was no tac in V7 Unix. It was first posted to USENET, I don't
> >> know by who, and picked up by Linux and *BSD.
>
> That brought back memories, and to verify them, I checked the tac.c
> source code in the latest GNU coreutils test release. It says
>
> /* Written by Jay Lepreau (lepreau(a)cs.utah.edu)
> GNU enhancements by David MacKenzie (djm(a)gnu.ai.mit.edu) */
>
> So my memory was right that my old friend Jay was the author. Sadly,
> we lost him in September 2008: see
>
>
https://www.legacy.com/obituaries/saltlaketribune/obituary.aspx?page=lifest…
>
> Jay founded the influential Flux group in advanced networking research:
>
> http://www.flux.utah.edu/profile/lepreau
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe Tel: +1 801 581 5254 -
> - University of Utah FAX: +1 801 581 4148 -
> - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
> - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
> - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
> -------------------------------------------------------------------------------