Dialog: An Introductory Tutorial
The preceding examples were somewhat unrealistic; dialog is normally used within a shell script to do some real work. Let's look at a simple but useful application. I use the following script to back up my home directory to floppy disk on a regular basis:
#!/bin/sh # Backup all files under home directory to a single # floppy # Display message with option to cancel dialog --title "Backup" --msgbox "Time for backup \ of home directory. \ Insert formatted 3-1/2\" floppy and press <Enter> \ to start backup or \ <Esc> to cancel." 10 50 # Return status of non-zero indicates cancel if [ "$?" != "0" ] then dialog --title "Backup" --msgbox "Backup was \ canceled at your request." 10 50 else dialog --title "Backup" --infobox "Backup in \ process..." 10 50 cd ~ # Backup using tar; redirect any errors to a # temporary file # For multi-disk support, you can use the # -M option to tar tar -czf /dev/fd1 . >|/tmp/ERRORS$$ 2>&1 # zero status indicates backup was successful if [ "$?" = "0" ] then dialog --title "Backup" --msgbox "Backup \ completed successfully." 10 50 # Mark script with current date and time touch ~/.backup else # Backup failed, display error log dialog --title "Backup" --msgbox "Backup failed \ -- Press <Enter> to see error log." 10 50 dialog --title "Error Log" --textbox /tmp/ERRORS$$ 22 72 fi fi rm -f /tmp/ERRORS$$ clear
To run this automatically, I put these lines in my .profile file to call the backup script on login if more than 3 days has elapsed since the last backup was made:
# do a backup if enough time has elapsed find ~/.backup -mtime +3 -exec ~/.backup \;
The sound driver for the Linux kernel uses a program called “configure” to prompt the user for sound configuration options. It generates a C header file based on the chosen options. A replacement based on dialog could offer some advantages, such as a more professional appearance and the ability to select options randomly from menus rather than as a linear sequence of questions.
Due to time and space constraints, I only present a partial (but functional) implementation of a sound driver configuration script. This could quite easily be extended to fully replace the current configure program.
The complete script is shown in as Listing 1. I'd like to explain it using a top down approach, which means reading the listing starting from the bottom.
The last part of the script is a while loop which simply calls the shell function main_menu repeatedly. Above that is the code to implement the main menu. We present the user with three choices, and redirect the selection to a file. One of three shell functions is then called, based on the user's choice.
The most important menu in this script is the next one, the config_menu function. Again we present the user with a number of choices. Note that in this case there is an option which returns the user back to the main menu.
Continuing to read our listing backwards, we come to the select_cards function. The kernel supports multiple sound cards, so here we use a checklist to present the user with the available choices. The command “on_off” is a utility function that will be shown later; it returns the string “on” if its parameters are equal, otherwise it returns “off”. This is the form that the checklist menu requires. Note that the return status of the command is checked. If the user selects “cancel” from the menu then the return status is non-zero and we return immediately without making any changes. Otherwise, we set appropriate variables to indicate which sound cards have been enabled.
The next function, as we read our listing backwards, it the function view_summary. This uses the textbox type to display a file containing information on the currently selected options. We first build up the data in the file before displaying it.
Our next function is select_dma. Here the user must make one of four mutually exclusive options, so we use the a radio list. If you try this example yourself, be aware that the radiolist type was added in dialog version 0.4; if you have an older version then you will have to make do with a checklist.
Up above, the routine select_irq uses very similar code to allow the user to select the final option in our configuration utility.
The purpose of this script is to generate a C language header file defining the compile options for the kernel sound driver. The “save” function does this. Notice how a dialog box is displayed while the save is in progress.
Above that we see the on_off function alluded to previously. This avoids some repetitive code in the script.
Finally, we see the clean_up routine which allows the user to exit from the script. At the top of the script some default values are defined for the configuration options and the temporary filename to use.
The configuration utility still needs a few enhancements to replace the existing program, including more kernel options and error checking, but the example does function and gives a feel for what can be done with dialog. I encourage you to type it in and try it.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- The Secret Password Is...
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- New Products
3 hours 59 min ago
- Keeping track of IP address
5 hours 50 min ago
- Roll your own dynamic dns
11 hours 3 min ago
- Please correct the URL for Salt Stack's web site
14 hours 15 min ago
- Android is Linux -- why no better inter-operation
16 hours 30 min ago
- Connecting Android device to desktop Linux via USB
16 hours 59 min ago
- Find new cell phone and tablet pc
17 hours 57 min ago
19 hours 26 min ago
- Automatically updating Guest Additions
20 hours 34 min ago
- I like your topic on android
21 hours 21 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?