Wrapped lines create extra linefeed

[aleherb]

When sending a line which is as long as the console window width (a wrapped line) the following CR LF sequence to move the cursor to the next line is superfluous, because the terminal cursor position has implicitly moved to the next line already. This creates an extra empty line in the terminal client.

[rprichard]

This is one of the ways the Windows console and Unix terminals differ. After writing the last character in a line, the Windows console immediately advances by a line. A Unix terminal, on the other hand, moves the cursor to the position just after the last cell in the line. Line advancement doesn't happen until the first character of the next line is output, or if a CR is output, no advancement happens at all. (This behavior allows writing to the bottom-right cell.)

This can be verified using echo. It can be helpful to write out a "DSR", where the terminal reports the cursor position as keyboard input. e.g. echo -e "xxxxxx\e[6nyyyyyy\e[6n"

The current #21 fix will work for sequential output where the CRLF is redundant. I would expect it to break if a full line were instead modified. (Successive modifications should appear to walk up the terminal.) I think the fix could be modified to let the terminal wrap in some cases, but I'm concerned about how rewrapping terminals (e.g. the OS X terminal) would handle it.

What terminal are you using to display the output of winpty? (Perhaps you're using the Windows console?)

[aleherb]

I am viewing the output in the Eclipse Terminal view (which should actually behave like a Unix terminal), but I do see now that it does not handle the line wrap case in the same way as e.g. an xterm. Anyway, thanks for the hints! I'll close this bug and redirect the issue to the Eclipse Terminal view then.