[TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Theodore Y. Ts'o
tytso at mit.edu
Fri Jul 16 00:28:04 AEST 2021
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?
> -r is weird because it enables backwards reading, but only as
> limited by count. Better would be a program, say revfile, that simply
> reads backwards by lines. Then tail p has an elegant implementation:
> revfile p | head | revfile
I'll note, with amusement, that -r is one option which is *NOT* in the
GNU version of tail. I see it in FreeBSD, but this looks like a
BSD'ism. So for those like to claim that the GNU utilities have laden
with useless options, this is one which can't be left at the feet of
GNU coreutils.
- Ted
More information about the TUHS
mailing list