23

I am going to create a script which will use user input, so I decided to use whiptail.

But now I'm a little bit confused about which one is portable and will work on Ubuntu 10.x and higher and CentOS 5.x and higher.

I know read, but I want a tool like dialog. If anybody knows any alternative just let me know.

Rahul Patil
  • 24,711

4 Answers4

17

whiptail is installed by default on most deb-based systems, while dialog is not.

Afair, on rpm-based whiptail is also default dialog app.

I guess it matters for you.

So whiptail is the right choice from point of portability.

Also whiptail is based on newt, while dialog is based on ncurses. From my point of view, the first one is more beautiful (:

rush
  • 27,403
  • 2
    The script might be more or less portable, but the dialog program itself is no less portable than whiptail. – Thomas Dickey Oct 29 '15 at 22:45
  • 2
    After all written here, why would whiptail more beatiful than dialog? The latter has more features and better documentation. – Daniel Bandeira Feb 19 '20 at 11:44
  • Actually, since whiptail is maintained by debian as a replacement for dialog (which can simply be installed via apt, and I think is installed by default on RedHat & derivatives), I would say that it's the other way around. For portability, choose dialog and make it a dependency on Debian & derived. – Luc VdV Feb 02 '21 at 07:17
14

According to the COMPATIBILITY section of the dialog(1) manual page:

Then there is whiptail. For practical purposes, it is maintained by Debian (very little work is done by its upstream developers). Its documentation (README.whiptail) claims

whiptail(1) is a lightweight replacement for dialog(1), to provide dialog boxes for shell scripts. It is built on the newt windowing library rather than the ncurses library, allowing it to be smaller in embedded environments such as installers, rescue disks, etc.

<p>whiptail is designed to be drop-in compatible with dialog, but has less features: some dialog boxes are not implemented, such as tailbox, timebox, calendarbox, etc.</p>

Comparing actual sizes (Debian testing, 2007/1/10): The total of sizes for whiptail, the newt, popt and slang libraries is 757 KB. The comparable number for dialog (counting ncurses) is 520 KB. Disregard the first paragraph.

The second paragraph is misleading, since *whiptail** also does not work for common options of dialog, such as the gauge box. whiptail is less compatible with dialog than the original mid-1990s dialog 0.4 program.

whiptail's manpage borrows features from dialog, e.g., but oddly cites only dialog versions up to 0.4 (1994) as a source. That is, its manpage refers to features which were borrowed from more recent versions of dialog, e.g.,

  • --gauge (from 0.5)

  • --passwordbox (from Debian changes in 1999),

  • --default-item (from dialog 2000/02/22),

  • --output-fd (from dialog 2002/08/14).

Somewhat humorously, one may note that the popt feature (undocumented in its manpage) of using a "--" as an escape was documented in dialog's manpage about a year before it was mentioned in whiptail's manpage. whiptail's manpage incorrectly attributes that to getopt (and is inaccurate anyway).

10

(This is not necessarily an answer, but I posted as such due to the amount of code. I have no practical experience with whiptail. Will delete this later if a whiptail user posts a tested solution on this.)

As Bash Shell Scripting/Whiptail writes:

From its README: whiptail is designed to be drop-in compatible with dialog(1), but has less features: some dialog boxes are not implemented, such as tailbox, timebox, calendarbox, etc.

That means you not necessarily have to decide for one or the other. Just detect which one is available then let the script use it:

# check whether whiptail or dialog is installed
# (choosing the first command found)
read dialog <<< "$(which whiptail dialog 2> /dev/null)"

# exit if none found
[[ "$dialog" ]] || {
  echo 'neither whiptail nor dialog found' >&2
  exit 1
}

# just use whichever was found
"$dialog" --msgbox "Message displayed with $dialog" 0 0

(Yes, the above detection will fail on tools installed inside directories with name containing newline characters. I just kept it simple.)

Florian
  • 135
manatwork
  • 31,277
  • 1
    Bruh... timebox and calendarbox were major to me... Used dialog instead. Who the heck won't implement these for any dialog software!? IMHO The main problem in these both is a bad/weak color customization. 8 colors? Oh dear... – Artfaith Mar 01 '21 at 08:36
9

Why not use both:

(Requires bash 4)

#!/usr/bin/env bash
t(){ type "$1"&>/dev/null;}
function Menu.Show {
   local DIA DIA_ESC; while :; do
      t whiptail && DIA=whiptail && break
      t dialog && DIA=dialog && DIA_ESC=-- && break
      exec date +s"No dialog program found"
   done; declare -A o="$1"; shift
   $DIA --backtitle "${o[backtitle]}" --title "${o[title]}" \
      --menu "${o[question]}" 0 0 0 $DIA_ESC "$@"; }



Menu.Show '([backtitle]="Backtitle"
            [title]="Title"
            [question]="Please choose:")'          \
                                                   \
            "Option A"  "Stuff...."                \
            "Option B"  "Stuff...."                \
            "Option C"  "Stuff...."    
B Layer
  • 5,171