line buffering problem with `less'
Fergus Henderson
Processing foo... done.
where the "Processing foo... " is output, the program does some
slow computation, and eventually the "done\n" is output.
When I pipe this program into `less', the program does its
slow computation, and then eventually "Processing foo... done\n"
is output all at once. Note that my program _is_ flushing it's
buffer after the "Processing foo..." is done, and piping it into
`cat -u' instead of `less' works fine, so the problem is with
`less', not with my program.
It would be good if `less' would output characters to the screen
as they are recieved, rather than waiting for a complete line
to be recieved before displaying any of it. (Or alternately
it could be a command-line option rather than the default.)
--
Fergus Henderson - f...@munta.cs.mu.OZ.AU
Francois Pinard
slow computation, and then eventually "Processing foo... done\n"
is output all at once. Note that my program _is_ flushing it's
buffer after the "Processing foo..." is done, and piping it into
`cat -u' instead of `less' works fine, so the problem is with
`less', not with my program.
The program less studies whole input lines for detecting overstrike
characters, and "renders" them as underlined, bold or reverse video.
Unless a line is complete, less has no way to know if the last
character obtained by a physical read would not become overstroke by
the next read.
less could probably not be modified to satisfy your particular need
without breaking it seriously for most other usages. Doing nothing
about it is probably our best move, here.
--
Franc,ois Pinard ``Vivement GNU!'' pin...@iro.umontreal.ca
About the League for Programming Freedom? Email me or l...@uunet.uu.net
Juergen Weigert (Inf4 - hiwi)
> slow computation, and then eventually "Processing foo... done\n"
> is output all at once. Note that my program _is_ flushing it's
> buffer after the "Processing foo..." is done, and piping it into
> `cat -u' instead of `less' works fine, so the problem is with
> `less', not with my program.
>
> The program less studies whole input lines for detecting overstrike
> characters, and "renders" them as underlined, bold or reverse video.
> Unless a line is complete, less has no way to know if the last
> character obtained by a physical read would not become overstroke by
> the next read.
Valid point, Francois...
...but shouldn't less have a "raw" option, where it does not process
backspacing and overstrike at all? I'd appreciate this, cause when
viewing binary files one may not see an expected string, because of
following backspaces or carriage returns. This can be quite confusing
and I often switch between vi and less to verify the output.
Furthermore, the above request could easily be added, as soon as such
a "raw" mode exists.
Just an idea...
juergen.
--
Juergen Weigert >> jnwe...@uni-erlangen.de <<
One pizza, One beer, two t-shirts, thousand bug-reports and still no money...
Bagheera: ``It's not funny. -- Let's get out of here quick!''