# Error opening terminal: screen.



## Speedy (Dec 4, 2017)

That's the error message. 

```
tcsh: The terminal database could not be opened.
tcsh: using dumb terminal settings.
```
It was working, what could be possibly wrong now?

```
$ ls -l /etc/termcap
lrwxr-xr-x  1 root  wheel  23 Nov  1  2012 /etc/termcap -> /usr/share/misc/termcap
```


----------



## mrclksr (Dec 4, 2017)

Try to recreate /usr/share/misc/termcap.db:

```
# cap_mkdb /usr/share/misc/termcap
```


----------



## Speedy (Dec 5, 2017)

Thanks for reply. Unfortunately this did not fix it.


----------



## mrclksr (Dec 5, 2017)

Could you please post the output of `env | grep TERM`?


----------



## Speedy (Dec 5, 2017)

Below is inside of screen session. After login it is set to xterm.

```
TERM=screen
TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal:\
```


----------



## mrclksr (Dec 5, 2017)

Please check if /usr/share/misc/termcap contains a definition for "screen":

```
grep screen /usr/share/misc/termcap
```
This *should* be the case, but who knows ...


----------



## Speedy (Dec 7, 2017)

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


----------



## mrclksr (Dec 8, 2017)

Speedy said:


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


----------



## Speedy (Dec 9, 2017)

I tried with BASH, error is a little different but the message is the same - error opening the terminal.


----------



## ShelLuser (Dec 9, 2017)

How did you install screen? Using ports or packages (so: `# make install clean` vs. `# pkg install`)?


----------



## mrclksr (Dec 9, 2017)

Did you check the permission of /usr/share/misc/termcap and /usr/share/misc/termcap.db? `ls -l /usr/share/misc/termcap*`


----------



## Speedy (Dec 10, 2017)

Everything is installed from ports, the system is compiled from source, too. Permissions seem OK.

```
~]$ 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
```


----------



## mrclksr (Dec 10, 2017)

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?


----------



## Speedy (Dec 10, 2017)

Surprisingly yes, without executing screen TERM=screen works, no complaints.


----------



## JamesElstone (Dec 24, 2018)

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.


----------



## yossman (May 29, 2019)

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.


----------



## abdelilah (Sep 24, 2019)

yossman said:


> 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


----------

