On 2012-09-27, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Sep 28, 2012 at 8:25 AM, John Gordon <gor...@panix.com> wrote:
>> Isn't terminal output line-buffered? I don't understand why there would
>> be an output delay. (Unless the "\r" is messing things up...)
>
> This is a classic progress-indication case, which does indeed mess up
> line-buffering. The carriage return (and no line feed, done in the
> Python 2 style of a trailing comma) puts the cursor back to the
> beginning of the line, ready to overwrite, and ripe for one of those
> old favorite incomplete overwrite errors - if nFiles monotonically
> increases, it's fine, but if it decreases, the display can get ugly.
True, but that wasn't the problem here. The updates where. Thanks for the
given answer, I'll try it.
The scripts in question only increase numbers. But should that not be the
case, solutions are simple enough. The numbers can be formatted to have a
fixed size. In the case of random line contents (a list of filesnames, say)
it's enough to create an output function that is aware of the length of the
previously printed line, and add enough spaces to the current one to wipe
exess content.
Thanks again for the suggestion.
--
When in doubt, use brute force.
-- Ken Thompson
--
http://mail.python.org/mailman/listinfo/python-list
