Fabric

When rewriting the I/O loop I had it print the line prefix after any line ending, meaning \n OR \r. I believe I did this because even during testing I ran into cases where a \r was present without a \n, though I'm not sure. It may have simply been pre-emptive on the assumption that somewhere, some program might be using \r as a newline terminator, or someone might be cat-ing such a file.

However, because at least some applications — such as colorized ls output — appear to use \r as, well, a carriage return without a newline, we end up with spurious blank, prefixed lines. This looks pretty bizarre, if not downright ugly.

Now, given that the captured text shouldn’t have this problem (since the only issue here is that we’re printing an extra prefix) it may not be a problem other than cosmetically, but even so, investigate whether a carriage return should be considered a valid line terminator on its own for our prefix-printing purposes. I'm thinking it shouldn’t be.