5

I'm seeing some slightly odd behaviour when using GNU Screen 4.00.03 on a Red Hat Enterprise Linux 6.4 system.

If I connect without Screen, looking at the logs I can see each line is terminated with CRLF (0x0D 0x0A), exactly as expected.

If I connect and run Screen, lines with two or more characters are terminated with CRLF as expected. Lines with no printed characters (eg from running a bare echo) are terminated only with LF (0x0A), and most bizarrely of all, lines with a single printed character (eg echo x) are terminated with BSLF (0x08 0x0A).

I'm seeing this with PuTTY, and the above logs are from PuTTY logs. I'm also seeing this with automated Python frameworks using Pexpect, so I'm not blaming PuTTY for this.

What's going on? How do I stop it?

Improve this question
3
  • How do you check the line contents?
    – Hauke Laging
    May 17, 2013 at 13:44
  • echo $TERM. probably a difference in the screen termcap entry, and whatever your TERM is when not running screen.
    – Tim Kennedy
    May 17, 2013 at 13:47
  • @HaukeLaging: As noted in the question, I can see the line contents in the PuTTY logs and in Python using Pexpect.
    – me_and
    May 22, 2013 at 20:17

1 Answer 1

Reset to default
7

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.

Improve this answer
3
  • 2
    That covers what's going on. Now how can I stop it doing that? Can I disable icrnl and onlcr in the .screenrc?
    – me_and
    May 22, 2013 at 20:19
  • 1
    Right, I've done a little more digging and have a better idea of what's going on. What I want is to disable GNU Screen's reparsing of CRLF sequences. I don't care sufficiently about the optimizations it provides, and would prefer to have the output match the output without Screen as much as possible. Is that possible?
    – me_and
    May 23, 2013 at 12:48
  • It's not optimisation. screen is a terminal emulator. What you're trying to do is like capture the X11 traffic sent by xterm to try and figure out what the application in it is sending. Just have screen capture what it receives (Ctrl-A H)
    – Stéphane Chazelas
    May 23, 2013 at 13:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .