The terminal, as far as the dialogue utility is concerned, is the terminal that is being emulated by the screen program. The screen program, in turn, is talking to another terminal, which going by the menu is GNOME Terminal, MATE Terminal, or some such.
The dialogue utility is using control sequences to clear a whole bunch of character cells at once. There are various "erase" control sequences defined by the ECMA-48 standard, that allow erasing to the end of the line, to the end of the display, or the next N characters. These control sequences are processed by screen.
There are two modes of behaviour that terminals have for processing such erasure sequences: erase using the current background colour or erase using the default background colour. In your second screenshot, you can see the result of a program, in this case your dialogue utility, thinking that erasure uses the current background colour when the terminal is actually implementing erasure using the default background colour. (The first screenshot comes about in two ways. Either the terminal erases using the current background colour, or the application recognizes that there is no background colour erasure ability in the first place and adjusts its output accordingly to make large blank areas in some other way.)
This behaviour is switchable in the case of screen, as it is in the case of a few other terminals and terminal emulators. By default in screen, so-called background colour erase is switched off, and the control sequences cause erasure with the default colour. One switches it on with the bce command, causing erasure with the current background colour. One sets the default for the bce setting itself, in all new screens, with the defbce command.
The dialogue utility has to know about this. Not all terminals have background colour erase, let alone make it switchable.
What informs the dialogue utility is the record corresponding to the terminal type (denoted, remember, by the value of the TERM environment variable as seen by the dialogue program) in the terminfo database. In that record, there is a capability that allows programs to determine what the terminal that they are talking to will do. It is named bce. (The termcap equivalent name is ut.)
Complicating this is screen's way of telling such programs what the terminal is. Other terminal emulators simply define how they behave as a terminal and require that programs be run with a specific terminal type for their terminal emulations. tmux just has the terminal types tmux and tmux-256color, for example, describing the single emulated terminal behaviour of tmux. screen by contrast constructs a bizarre mongrel terminal type that combines the screen emulation type with the type of the outer, rendered on to, terminal, such as screen.xterm-256color in your case, that then has to have a matching mongrel entry in the terminfo database.
The problem here is in part that you are mis-describing your outer, rendered on to, terminal to screen in the first place. It isn't XTerm, it isn't fully compatible with XTerm, and its correct terminal type is, despite what you may hear, not xterm. Its correct terminal type is gnome-256color or vte-256colour, which actually specifically describes libvte-based emulators like GNOME Terminal. (You can run infocmp {xterm,vte}-256color for revelations on how your system thinks that these two terminal emulators differ. And those are only the parts of the emulations that the terminfo database actually covers.)
You need to:
- Provide a proper terminal type to (the front-end rendering part of)
screen that correctly describes libvte-based terminal emulators.
- Provide a proper terminal type to the applications running against
screen's own terminal emulation. screen will create a mongrel screen.vte-256color type. You can also employ something like screen-256color-bce instead.
- Tell
screen to switch background colour erase on, with the bce setting or with the defbce command before creating a screen. Note that this is going to be affected by the visibility of your ${HOME}/.screenrc file in whatever context you are invoking screen.
An alternative inferior (because background colour erase is a useful optimization for programs such as this dialogue utility that colour large blank blocks of the screen) approach is:
- Still provide a proper terminal type to (the front-end rendering part of)
screen that correctly describes libvte-based terminal emulators.
- Provide a proper terminal type to the applications running against
screen's own terminal emulation, but this time one of the ones that does not advertize a background colour erase capability, such as the plain screen-256color type.
- Leave
screen with background colour erase off.
Further reading
