On Sat, May 28, 2022 at 08:32:57PM +0200, Markus Wichmann wrote: > 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.
The only solution would be to allow buffering to be passed through exec/posix_spawn, with a way to signal tools to not go through their heuristic logic. Then the shell could have a syntax to signal the pipeline buffering mode. Basically, another POSIX problem that can't be fixed =). [BLOG POST WARNING] A better solution would require departing from UNIX/POSIX and its minimalist API of "input: stdin/argv/signals in, output: stdout/stderr/return code out and FS for both". You know, years ago I found myself laughing at stuff like Lisp OSs or Spring as overly complex academic drivel, but the more I "progress" in computing, the more I learn of my error and understand UNIX as reactionary: rightly so, considering Multics and PL/I and the hardware of the time; but the reasons that made sense then don't now. Now that I'm infatuated with Common Lisp, functions instead of executables make perfect sense to me. In that case there would be no pipe and no buffering problem at all, since memory is shared and you're passing objects/pointers around instead of copying massive amounts of it via kernel.
