Re: [TUHS] head/sed/tail (was The Unix shell: a 50-year view)

["Theodore Y. Ts'o" <tytso@mit.edu>]

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