The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Paul Ruizendaal <pnr@planet.nl>
To: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Date: Thu, 15 Jul 2021 23:26:33 +0200	[thread overview]
Message-ID: <4FA4AAA0-B3B8-410C-8307-A3ECEDE60E2C@planet.nl> (raw)


> Message: 7
> Date: Thu, 15 Jul 2021 10:28:04 -0400
> From: "Theodore Y. Ts'o" 
> Subject: Re: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)
> 
> 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.
>> 
>> -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.
> 
> OTOH, this would mean adding more functionality (read: complexity)
> into the kernel, and there has always been a general desire to avoid
> pushing <stuff> 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?
> 
> 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


             reply	other threads:[~2021-07-15 21:27 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-15 21:26 Paul Ruizendaal [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-07-18 20:07 Douglas McIlroy
     [not found] <CAKH6PiW58PDPb5HRi12aKE+mT+O8AjETr9R51Db6U3KcEp_KkA@mail.gmail.com>
2021-07-16 14:17 ` Nelson H. F. Beebe
2021-07-16 16:13   ` Theodore Y. Ts'o
2021-07-16 12:09 Douglas McIlroy
2021-07-16 14:32 ` Bakul Shah
2021-07-15 22:26 Nelson H. F. Beebe
2021-07-15 23:18 ` Jim Davis
2021-07-16  0:02   ` John Floren
2021-07-16  1:02     ` Nelson H. F. Beebe
2021-07-16  8:27     ` Lars Brinkhoff
2021-07-16 15:28       ` John Floren
2021-07-16  0:02 ` Clem Cole
2021-07-16  0:25   ` Nelson H. F. Beebe
2021-07-16  8:50     ` Lars Brinkhoff
2021-07-15 22:00 Douglas McIlroy
2021-07-15 22:12 ` John Cowan
2021-07-15 19:01 Norman Wilson
2021-07-15 19:27 ` Clem Cole
2021-07-15 19:28   ` Clem Cole
2021-07-15 19:34   ` Warner Losh
2021-07-16  7:38     ` arnold
2021-07-16 16:09       ` Warner Losh
2021-07-16  8:05   ` Lars Brinkhoff
2021-07-16 14:19     ` Clem Cole
2021-07-17  0:34       ` Charles Anthony
2021-07-15 16:54 Nelson H. F. Beebe
2021-07-15 15:44 Norman Wilson
2021-07-15  2:38 Douglas McIlroy
2021-07-15  4:19 ` arnold
2021-07-15  4:25   ` Adam Thornton
2021-07-15  7:20   ` Thomas Paulsen
2021-07-15 14:28 ` Theodore Y. Ts'o
2021-07-15 22:29 ` Bakul Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FA4AAA0-B3B8-410C-8307-A3ECEDE60E2C@planet.nl \
    --to=pnr@planet.nl \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).