16 Jul
2021
16 Jul
'21
3:26 a.m.
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:
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
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?