Re: [Fab-user] status of "occasional droped lines of output" bug 32

[Xinan Wu]

this was my fix, but it's a bit ugly... please try and at least make
sure functionality is fixed.

=== quoted ealier email ===

The reason is .splitlines() does not put an empty str at the end of
array when the last char in out is \n, so the leftover logic is
incorrect. (I am using python 2.5, don't know if 2.6 changes this,
unlikely though)

The code in old 0.1.1 was in fact pretty solid except it didn't handle
\r case. The patch I included in my first email wasn't as solid.
Here's a probably better fix but still a bit ugly :)

diff -ur fabric-0.9b1-original/fabric/network.py fabric-0.9b1/fabric/network.py
--- fabric-0.9b1-original/fabric/network.py     2009-07-02
21:36:15.000000000 -0700
+++ fabric-0.9b1/fabric/network.py      2009-07-12 23:56:45.000000000 -0700
@@ -319,9 +319,10 @@
            # leftovers, if any.
            if '\n' in out or '\r' in out:
                parts = out.splitlines()
+                if out[len(out)-1] in '\r\n':
+                    parts.append('')
                line = leftovers + parts.pop(0)
-                if parts:
-                    leftovers = parts.pop()
+                leftovers = parts.pop()
                while parts or line:
                    # Write stderr to our own stderr.
                    out_stream = stderr and sys.stderr or sys.stdout

On Fri, Aug 7, 2009 at 7:25 AM, Steve Steiner
(listsin)<address@hidden> wrote:
>
> On Aug 6, 2009, at 10:36 PM, Carl Zmola wrote:
>
> I have reproduced this at home and at work.
>
> Apparently, someone has a 100% reproducible case on his local machine.
> My Spidey sense is tickled in three areas.
> 1> Non-flushing on the remote side
> 2> Manglement on the receiving side
> 3> Thread shenanigans with filling up the output list
> I think 2 is most likely (and easiest to test/diagnose anyway).
> The return string is handled by passing an empty list to the thread to be
> filled up.
> Then a simple "".join() is being applied to that result.
> I'm guessing that there's an encoding/string/buffer type mismatch and things
> are not joining properly rather than the output buffer on the other side not
> being flushed.
> If whoever has a reproducible local case could put some debugging output in
> operations.py around line 435 to dump out the contents of 'capture' before
> it's "".joined, I'm gonna' bet that the reason for the missing data will
> become apparent pretty quickly.
> Thanks,
> S
>
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>
>