That's an optimisation done by screen
.
When you type echo<Cr>
in screen
. Because of the local echo and the icrnl
and onlcr
settings of the pseudo terminal device in the screen
window, the \r\n
sequence is sent to master side (to screen).
screen
implements a terminal emulator where \r
is meant to bring the cursor to the beginning of the line and \n
to move the cursor down. To do that, where a terminal emulator like xterm would do X API calls to move the cursor to the beginning of the line, screen
has to send escape codes to the host terminals it is attached to to tell it/them to move the cursor to the left hand side of the screen window.
In case you've split the window vertically, that means send cursor positioning escape sequences to wherever the left hand side of the screen windows is. If not or if on the left hand side of the host terminal, screen
would just pass those \r
and \n
characters along so that the cursor be moved to the beginning of the line and one line down on the host terminal as well (since all terminals treat \r
and \n
the same in that instance).
Now, echo
runs and outputs a \n
character. Because of onlcr
again in the screen
window tty, screen
receives \r\n
again. \r
tells it to move to the beginning of the line, but the cursor is already at the beginning of the line, so no need to do anything which is why the host terminal doesn't receive a second \r
character. Then to move the cursor down because of the \n
it receives, screen
sends \n
to the host terminal.
You can verify that by running in screen:
printf '\r\r\r\r'
You'll notice that screen
only sends one \r
character to its host terminal.
screen
termcap entry, and whatever your TERM is when not running screen.