From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id d3fce7bf for ; Wed, 4 Mar 2020 17:27:04 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 3816B9D72D; Thu, 5 Mar 2020 03:27:03 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id D1DA49D71B; Thu, 5 Mar 2020 03:25:57 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id A1BB09D71B; Thu, 5 Mar 2020 03:25:54 +1000 (AEST) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by minnie.tuhs.org (Postfix) with ESMTP id 7354D9D68F for ; Thu, 5 Mar 2020 03:25:53 +1000 (AEST) Received: from [192.168.125.6] (ipad.bitblocks.com [192.168.125.6]) by mail.bitblocks.com (Postfix) with ESMTP id C1E8E156E413; Wed, 4 Mar 2020 09:25:31 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-18A6EA0B-ACDC-43EA-BBA6-E4F674DBCCE3 Content-Transfer-Encoding: 7bit From: Bakul Shah Mime-Version: 1.0 (1.0) Date: Wed, 4 Mar 2020 09:25:31 -0800 Message-Id: References: In-Reply-To: To: "John P. Linderman" X-Mailer: iPad Mail (17D50) Subject: Re: [TUHS] Command line options and complexity X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --Apple-Mail-18A6EA0B-ACDC-43EA-BBA6-E4F674DBCCE3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I missed knowing about tac till now. I=E2=80=99ve 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=3Dgetchar();if(c=3D=3DEOF)return;rev();putchar(c);} > On Mar 4, 2020, at 8:19 AM, John P. Linderman wrote: >=20 > =EF=BB=BF > The "statute of limitations" must have passed long ago, so I confess to ha= ving 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 migh= t go by without any activity, followed by a burst of logging activity. We of= ten wanted to see the most recent burst of activity, so "tail -f" wouldn't d= o the job. It would show the next burst of activity, which might not occur f= or quite some time. Somebody posted a functional equivalent on some netnews g= roup, 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 w= ould have been a disservice to other users. My version did reads of 512 byte= s 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 n= ightmare, so I "tossed my version over the wall", into the arms of Andy Tane= nbaum, as I recall. He made it public, attributed to "an unknown author". >=20 > I don't know how Rob Pike got ahold of it, but he recognized that mailbox f= iles had the same bursty growth. Unlike our log files, whose contents were a= cceptably understandable in reverse order, mail messages were hard to read i= n reverse order, so he proposed making it possible to recognize the headers a= t 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 opt= ion to "tac" was hard to overlook. >=20 > The version out there now was rewritten by Jay Lepreau, it seems: >=20 > /* > * 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. > */ >=20 > Dynamic buffer allocation rather than relying on the time-honored 512-byte= s-is-enough assumption was a positive, as was supporting Rob's suggestion. H= andling pipes strikes me as a waste of code, but hey, anything is better tha= n that version I replaced. >=20 >> On Wed, Mar 4, 2020 at 9:15 AM Nelson H. F. Beebe w= rote: >> Arnold Robbins writes: >>=20 >> >> 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. >>=20 >> That brought back memories, and to verify them, I checked the tac.c >> source code in the latest GNU coreutils test release. It says >>=20 >> /* Written by Jay Lepreau (lepreau@cs.utah.edu). >> GNU enhancements by David MacKenzie (djm@gnu.ai.mit.edu). */ >>=20 >> So my memory was right that my old friend Jay was the author. Sadly,=20 >> we lost him in September 2008: see >>=20 >> https://www.legacy.com/obituaries/saltlaketribune/obituary.aspx?p= age=3Dlifestory&pid=3D117597321 >>=20 >> Jay founded the influential Flux group in advanced networking research: >>=20 >> http://www.flux.utah.edu/profile/lepreau >>=20 >> -------------------------------------------------------------------------= ------ >> - 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@math.utah.= edu - >> - 155 S 1400 E RM 233 beebe@acm.org beebe@computer= .org - >> - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~be= ebe/ - >> -------------------------------------------------------------------------= ------ --Apple-Mail-18A6EA0B-ACDC-43EA-BBA6-E4F674DBCCE3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I missed knowing about tac= till now. I=E2=80=99ve used tail -r since
1982 when Y= ost pointed out that tail -r|rev was equivalent
to a t= oy recursive C program I had written to reverse a file.
He was almost right!

rev(= ){int c=3Dgetchar();if(c=3D=3DEOF)return;rev();putchar(c);}

On Mar 4, 2020, at 8:19 AM, John P. Lind= erman <jpl.jpl@gmail.com> wrote:

=EF=BB=BF
The "statute of limitations" must have p= assed 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 lo= gs 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 b= urst of activity, so "tail -f" wouldn't do the job. It would show the nex= t 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 lin= e. 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 dis= service to other users. My version did reads of 512 bytes on 512-byte bounda= ries, so it put much less load on the system. I couldn't bear to see somethi= ng like the netnews version
get adopted. The software release process at the Labs was a bure= aucratic 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 a= uthor".

I don't know how Ro= b Pike got ahold of it, but he recognized that mailbox files had the same bu= rsty growth. Unlike our log files, whose contents were acceptably understand= able in reverse order, mail messages were hard to read in reverse order, so h= e proposed making it possible to recognize the headers at the start of each m= ail message, and put the entire message out in readable order. I think that w= as a useful option, but the irony of Rob adding an option to "tac" was hard t= o overlook.

=
The version out= there now was rewritten by Jay Lepreau, it seems:

/*
 * tac.c - Print= file segments in reverse order
 *
 * Original line-only ver= sion by unknown author off the net.
 * Rewritten in 1985 by Jay Lepr= eau, Univ of Utah, to allocate memory
 * dynamically, handle string b= ounded segments (suggested by Rob Pike),
 * and handle pipes.
&nb= sp;*/

Dynamic bu= ffer allocation rather than relying on the time-honored 512-bytes-is-enough a= ssumption 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 versio= n I replaced.

On Wed, Mar 4, 2020 at 9:15 AM Nelson H. F. Beebe <beebe@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@cs.utah.edu).
   GNU enhancements by David MacKenzie (djm@gnu.ai.mit.edu). */

So my memory was right that my old friend Jay was the author.  Sadly, <= br> we lost him in September 2008: see

        https://www.legacy.com/obituaries/saltlaketribune/= obituary.aspx?page=3Dlifestory&pid=3D117597321

Jay founded the influential Flux group in advanced networking research:

        http://www.flux.utah.edu/profile/l= epreau

----------------------------------------------------------------------------= ---
- Nelson H. F. Beebe                &= nbsp;   Tel: +1 801 581 5254            &= nbsp;     -
- University of Utah                &= nbsp;   FAX: +1 801 581 4148            &= nbsp;     -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu = -
- 155 S 1400 E RM 233               =        beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math= .utah.edu/~beebe/ -
----------------------------------------------------------------------------= ---
= --Apple-Mail-18A6EA0B-ACDC-43EA-BBA6-E4F674DBCCE3--