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
