screen displays ""TERMCAP", line 20, col 1, terminal 'SC': Missing separator"

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #48662.

[youvegotmoxie@…]

Can you provide a little more information so I can try to recreate the issue?

Screen works properly here.

[sime@…]

I recently upgraded bash and I believe since then I see the same error each time I run ls.

I have commented out .screenrc and .profile though the problem persists.

[ericmoret]

Same problem here

[youvegotmoxie@…]

Try rebuilding bash and screen making sure you're using the latest version of ncurses.
I use zsh as my shell but just installed bash to see if I can duplicate your bug, I do not see ""TERMCAP", line 20, col 1, terminal 'SC': Missing separator" when issuing the ls command.

mike@snafu-mac:~/ > /opt/local/bin/bash
bash-4.3$ /opt/local/bin/bash --version
GNU bash, version 4.3.42(1)-release (x86_64-apple-darwin14.5.0)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
bash-4.3$ ls
Applications Documents Movies Pictures gitlab macports-svn
ClamXAV-Quar Downloads Music Public local-scripts mbox
Desktop Library NFS Sync macports-local patches
bash-4.3$
bash-4.3$ screen -ls
There is a screen on:

9824.test (Attached)

1 Socket in /tmp/screens/S-mike.
bash-4.3$ screen --version
Screen version 4.03.01 (GNU) 28-Jun-15
bash-4.3$

[sime@…]

What is the desired way to rebuild a port in this case?

Also an another interesting error when I run top on a remote system:

$ top
'screen.xterm-256color': unknown terminal type.

[sime@…]

Okay, I can silence the error if I run ls in the following ways:

$ TERM=screen-256color ls
$ TERM=xterm ls

[vlsd (Vlad)]

I get this error every time I start screen after a recent update. I'm using zsh and I've narrowed it down to either something in my .zshrc or oh-my-zsh. However, something definitely changed in the screen code base, since this started happening right after an update to screen, with no other changes on my machine.

[youvegotmoxie@…]

Replying to sime@…:

What is the desired way to rebuild a port in this case?

Also an another interesting error when I run top on a remote system:

$ top
'screen.xterm-256color': unknown terminal type.

# port upgrade --force ncurses screen bash

[dgsb (David Bariod)]

I just fall on the same issue. It seems that it is related with the Terminal.app OS X application configuration. Screen or its child processes does not seem to handle well the content of the TERM variable when it holds xterm-256color prior starting the screen command.

[tdy@…]

Replying to youvegotmoxie@…:

mike@snafu-mac:~/ > /opt/local/bin/bash
bash-4.3$ /opt/local/bin/bash --version
GNU bash, version 4.3.42(1)-release (x86_64-apple-darwin14.5.0)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
bash-4.3$ ls
Applications Documents Movies Pictures gitlab macports-svn
ClamXAV-Quar Downloads Music Public local-scripts mbox
Desktop Library NFS Sync macports-local patches
bash-4.3$
bash-4.3$ screen -ls
There is a screen on:

9824.test (Attached)

1 Socket in /tmp/screens/S-mike.
bash-4.3$ screen --version
Screen version 4.03.01 (GNU) 28-Jun-15
bash-4.3$

I'm not sure if there were some truncated commands here, but I don't see an ls command inside a screen session itself. That's how I'm duplicating the issue on my end. I only see an ls outside of screen and a screen -ls to list screens, but the main issue is running ls after opening screen.

[ojkastl]

Any news on this issue? I still have this, every time I open screen.

Macports 2.3.5 on OSX 10.12

[eastpole (tai viinikka)]

Indeed, every time I start a screen:

"TERMCAP", line 20, col 1, terminal 'SC': Missing separator
tai@recluse:~$screen --version 
Screen version 4.06.02 (GNU) 23-Oct-17
tai@recluse:~$uname -a 
Darwin recluse 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
tai@recluse:~$port -v 
MacPorts 2.5.4
Entering shell mode... ("help" for help, "quit" to quit)

I'd like to help resolve this -- let me know if more info is required or if we need to file a bug in screen at GNU.

[mkultra329 (Matt Kokidko)]

This occurred on my system when I opened up the system terminal. WhenI opened iTerm it prompted me to grant full disk access to iTerm in system settings. After I did this the error stopped showing up in the system terminal. Can anyone else verify if this will do the same for them?

[dgilman (David Gilman)]

I opened this bug with GNU screen over the summer, it hasn't moved since: ​https://savannah.gnu.org/bugs/?54556

I noticed it had to do with a term variable of xterm-256color, and probably the hyphen in that name. screen has its own code to generate a TERMCAP environment variable and as far as I know there is some sort of bug with its generation of TERMCAPs that it isn't handling something right.

I'm not a curses wizard but it appears that this whole TERMCAP environment variable business is archaic. I looked for a way to drop it entirely (some sort of compile-time flag?) but this TERMCAP generation was wedded pretty heavily into GNU screen. I think I need feedback from the upstream about how to proceed from here on out.

[Scott Shambarger <devel@…>]

In 4e83768a2da5ff16752c4dd07b4a729e63f78908/macports-ports (master):

screen: limit termcap, fix blanker, fix error messages

Screen creates invalid TERMCAP entries for full featured terminals
like xterm-256color. Adds patch to limit the size of TERMCAP
to 1023 characters by skipping some function keys but keeping
important navigation keys.

Screen currently fails to run blanker when suid root. Adds patch
to correctly prepare the PTY before running the blanker. Also
allows errors to be displayed when blanker is blocking the display.

When screen fails in a child process and is suid root, the Panic
message isn't sent as the Panic process also Panics. Adds patch
to correctly set the internal effective uid so that error messages
are sent to the parent. Also fixes children to not remove the
screen socket when they Panic.

I've submitted all patches upstream, but it appears the maintainers
don't often push new screen releases.

Closes: #48661