Re: [dev] ii: how to process out in a pipeline and still page with less

From: Markus Wichmann <nullplan_AT_gmx.net>
Date: Sat, 28 May 2022 20:32:57 +0200

On Sat, May 28, 2022 at 06:09:04PM +0000, Hadrien Lacour wrote:
> Now, I wonder how it'd be fixed ("it" being how does the read end of the pipe
> signal to the write one the kind of buffering it wants) in a perfect world.

The problem ultimately stems from the mistaken idea that buffering is
invisible to the user. Which is true if the pipeline ultimately
terminates in a disk file or some such, but not if the pipeline
ultimately terminates on the terminal. But who knows if that is the
case? Pipelines ending in a call to "less" will terminate on the
terminal, pipelines ending in a call to "nc" will not. So the shell
can't know, only the last command can know.

So to make this work automatically, the last command would have to be
able to somehow inform all commands in the pipeline of its intentions.
Sadly, pipes are unidirectional, and in general it is impossible to
figure out the process on the other side of the pipe.

But even if that was possible, now what? Send a signal to the other side
to please unbuffer your output? That might actually work, but would
require each and every program to make intelligent decisions about how
to handle that signal. More importantly, it would require each and every
UNIX programmer to agree. Both on a signal and the behavior there, and
on the necessity of it all. Frankly, I have little hope for that ever
happening.

In a perfect world, yes, it could be done, but in a perfect world we'd
have brain-computer-interfaces so that the machines understand our
intentions. We'd not be stuck on emulations of 1960s teletypes to do the
same.

Besides, adding more automagic code that works different based on the
type of output device is going to make debugging shell scripts even
harder than it already is.

Ciao,
Markus
Received on Sat May 28 2022 - 20:32:57 CEST