[Qemu-devel] [Bug 1407813] [NEW] QEMU wrongly translates newlines on serial output

[Qemu-devel] [Bug 1407813] [NEW] QEMU wrongly translates newlines on serial output

[Nadav Har'El]

Public bug reported:

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).

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
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:
  New

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

[Qemu-devel] [Bug 1407813] Re: QEMU wrongly translates newlines on serial output

[Tomasz Rostanski]

I think this bug relates to:
https://bugs.launchpad.net/qemu/+bug/1715296

-- 
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:
  New

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

[Qemu-devel] [Bug 1407813] Re: QEMU wrongly translates newlines on serial output

[Thomas Huth]

Patch has now been committed here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=12fb0ac0575df83cec72ec

** Changed in: qemu
       Status: New => Fix Committed

-- 
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 Committed

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

[Qemu-devel] [Bug 1407813] Re: QEMU wrongly translates newlines on serial output

[Thomas Huth]

** 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