From: Thomas Huth <1407813@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [Bug 1407813] Re: QEMU wrongly translates newlines on serial output
Date: Wed, 15 Aug 2018 07:25:45 -0000 [thread overview]
Message-ID: <153431794702.8562.18336630446601945847.launchpad@wampee.canonical.com> (raw)
In-Reply-To: 20150105223623.22315.6307.malonedeb@gac.canonical.com
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1407813
Title:
QEMU wrongly translates newlines on serial output
Status in QEMU:
Fix Released
Bug description:
When using "-serial stdio", QEMU shows the guest serial port's output
on the tty running qemu. As it should, QEMU sets the tty to raw mode.
Or almost... Strangely, it neglects to remove one output-translation
bit, ONLCR (see termios(3)) enabled on the tty. And it should have
removed this output translation!
The problem is that with this ONLCR, the guest has no way of
outputting a bare linefeed ('\n') - every time the guest tries to
output a bare linefeed to the serial port, the host tty will translate
it to \r\n which will be sent to the underlying terminal (e.g.,
xterm).
In most cases, this issue doesn't cause a problem: When the guest is
running a Unix-like operating system which is itself in cooked mode,
the guest itself will always output \r\n, and the hosts second
translation (to \r\r\n) does no harm. But in certain cases, the guest
can *really* want to output just \n, and have this \n reach the
terminal emulator and do what a linefeed is supposed to do without a
carriage-return - namely - just go one line down in the same column.
As an illustration of this bug, consider a guest running a Unix-like
operating system running a curses-based application (e.g., "vi"). If
you look at the output of "infocmp xterm", you'll notice that cud1=^J.
This means that if the curses library decides to move one line down
(it can happen in some cursor movement situations) it might decide to
print a linefeed (\n) to move one line down. The guest's operating
system will not mess with this linefeed (because the guest is in raw
mode), but then qemu's tty, because it was wrongly left in ONLCR mode,
will change this \n to \r\n before it reaches the terminal - causing
wrong cursor movement (instead the cursor going straight down, it
moves to the first column of the next line).
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1407813/+subscriptions
prev parent reply other threads:[~2018-08-15 7:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-05 22:36 [Qemu-devel] [Bug 1407813] [NEW] QEMU wrongly translates newlines on serial output Nadav Har'El
2017-09-06 5:40 ` [Qemu-devel] [Bug 1407813] " Tomasz Rostanski
2018-06-04 12:34 ` Thomas Huth
2018-08-15 7:25 ` Thomas Huth [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=153431794702.8562.18336630446601945847.launchpad@wampee.canonical.com \
--to=1407813@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.