Re^3: SLOW DOWN, you move too fast.....

First, you have no way of knowing how many bytes were printed, so you have no idea if the number of bytes is a multiple of a reasonable buffer size. How then can you claim the buffering is weird?

Second, the number of bytes that didn't print is even more telling. Could 73 lines fit in a normal buffer? Probably.

Thirdly, why do you assume he's printing to a tty? To count the lines exactly, he probably redirected stdout. That disables line buffering.

Finally, that a line was only partially printed is a very good indicator of a buffering problem.

Comment on Re^3: SLOW DOWN, you move too fast.....

Replies are listed 'Best First'.
Re^4: SLOW DOWN, you move too fast..... by chromatic (Archbishop) on Aug 09, 2006 at 03:33 UTC
...you have no way of knowing how many bytes were printed... I gave the minimum lower bound. Second, the number of bytes that didn't print is even more telling. I repeat your first assertion. How do you know the number of bytes that didn't print? Thirdly, why do you assume he's printing to a tty? In the absence of any other information, what else is there to assume? To count the lines exactly, he probably redirected stdout. That disables line buffering. The OP had to notice the problem before deciding to count the lines exactly. There's no way of knowing without more information. You might as well assume `$\|++` somewhere in the program. Finally, that a line was only partially printed is a very good indicator of a buffering problem. ...or unexpected data, such as `\r` or `\b` characters.	[reply] [d/l] [select]
Re^5: SLOW DOWN, you move too fast..... by ikegami (Patriarch) on Aug 09, 2006 at 04:02 UTC
Why are you trying so hard to prove that buffering is not a possibility? Maybe you should be spending your efforts on finding alternate causes if you think it's not buffering. I gave the minimum lower bound. If the buffer fills up once, there will be X bytes outputed. If the buffer fills out twice, there will be 2X bytes outputed. If the buffer fills out three times, there will be 3X bytes outputed. etc. The only time the minimium lower bound on the numer of bytes actually printed matters if it's lower than a reasonable X. 512, 1024, 4096 bytes are all reasonable Xs, so that's not the case here. If you wanted to show weird buffering, you'd have to show the exact number of bytes printed is not a multiple of a reasonable X. The minimium lower bound on the numer of bytes actually printed is totally useless to this end. How do you know the number of bytes that didn't print I don't. But I didn't make claims of weird buffering. In the absence of any other information, what else is there to assume? Who says you should make an assumption? And if there's truly no other information, you could always assume the opposite. ...or unexpected data, such as \r or \b characters. That would give the appearance of starting halfway, not stopping halfway.	[reply]