Remix.run Logo
Dylan16807 4 hours ago

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 2 hours 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 2 hours 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.

YZF an hour ago | parent [-]

You're right that it does not take input from the user. But I think you're in agreement with me that not everything is pipe-able.

The buffer in Unix (or rather C?) file output goes back to the beginning of time. It's not the pipe that's buffering.

Anyways, as soon as your mental model of these command line utilities includes the buffering then the behavior makes sense. How friendly it is can be debated. Trying to make it work with timers feels wrong and would introduce more complexity and deviate from some people's mental model.