Live data from Hacker News

What Unix pipelines got right and how we can do better

programmingsimplicity.substack.com

21–22 of 22 posts

Re: What Unix pipelines got right and how we can do better

#21

When cat writes to stdout, it doesn't block waiting for grep to process that data. It will certainly do that if the buffer is full. prevents the implicit blocking No, that's exactly the case of implicit blocking mentioned above. Does anyone else find this article rather AI-ish? The extreme verbosity and repetitiveness, the use of dashes, and "The limitation isn't conceptual—it's syntactic" are notable artifacts.

If anything, the pre-pipe style of prog1 -input input_file -output tmp1_file prog2 -input tmp1_file -output tmp2_file && del tmp1_file prog3 -input tmp2_file -output tmp1_file && del tmp2_file ... progN -input tmpX_file -output output_file && del tmpX_file is more in line with the author's claimed benefits of the pipes than the piped style itself. The process isolation is absolute, they are separated not just in spac…

File management suddenly becomes an issue. If old file tmp1_file remains from a previous run, then prog1 fails, you get "old" output. Pipes avoid file management entirely.

Re: What Unix pipelines got right and how we can do better

#22
I'm a big fan of how PowerShell passes objects.

But without a common runtime the closest you could really get to that in Unix would be to pass JSON or XML about, and have every program have a "pipe" mode that accepted that as input.

Which seems like an awful lot of work and unlikely to get the kind of buy in you'd need to make it work widely.

Post reply on HN