[TUHS] Command line options and complexity

[Rob Pike]

I have no memory of this, but that doesn't mean it's false.

Also in my defense, suggesting an option compared to actually adding
the code is a lesser crime. Or is it?

Anyway I removed all the options from research cat, including -u. That
counts for something.

-rob

On Thu, Mar 5, 2020 at 3:19 AM John P. Linderman <jpl.jpl at 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 at 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 at cs.utah.edu).
>>    GNU enhancements by David MacKenzie (djm at 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=lifestory&pid=117597321
>>
>> 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 at math.utah.edu  -
>> - 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
>> - Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
>> -------------------------------------------------------------------------------