Debconf's questions, or really whiptail, doesn't always work in xterms

March 8, 2023

Every so often I install or upgrade a package by hand on one of our Ubuntu servers and the package stops to ask me questions, because that is a thing that Debian packages can do. Usually this is pretty close to fatal, because in my normal xterm environment, the default interactive interface Debconf uses for this doesn't work. Specifically, there is no way to see what the current selection theoretically is, which leaves me flying blind in picking an answer.

The ultimate cause for this turns out to be that the whiptail program doesn't work in an xterm that has colour turned off. Whiptail is the default program used for the default 'dialog' debconf frontend (thanks to @anarcat for telling me about this). Contrary to what I thought before I tried it, whiptail doesn't intrinsically require colour, as it will work if you claim your xterm is, say, a VT100 (with eg 'export TERM=vt100'). The alternative dialog program works fine if your xterm has had its colours forced off, and you can force debconf to use dialog instead of whiptail.

(In a terminal environment that it thinks can do colour, whiptail relies on colour to highlight your selection so you know what it is. If the terminal is not actually displaying colour, this goes badly.)

Xterm is relatively unique in X terminal programs in that it supports text colours but allows you to turn them off at runtime as a command line option (or an X resource setting, which is what I use). I disable terminal colours whenever I can because they're almost always hard for me to read, especially in the generally rather intense colour set that xterm uses (X terminal programs aren't consistent about what text colours look like, so the experiences of people using Gnome Terminal are different here). Unfortunately, once you've started xterm with colours off, as far as I know there's no way to turn them back on.

(There is probably some escape sequences that can be used to query xterm to see if it currently supports colours. I suspect that my odds of getting the authors of whiptail to use them are functionally zero.)

There are an assortment of manual workarounds, such as setting various environment variables before running apt-get. The practical problem is that, to quote myself from the Fediverse:

The broad problem is that Ubuntu and Debian package installs/updates infrequently and irregularly ambush me with this and the default configuration doesn't work. If I expect it I have many workarounds, but generally I don't. And I'll never remember to always, 100% of the time deploy the workarounds on all of our servers all of the time, no matter what I'm doing.

In theory debconf supports not even asking you questions, in the form of the noninteractive frontend. In practice I don't have enough confidence in Debian packages or especially Ubuntu's version of them behaving sensibly when they're forced into non-interactive mode. The very nature of being able to ask questions means that people don't necessarily feel compelled to make the default answer a sensible one.

Possibly the right answer for us is to deploy a general system setting on our servers to prefer dialog over whiptail. Unfortunately Ubuntu doesn't want you to remove the 'whiptail' package itself; it's a dependency of the 'ubuntu-minimal' package, and I don't really feel like finding out what effects stripping out core looking 'ubuntu-<etc>' packages have. Another option is for me to configure xterm to set the '$TERM' environment variable to 'xterm-mono', which I expect exists on most Unix systems I'm likely to use (or perhaps the older name 'xtermm', which is also on OpenBSD). This version of xterm's terminfo capabilities lacks colour entries entirely, and whiptail works fine with it.

(I'm not intrinsically opposed to colours, but I am opposed to blinding or hard to read colour choices, and a great deal of the colours that programs try to use in terminal windows wind up that way. The default colour set used by GNU Emacs for code highlighting generally comes across to me as fairly nice, for example.)

PS: One way to see if your current terminal type claims to support colours is 'tput colors' (cf). In my regular xterms, this reports '8' (the basic number of ANSI colours), while 'tput -T xterm-mono colors' reports '-1', ie 'no'.


Comments on this page:

By Vincent Bernat at 2023-03-09 02:32:15:

The ultimate cause is more that you use a TERM claiming that you support color while you don't (like you explain later in your post). I can't see how you can blame a program trying to make use of colors when your TERM is supposed to support them.

By deltragon at 2023-03-09 07:42:09:

As someone with a background in web accessibility, this sounds like a bug in whiptail. Even when it's possible to communicate something with color, it should at the same time be communicated without color as well (for eg. colorblind people, or your usecase). I think this might be something that whiptail would more likely accept as a bugfix, that the selection is always indicated separately (whether color is on or off).

I can confirm that it's not enough to set the noninteractive frontend. We have env DEBIAN_FRONTEND=noninteractive NEEDRESTART_MODE=a UCF_FORCE_CONFFNEW=YES in our Ubuntu config scripts. It's still not enough to deal with some changes like trying to nerf /etc/apt/apt.conf.d/20apt-esm-hook.conf so that's sadly not done.

Written on 08 March 2023.
« ANSI colours aren't consistent across X terminal programs
ZFS on Linux and when you get stale NFSv3 mounts »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Wed Mar 8 23:12:30 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.