[Bug 58665] New: cmd incorrectly wraps text containing ANSI escape sequences
http://bugs.winehq.org/show_bug.cgi?id=58665 Bug ID: 58665 Summary: cmd incorrectly wraps text containing ANSI escape sequences Product: Wine Version: 10.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: cmd Assignee: wine-bugs(a)winehq.org Reporter: forestix(a)gaga.casa Distribution: --- Created attachment 79250 --> http://bugs.winehq.org/attachment.cgi?id=79250 reproducer: should print 3 lines; wine prints 4 lines Wine's cmd.exe prematurely inserts line breaks when a program's output contains non-printable ANSI escape sequences, such as those used to change colors. It looks as though Wine is counting not only the printable characters in the program's output, but also the non-printable ones, and using the total to decide where to insert a line break. Text that fits entirely on one line in a real Windows console is sometimes broken midway through the line, or followed by a blank line that should not be there, when run in an xterm using Wine. I am attaching a batch file that reproduces the problem. It should print 3 lines. The second line is identical to the others with the addition of some non-printable escape sequences. These characters should either occupy no width in the terminal (making the line length match the others) or be rendered as visible placeholder characters (as older Windows versions do). To see Wine handling it incorrectly, run it in an 80-column xterm or a similar terminal. Ideally, the output should look like this, with the head of line 2 in red: 79 chars _123456789_123456789_123456789_123456789_123456789_123456789_123456789 79 chars _123456789_123456789_123456789_123456789_123456789_123456789_123456789 79 chars _123456789_123456789_123456789_123456789_123456789_123456789_123456789 In wine, the output looks like this: 79 chars _123456789_123456789_123456789_123456789_123456789_123456789_123456789 79 chars _123456789_123456789_123456789_123456789_123456789_123456789_12 3456789 79 chars _123456789_123456789_123456789_123456789_123456789_123456789_123456789 Bug 49780 is related, but IMHO does not excuse this behavior. Regardless of whether virtual terminal sequences are supported, Wine should either print a character or not count it toward the length of a line when deciding where to wrap it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58665 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech(a)gmail.com --- Comment #1 from Eric Pouech <eric.pouech(a)gmail.com> --- there are several issues involved: 1) cmd.exe was erroneously breaking lines. funnily enough, this has been fixed yesterday (see [1]) 2) as already stated in bug 49780, conhost doesn't support yet ansi esc sequence (bug 49780), nor does it recognize them so it treats them as regular output, hence taking them into account when wrapping lines Note: this is the expected behavior when virtual terminal processing is not activated for the console (native does this as well) 2a) when using a unix console (eg. running ./wine cmd from unix prompt) output is sent to underlying unix terminal, which will handle the esc sequences (note: this will only work if the windows esc sequences matches the selected one in unix terminal; will likely work for color, bold, italic, but might break for more exotic ones) retested with [1] applied, and 79 is printed in red on second line as expected (yet wrapped as explained in 2) 2b) when using a windowed console (eg. running ./wine wineconsole cmd) same wrapping issue. however, the escape sequences are printed in short: - I can't repro the state you're reporting (esp sequence not printed but line wrapped). can you retest with [1] applied, and if the behavior you see doesn't match what's described above, please detail which console you're using (and if in 2a, which terminal emulator and which term settings) - we don't have anything in place for silencing the esc seq on output, and likely won't add it. - the only reasonable solution is to fix 49780 [1] https://gitlab.winehq.org/wine/wine/-/commit/adad7016757de9a53dab2dc688d14bb...) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58665 --- Comment #2 from Forest <forestix(a)gaga.casa> --- I tried with wine 10.14 + that patch, and again with wine 10.15 (unpatched because that commit is already present). The premature line wrapping persists. Tested in both Konsole and xterm. I configured the build with --enable-archs=i386,x86_64. Could that somehow be interfering with the patch? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58665 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Eric Pouech <eric.pouech(a)gmail.com> --- (In reply to Forest from comment #2)
I tried with wine 10.14 + that patch, and again with wine 10.15 (unpatched because that commit is already present). The premature line wrapping persists. Tested in both Konsole and xterm. what you should get when running in a unix term (xterm, konsole...) is 79 in red but line is wrapped (my previous wasn"t 100% clear) this is because conhost doesn't handle the escape sequences (and account them as real characters). ESC sequences are not erased by Wine, they're just passed as is to underlying unix terminal
to be fixed, this will require adding esc sequence support to conhost so closing as dupe of 49780 *** This bug has been marked as a duplicate of bug 49780 *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58665 --- Comment #4 from Forest <forestix(a)gaga.casa> --- I still don't understand why it's considered normal to insert line breaks when passing the characters through to a unix terminal. Why would the terminal need extra line breaks that are not present in the original character/byte stream? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58665 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Closing Duplicate -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla