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.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, 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 f8acdfff for ; Wed, 4 Mar 2020 16:18:53 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id A4F739D723; Thu, 5 Mar 2020 02:18:51 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 260EC9D71B; Thu, 5 Mar 2020 02:18:16 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="VYjilbrW"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 983479D71B; Thu, 5 Mar 2020 02:18:13 +1000 (AEST) Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) by minnie.tuhs.org (Postfix) with ESMTPS id E9BB89D68F for ; Thu, 5 Mar 2020 02:18:12 +1000 (AEST) Received: by mail-vs1-f44.google.com with SMTP id a19so1511212vsp.6 for ; Wed, 04 Mar 2020 08:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4OuRkKfTBdDMwcPyJWyEAGXEA5kkdRXUKvMwNrfQ0jw=; b=VYjilbrW1UmGd4QdH0aPvNTriKfL6naxBHajR4BUrQUo0frn4Hpt7JSm/i3ifys7Gu wHmMSVogudL+LR95jXt6AnRWu5TuYxrp1KAzXV0kWSkUIwtwgdWoqzdguRI55+usOUwF /EyrjEtwIKociWaPPo05D+jvEU4aVhy2/xKSRPN2/0DXCVqkup4XJWlChGdkdv2Ss3LC PbjVmPk9InDI+L/iHPEoEQh9MWhThxGqb2RNO84zAhgzvD67PsC0htJRwmU8O5PagWTS YpWAl5CZ0y57FHO5CBlHr9O8kCuQvYkvU15m/LBdiosVaOonpMjdrhlBO/UxhlBinhoA TLrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4OuRkKfTBdDMwcPyJWyEAGXEA5kkdRXUKvMwNrfQ0jw=; b=Y7dGOA7SQzzysVr6mTqwFwuJnfc5OeEB0ZRTstnElkRigJzA/Jd1dwiCZ1LImtBhB6 aTLZekpIueTDEloRwDtISQQ6sLfEJ3WnhAFqaI6WgUy7b+9TVQyfnnbqt14Bci2+Babi PItz4rOmAy9g79h0/M2JelIBR7eTVCn0ke1KsfifgQI60O6HxEM7iTSoeENXcohdHb20 reH9Z93E76O+pHROlnofGaFCuNVsr9DJfXQA7191TTvqaxjPD4C9hu2B5F4Ukew61CQc xabhob36NY415VJerq0IH7LReshTdhQ3FAKyRg3a74Lgk9TOktzXbC0YqFTOYJopwVpk /wWw== X-Gm-Message-State: ANhLgQ2QGskrKNMAxQbkenRno7Q5xJelTATiCaDWf4HqwCRA2zjFhNTL 2Sa8psGzo8JDY3emKzFvmGKap+LfSQD7wp5kpVE= X-Google-Smtp-Source: ADFU+vsjIvUrJl6FHfz+w4658lp4JdMCl49hhjudsH/F73A3KOVa713kG7NUJmHD4yEmWj4HBg91cbK3/esa32apsYQ= X-Received: by 2002:a67:f585:: with SMTP id i5mr2227420vso.52.1583338691693; Wed, 04 Mar 2020 08:18:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "John P. Linderman" Date: Wed, 4 Mar 2020 11:17:46 -0500 Message-ID: To: "Nelson H. F. Beebe" Content-Type: multipart/alternative; boundary="00000000000047104705a009c416" 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" --00000000000047104705a009c416 Content-Type: text/plain; charset="UTF-8" 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 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, > 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@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/ - > > ------------------------------------------------------------------------------- > --00000000000047104705a009c416 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 work= ing on a project that wrote log files, but the logs were very "bursty&= quot;. Minutes might go by without any activity, followed by a burst of log= ging activity. We often wanted to see the most recent burst of activ= ity, so "tail -f" wouldn't do the job. It would show the n= ext burst of activity, which might not occur for quite some time. Someb= ody posted a functional equivalent on some netnews group, but it was gha= stly. I think it did seeks of -1 characters at a time to accumulate eac= h line. That would have been fast enough to feed our pathetic 1200 baud ter= minals, but it would have beat the system to death, and that would have bee= n a disservice to other users. My version did reads of 512 bytes on 512-byt= e boundaries, so it put much less load on the system. I couldn't bear t= o 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 wa= ll", 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 fi= les, whose contents were acceptably understandable in reverse order, mail m= essages were hard to read in reverse order, so he proposed making it possib= le 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 no= w was rewritten by Jay Lepreau, it seems:

/*
=C2=A0* tac.c - Print file = segments in reverse order
=C2=A0*
=C2=A0* Original line-only version = by unknown author off the net.
=C2=A0* Rewritten in 1985 by Jay Lepreau,= Univ of Utah, to allocate memory
=C2=A0* dynamically, handle string bou= nded segments (suggested by Rob Pike),
=C2=A0* and handle pipes.
=C2= =A0*/

Dynamic = buffer allocation rather than relying on the time-honored 512-bytes-is-enou= gh assumption was a positive, as was supporting Rob's suggestion. Handl= ing pipes strikes me as a waste of code, but hey, anything is better than t= hat version I replaced.

On Wed, Mar 4, 2020 at 9:15 AM Nelson H. F. B= eebe <beebe@math.utah.edu>= wrote:
Arnold R= obbins writes:

>> There was no tac in V7 Unix. It was first posted to USENET, I don&= #39;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.=C2=A0 It says

/* Written by Jay Lepreau (lepreau@cs.utah.edu).
=C2=A0 =C2=A0GNU enhancements by David MacKenzie (djm@gnu.ai.mit.edu). */

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.legacy.com/obituaries/saltlaketribu= ne/obituary.aspx?page=3Dlifestory&pid=3D117597321

Jay founded the influential Flux group in advanced networking research:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.flux.utah.edu/profile= /lepreau

---------------------------------------------------------------------------= ----
- Nelson H. F. Beebe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 Tel: +1 801 581 5254=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 -
- University of Utah=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 FAX: +1 801 581 4148=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 -
- Department of Mathematics, 110 LCB=C2=A0 =C2=A0 Internet e-mail: beebe@math.utah.edu= =C2=A0 -
- 155 S 1400 E RM 233=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0beebe@acm.org=C2=A0 beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA=C2=A0 =C2=A0 URL: http://www.ma= th.utah.edu/~beebe/ -
---------------------------------------------------------------------------= ----
--00000000000047104705a009c416--