From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: *** X-Spam-Status: No, score=3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FAKE_REPLY_B,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 25040 invoked from network); 15 Jul 2021 21:27:23 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 15 Jul 2021 21:27:23 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 363509C83A; Fri, 16 Jul 2021 07:27:21 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 937729C7F1; Fri, 16 Jul 2021 07:26:55 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=planet.nl header.i=@planet.nl header.b="WvcvYsIZ"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 071279C7F1; Fri, 16 Jul 2021 07:26:49 +1000 (AEST) Received: from cpsmtpb-ews06.kpnxchange.com (cpsmtpb-ews06.kpnxchange.com [213.75.39.9]) by minnie.tuhs.org (Postfix) with ESMTP id 8CB129C7F0 for ; Fri, 16 Jul 2021 07:26:42 +1000 (AEST) Received: from cpsps-ews04.kpnxchange.com ([10.94.84.171]) by cpsmtpb-ews06.kpnxchange.com with Microsoft SMTPSVC(8.5.9600.16384); Thu, 15 Jul 2021 23:26:34 +0200 X-Brand: 7abm2Q== X-KPN-SpamVerdict: e1=0;e2=0;e3=0;e4=;e6=(e1=10;e3=10;e2=11;e4=10;e6=1 0);EVW:White;BM:NotScanned;FinalVerdict:Clean X-CMAE-Analysis: v=2.4 cv=G7Z/r/o5 c=1 sm=1 tr=0 ts=60f0a80a cx=a_idp_e a=LO2mTXPAMClkaqVt2RTykg==:117 a=soxbC+bCkqwFbqeW/W/r+Q==:17 a=x1i13A_MHe4A:10 a=kj9zAlcOel0A:10 a=e_q4qTt1xDgA:10 a=Sz_oyh0qSS-owGcx4JkA:9 a=CjuIK1q_8ugA:10 X-CM-AcctID: kpn@feedback.cloudmark.com Received: from smtp.kpnmail.nl ([195.121.84.12]) by cpsps-ews04.kpnxchange.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Thu, 15 Jul 2021 23:26:33 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=to:date:message-id:subject:mime-version:content-type:from; bh=/BB58ORJTJeVK+4SEDwTIM3WtsoI15/Alj9/aKgJjjU=; b=WvcvYsIZdlv2FVHk5tB80hmVL2MG/0SHx2sutzYe1W5qfGeveCvhC8ncGIJRFHCL939mr551Q1ufy 5WKAr/wdjvOVfh69fQXDc04TNRTJ+xse0hkd5VVhv09zUkq3Mjlp4oIqg8BIaona9v7dYOyGxeBpWp JNRpyVV9QoCQ7mM0= X-KPN-MID: 33|B/eb6XrKtX61w0dAPbkTNEcXckcZfqQKM3kcuYV8NIpFXxyNcLhRPVcc/0eBzHN 9hDRb4Z0Kybfhlf0gItkykQ== X-KPN-VerifiedSender: Yes X-CMASSUN: 33|1iV3Oe0qnnN9VooIOwdcFvIovqOjxP9yd9JhjJErHFphOi6w+Gy2QtJyPkeYSTQ 4eIlhee65mTzQVY6zXy4v6Q== X-Originating-IP: 80.101.112.122 Received: from mba2.fritz.box (sqlite.xs4all.nl [80.101.112.122]) by smtp.kpnmail.nl (Halon) with ESMTPSA id 5407a8af-e5b3-11eb-baae-00505699772e; Thu, 15 Jul 2021 23:26:33 +0200 (CEST) From: Paul Ruizendaal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <4FA4AAA0-B3B8-410C-8307-A3ECEDE60E2C@planet.nl> Date: Thu, 15 Jul 2021 23:26:33 +0200 To: TUHS main list X-Mailer: Apple Mail (2.3608.120.23.2.4) X-OriginalArrivalTime: 15 Jul 2021 21:26:33.0947 (UTC) FILETIME=[15F04AB0:01D779C0] X-RcptDomain: minnie.tuhs.org Subject: Re: [TUHS] head/sed/tail (was The Unix shell: a 50-year view) 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > Message: 7 > Date: Thu, 15 Jul 2021 10:28:04 -0400 > From: "Theodore Y. Ts'o"=20 > Subject: Re: [TUHS] head/sed/tail (was The Unix shell: a 50-year view) >=20 > On Wed, Jul 14, 2021 at 10:38:06PM -0400, Douglas McIlroy wrote: >> Head might not have been written if tail didn't exist. But, unlike = head, >> tail strayed from the tao of "do one thing well". Tail -r and tail -f = are >> as cringeworthy as cat -v. >>=20 >> -f is a strange feature that effectively turns a regular file into a = pipe >> with memory by polling for new data, A clean general alternative >> might be to provide an open(2) mode that makes reads at the current >> file end block if some process has the file open for writing. >=20 > OTOH, this would mean adding more functionality (read: complexity) > into the kernel, and there has always been a general desire to avoid > pushing into the kernel when it can be done in userspace. Do > you really think using a blocking read(2) is somehow more superior > than using select(2) to wait for new data to be appended to the file? >=20 > And even if we did this using a new open(2) mode, are you saying we > should have a separate executable in /bin which would then be > identical to cat, except that it uses a different open(2) mode? Yes, it would put more complexity into the kernel, but maybe it is = conceptually elegant. Consider a classic pipe or a socket and the behaviour of read(2) for = those objects. The behaviour of read(2) that Doug proposes for a file = would make it in line with that for a classic pipe or a socket. Hence, = maybe it should not be a mode, but the standard behaviour. I often think that around 1981 the Unix community missed an opportunity = to really think through how networking should integrate with the = foundations of Unix. It seems to me that at that time there was an = opportunity to merge files, pipes and sockets into a coherent, simple = framework. If the 8th edition file-system-switch had been introduced = already in V6 or V7, maybe this would have happened. On the other hand, the installed base was probably already too large in = 1981 to still make breaking changes to core concepts. V7 may have been = the last chance saloon for that. Paul