== Debconf's questions, or really whiptail, doesn't always work in xterms Every so often I install or upgrade a package by hand on one of [[our https://support.cs.toronto.edu/]] Ubuntu servers and the package stops to ask me questions, because [[that is a thing that Debian packages can do UbuntuUpdateProcessDislike]]. Usually this is pretty close to fatal, because [[in my normal xterm environment, the default interactive interface Debconf uses for this doesn't work https://mastodon.social/@cks/109982648901372273]]. 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_ https://manpages.debian.org/bullseye/whiptail/whiptail.1.en.html]] program doesn't work in an [[xterm https://invisible-island.net/xterm/]] that has colour turned off~~. Whiptail is [[the default program used for the default 'dialog' debconf frontend https://manpages.debian.org/bullseye/debconf-doc/debconf.7.en.html#Frontends]] ([[thanks to @anarcat for telling me about this https://kolektiva.social/@Anarcat/109982789634101272]]). 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_ https://manpages.debian.org/bullseye/dialog/dialog.1.en.html]] program works fine if your xterm has had its colours forced off, and [[you can force debconf to use dialog instead of whiptail https://manpages.debian.org/bullseye/debconf-doc/debconf.7.en.html#DEBCONF_FORCE_DIALOG]]. (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 https://mastodon.social/@cks/109982924464399854]]). 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 ../unix/TerminalColoursNotTheSame]], 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 https://mastodon.social/@cks/109982824003312269]]: > 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 https://manpages.debian.org/bullseye/debconf-doc/debconf.7.en.html#noninteractive]]. 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-' 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 https://man7.org/linux/man-pages/man5/terminfo.5.html]] 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 https://unix.stackexchange.com/a/10065]]). In my regular xterms, this reports '8' (the basic number of ANSI colours), while '_tput -T xterm-mono colors_' reports '-1', ie 'no'.