Debconf's questions, or whiptail, doesn't always work in xterms | Hacker News Reader

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

utcc.utoronto.ca

20 pointszdw14 comments

Besides everything else, can I just say how crazy it is to pause an upgrade, while the system is in a partially upgraded state, to ask the user a question? If the user forgets and reboots the system or hibernates it, your system is likely hosed.

If you must ask questions, at least ask them all at the beginning of the upgrade before any modifications are made, and record the answers somewhere in an upgrade log so that a sysadmin can audit the choices afterwards.

But for an even better experience, provide a tool as well to output any choices to a file before the upgrade process starts. The sysadmin can select answers in a text editor, and then that file can be read in by the upgrade system for the upgrade process later. That way an entire fleet can be configured consistently.

Debian currently has none of these, it pauses your entire installation while it's at its most fragile and the choices are ephemeral.

I don't know how terminfo works, but if possible turning off colors in xterm should change the terminfo to say it doesn't support colors. If that is possible, I would consider that a bug in xterm.

> Unfortunately Ubuntu doesn't want you to remove the 'whiptail' package itself; it's a dependency of the 'ubuntu-minimal' package

I recall that ubuntu-minimal was a sneaky canonical trick. If I recall correctly it keeps your system doing canonical's bidding.

EDIT: ok found it: it "requires" ubuntu-advantage-tools

https://askubuntu.com/questions/1434512/how-to-get-rid-of-ub...

> EDIT: ok found it: it "requires" ubuntu-advantage-tools

Dependencies:

* https://packages.ubuntu.com/jammy/ubuntu-minimal

Discussed recently here: https://news.ycombinator.com/item?id=34846287

nice. too bad the discussion doesn't go deep enough into how ubuntu sort of intertwines canonocal into the os. Like /etc/motd and other packages that phone home all the time. Not only are things opt-out instead of opt-in, some things you can't opt-out unless you delve into the sources (which at least you can do with the core OS)

I'll get roasted for saying this, but now that modern terminals like kitty can handle a huge number of colors, why not set the bar at requiring that many colors - which any decently modern PC can handle? Like throw out 16-color mode completely, along with 486 CPUs, PCMCIA cards, and floppy disks.

Then have sane, pleasant color schemes that aren't all harsh and glaring - which 16-color mode often looks like.

Whatever dev is great at logic, but is bad at picking colors, should humble themselves when someone with taste in colors comes along and offers a PR to make the default color schemes better (keeping in mind the higher-contrast needs of the visually impaired, favoring "dark mode").

Take a look at the color schemes which can be chosen from within "theme.sh -i" for great examples of such color schemes. Many are in poor taste, but there are also some great ones - which usability experts would agree are functionally the best, from a legibility perspective.

TL;DR: If you explicitly turn off colors in XTerm, whiptail does not know or understand this, and relies on color information to be able to present an understandable interface. But whiptail otherwise does not require colors if presented with a terminal which it knows not to have colors, it’s just a bug in whiptail that it assumes that all XTerms have colors.

I would say there is no bug in whiptail. Whiptail honors the capabilities it is told via TERM your terminal supports. Setting TERM=xterm, which has 8 color support, and then not supporting color is a bug on your part. If you are going to force xterm to mono you need to set your TERM=xterm-mono which whiptail will honor and there is no issue.

I can seen the reasoning, but terminals can change settings dynamically from having color support to not having it (I assume that XTerm is not the only one to do this), and if there is an escape sequence to query this information, it would be reasonable to expect whiptail to use it. If no such dynamic query exists, then yes, whiptail has to go off what TERM is set to.

It might also be reasonable to expect XTerm to set the TERM environment variable to “xterm-mono” if started without color support.

Whiptail uses the newt widget library (which uses the slang library), if you want that kind of support it will have to be added there.

As stated in another replay whiptail uses the newt widget library which itself is based upon the s-lang library. The s-lang library gets the capabilities of the terminal by querying the terminfo database using the terminal name. This is the same way ncurses or most terminal based libraries work. The terminfo database does contain info regarding whether a specific terminal supports color but doesn't contain info regarding whether there is an escape sequence for that particular terminal to determine if color is turned on. Instead separate terminfo entries for color vs mono are in the database.

Setting TERM to xterm when you are using xterm-mono is the error here. It fails just as setting your TERM to xterm when connected to a ADM-3A would cause things to fail.

This is a personal pet peeve of mine in poor design. colors are fine, nothing wrong with colors, but never depend solely on colors to differentiate state, always include some sort of bug or indicator that works without color, it may be a form that was photocopied, it may be(as in this case) a terminal with color turned off, hell it may even be someone who is color blind.

For the advanced class, interactive choice widgets need to have unambiguous state, cell phone slider buttons are notoriously bad at this.

Whiptail is buggy, I had to go back to plain old dialog in my console application.

Reply on news.ycombinator.com