| ▲ | YZF 3 hours ago |
| I would tend to disagree. The buffering here is doing what's it's supposed to be. The mix of something that's supposed to be interactive with a contract that's not meant to be interactive is the source of the problem (tail following into a pipe). There's no real problem to solve here. The "hardware" analog is a tank of water that accumulates rainwater and you only move it somewhere when it fills up. I'm not sure what examples you have in mind but time based flushes aren't common in hardware AFAIK. The proposed fix makes the contract a lot more complicated. |
|
| ▲ | dullcrisp 2 hours ago | parent | next [-] |
| How is there no problem to solve when the post clearly identifies a problem, as well as why the behavior is confusing to a user? “The system is working as it was designed,” is always true but unhelpful. |
| |
| ▲ | YZF 18 minutes ago | parent [-] | | I get that. But it's like complaining why your pliers aren't good at unscrewing a bolt. I'm willing to accept the UX isn't great but `tail -f | grep` is like `vim | grep` or `rogue | grep` (I'm exaggerating to try and make a point). `tail -f` is also if I'm not mistaken a much more recent development vs. the origins of the Unix command line pipes. So sure, it would maybe be a better UX to be able to combine things and have them work, but there is fundamental tension between building something that's optimized for moving chunks of data and building things that's interactive. And trying to force one into the other, in my humble opinion, is not the solution. |
|
|
| ▲ | Dylan16807 2 hours ago | parent | prev [-] |
| What are you saying is "not meant to be interactive"? That's not true of pipes in general, or of grep in general. Or, even if it is true of pipes, then we need an alternate version of a pipe that signals not to buffer, and can be used in all the same places. It's a real problem either way, it just changes the nature of the problem. > The proposed fix makes the contract a lot more complicated. How so? Considering programs already have to deal with terminals, I'm skeptical a way to force one aspect of them would be a big deal. |
| |
| ▲ | YZF 15 minutes ago | parent [-] | | Sure. An alternative for combining interactive terminal applications might be interesting. But I think there is tension between the Unix mechanisms and interactive applications that's not easy to resolve. What's `less | grep` or `vim | grep`... do we need to send input back through the pipe now? It's one of those things you get used to when you've used Unix-like systems long enough. Yes, it's better things just work as someone who is not a power user expects them to work but that's not always possible and I'd say it's not worth it to try to always meet that goal, especially if it leads to more complexity. | | |
| ▲ | Dylan16807 3 minutes ago | parent [-] | | > But I think there is tension between the Unix mechanisms and interactive applications that's not easy to resolve. I would say that the platonic ideal of the pipe Unix mechanism has no buffering, and the buffer is only there as a performance optimization. > What's `less | grep` or `vim | grep`... do we need to send input back through the pipe now? Well, this is "interactive" in the timing sense. It still has one-way data flow. That's how I interpreted you and how I used the word. If you meant truly interactive, then I think you're talking about something unrelated to the post. |
|
|
