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 7 months 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 7 months 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.

▲

kiitos 7 months ago | parent [-]

> `tail -f | grep` is like `vim | grep` or `rogue | grep`

I think this position is user-hostile.

`vim` and `rogue` are fully user-interactive programs. The same is not true of `tail -f`, which by default appears to users as a stream of lines.

I understand why, at a technical level, `tail -f | grep` doesn't work in the way that's expected here. But it should! At least, when invoked from a user-interactive shell session -- in that context, a "chunk of data" is clearly expected to be a newline-delimited line, not a buffer of some implicitly-defined size.

▲

dullcrisp 7 months ago | parent [-]

In fact, `tail -f | grep` works the way they expect. What doesn’t work is `tail -f | grep | grep`.

It’s hard to argue that grep isn’t supposed to work like this when grep tries to work like this. It’s not a fundamental tension, it’s just that isatty(stdout) doesn’t always tell you when you’re running in an interactive terminal.

	▲	YZF 7 months ago \| parent [-]
		That's a good point. If the proposal is to propagate that all the way through the pipe chain I'd support that. My gut negative reaction is to the complexity of adding flush timers.

▲

Dylan16807 7 months 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 7 months 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 7 months 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 7 months 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.

	▲	Dylan16807 7 months ago \| parent [-]
		The not-buffering when attached to a terminal also goes back the beginning of time. I don't see any particular reason for a pipe to be more like a file than a terminal. And I don't see why my mental model should be file-like and only file-like. > Trying to make it work with timers feels wrong and would introduce more complexity and deviate from some people's mental model. Oh, that's the specific proposed fix you meant. Okay, I can see why you'd dislike that, but I would say that forcing line mode doesn't have those downsides.