Error opening terminal: screen.

That's the error message.
Code:
tcsh: The terminal database could not be opened.
tcsh: using dumb terminal settings.
It was working, what could be possibly wrong now?
Code:
$ ls -l /etc/termcap
lrwxr-xr-x  1 root  wheel  23 Nov  1  2012 /etc/termcap -> /usr/share/misc/termcap
 
Below is inside of screen session. After login it is set to xterm.
Code:
TERM=screen
TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal:\
 
Please check if /usr/share/misc/termcap contains a definition for "screen":
Code:
grep screen /usr/share/misc/termcap
This *should* be the case, but who knows ...
 
Yes it sure does, in addition, when I run env | grep TERM in another box where screen behaves normally I get the exact same response. So far I haven't found any differences between two boxes, just screen works in one and not in another. Me scratching head ...
 
Me scratching head ...
Same here. Have you tried another shell in [FONT=Courier New]screen[/FONT]? Does it show a similar behavior? If not, what's the version of the complaining tcsh? Is the same version running on your other system?
 
I tried with BASH, error is a little different but the message is the same - error opening the terminal.
 
Did you check the permission of /usr/share/misc/termcap and /usr/share/misc/termcap.db? ls -l /usr/share/misc/termcap*
 
Everything is installed from ports, the system is compiled from source, too. Permissions seem OK.
Code:
~]$ ls -l /usr/share/misc/termcap*
-r--r--r--  1 root  wheel   208384 Dec  3 09:53 /usr/share/misc/termcap
-r--r--r--  1 root  wheel  1343488 Dec  4 17:59 /usr/share/misc/termcap.db
 
Is the behavior of tcsh (and bash) limited to [FONT=Courier New]screen[/FONT], or does it behave similar without screen on an xterm or virtual console? If not, is sh -c 'TERM=screen tcsh' (without screen) working?
 
Just for my own reference in future:

Had this issue when using JuiceSSH client to connect to a FreeBSD box but fine when launching screen from the local directly attached console.

It turned out to be the terminal emulation mode of my client causing the above error message and the above error is the same if it cannot open the file or cannot find a match in the file.

Flipped client emulation to "VT100" or "xterm" from the "linux" default in the client and all is OK.
 
just in case this helps anyone else who finds this thread, i ran into this same issue when building 'screen' from ports on FreeBSD 11.2 today (i updated both base system and ports tree first). when i changed the TERM environment variable from 'xterm' to 'vt100' or 'screen' before running screen, that did fix the error, but i wasn't happy with that solution, it's another tweak/step that should not be necessary.

after a bit of testing changes to /usr/share/misc/termcap file and still seeing no change in screen's behaviour, i saw a few other people were reporting similar issues with a few other tools (not screen), and it looked to me like the common element was ncurses support.

removing the ncurses port from the system and rebuilding screen using base system copy of ncurses fixed the problem instantly for me, so this solved the issue on systems where i don't need ncurses from ports. i had to remove ncurses port entirely because just using 'make config' on the screen port build and telling it to use base system ncurses did not work while ncurses from ports was still installed/available.
 
just in case this helps anyone else who finds this thread, i ran into this same issue when building 'screen' from ports on FreeBSD 11.2 today (i updated both base system and ports tree first). when i changed the TERM environment variable from 'xterm' to 'vt100' or 'screen' before running screen, that did fix the error, but i wasn't happy with that solution, it's another tweak/step that should not be necessary.

after a bit of testing changes to /usr/share/misc/termcap file and still seeing no change in screen's behaviour, i saw a few other people were reporting similar issues with a few other tools (not screen), and it looked to me like the common element was ncurses support.

removing the ncurses port from the system and rebuilding screen using base system copy of ncurses fixed the problem instantly for me, so this solved the issue on systems where i don't need ncurses from ports. i had to remove ncurses port entirely because just using 'make config' on the screen port build and telling it to use base system ncurses did not work while ncurses from ports was still installed/available.
Thanks @yosmann you solved my problem, I'm using 13.0-Current
 
Back
Top