all.

The question is about the setup that you can find here: https://github.com/filmil/bugreports/blob/master/dialog/README.md

I noticed that running a dialog utility in an interactive docker terminal session gives different results when ran from a "regular" terminal, versus when ran in a screen session.

In the former case, the sample application is displayed as expected. See below.

In the latter case, the sample application is displayed, but the screen is not fully "drawn". See below.

At first I thought that this was something about the TERM setting. But I could not find a TERM settings that seem to work under screen. Any ideas what could be done to have the screen session work as well? Note, if I run a "regular" dialog without docker, the display is just fine. Only when docker comes into play does the display get "holes".

Thank you for thinking along!

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

• 
  "Character Processing", Screen Users' Manual. GNU Project.


• Clear to end of line uses the wrong background color in screen


• Clear to end of line uses the wrong background color in tmux


• Curses interface has blank spaces under GNU Screen and ssh


• Thomas E. Dickey (1997). "What is a VT220?". xterm Frequently Asked Questions. invisible-island.


• Thomas E. Dickey (2018). "Known Bugs in XTerm and Look–alikes: GNOME Terminal". xterm Frequently Asked Questions. invisible-island.