Troubleshooters.Com Presents

Linux Productivity Magazine

Volume 2 Issue 8, August 2003


Copyright (C) 2003 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Linux Productivity Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

See also Troubleshooting Techniques of the Successful Technologist
and Rapid Learning: Secret Weapon of the Successful Technologist
by Steve Litt

[ Troubleshooters.Com | Back Issues |Troubleshooting Professional Magazine ]

Heck, if I get 50 people wanting it, I'll make the menu program myself. -- Steve Litt (predicting the future in the April 1998 Troubleshooting Professional Magazine)


Editor's Desk

By Steve Litt
Are you better off than you were four years ago? Every four years this question makes or breaks a president.

Now let me ask this question: Are you more productive on your computer than you were 15 years ago? Is your current spreadsheet faster to use than Lotus 123 for DOS, or is it just prettier, mousier and more of a memory hog? Is your current word processing software more productive than WordPerfect 5.1 for DOS or Wordstar for CPM, or do you waste inordinate time reaching for a mouse?

15 years ago we worked with 10 nimble fingers -- today it's 1 clumsy arm. We've come a long way, baby!

Don't get me wrong. Mice are productive for operations like huge selections and aligning elements on a drawing. But for character based content, and especially for picking choices from among alternatives, they're a productivity black hole. Menus are great interfaces, but mice slow them terribly. That's why UMENU exists.

UMENU is a keyboard driven menu system capable of running on a console, or even a teletype printer. It's lightweight, touch typist friendly, and runs on any UNIX clone, including, of course, Linux. Better yet, with the addition of the EMDL to UMENU converter, it's probably the quickest menu system to configure, or more importantly, reconfigure.

Consider the cost of using a mouse menu. How many keystrokes can you press in the time it takes to reach and grab the mouse, and then reseat your hands on home position? How many keystrokes could you press in the time it takes to hover or click a choice with a mouse?

This issue of Linux Productivity Magazine discusses UMENU -- how to use it, how to configure it, how to install it, and how to benefit from it. If you want the technical nitty-gritty of UMENU and its Rapid Menu Development companion, EMDL, the URL's are in the URL's section of this magazine.

So kick back, relax, and contemplate the difficulties and opportunities of exidus from Windows XP. And remember -- if you enjoy, use, or write Open Source software, this is your magazine.
Steve Litt is the author of Samba Unleashed.   Steve can be reached at Steve Litt's email address.

Help Publicize Linux Productivity Magazine

By Steve Litt
Loyal readers, I need your help.

For months I've publicized Linux Productivity Magazine, expanding it from a new magazine to a mainstay read by thousands. There's a limit to what I can do alone, but if you take one minute to help, the possibilities are boundless.

If you like this magazine, please report it to one of the Linux magazines. Tell them the URL, why you like it, and ask them to link to it.

I report it to them, but they don't take it very seriously when an author blows his own horn. When a hundred readers report the magazine, they'll sit up and take notice.

Reporting is simple enough. Just click on one of these links, and report the magazine. It will take less than 5 minutes.

News Mag
Submission URL or Email address
Just fill in the short form.
Just fill in the short form.
Linux Weekly News
Just tell them the URL, why you like it.
Just tell them the URL, why you like it.
Just fill in the short form.
Newsfactor Network
Just tell them the URL, why you like it.
The Linux Knowledge Portal
Just tell them the URL, why you like it.
OS News
Just tell them the URL, why you like it.
Only for LPM issues involving the Linux desktop, not for programming or server issues.

If you really like this magazine, please take 5 minutes to help bring it to a wider audience. Submit it to one of the preceding sites.
Steve Litt is the author of Samba Unleashed.   Steve can be reached at Steve Litt's email address.


By Steve Litt
This article assumes that you've configured your window manager so that Ctrl+9 instantiates UMENU. How to so configure your window manager will be discussed in the next article, Installing UMENU.

When you press Ctrl+F9 the main menu comes up, as shown below:
Main Menu screenshot

You'll notice a few points about the preceding menu. The line with the asterisks shows the menu's title (Main Menu in this case), as well as the menu's letter string (s in this case). Below that line are a series of lines defining choices. Each line has a letter to press, and text describing the choice. All but the bottom choice (eXit) are preceded by elipses (...). The elipses denote that this choice is itself another menu -- a submenu. The eXit choice is set to return you to the operating system, terminating the menu system. The following screenshot shows the result of pressing the I key:

Internet Menu screenshot

The preceding has several distinctions from the main menu. First, the title is different. Second, the menu's letter string is now two characters long (sI instead of just s). The I represents the key you pressed to get into this menu. Also, you'll notice that some of the choices have elipses and some don't. Those that have elipses will bring up yet another submenu, while those without elipses will run the appropriate app, or return to the calling menu in the case of the Quit choice. The following screenshot shows the result of pressing the B key:

Browser Menu screenshot

In the preceding, there are no submenus, as shown by the absense of elipses. The menu's letter string is sIB, meaning you got there by pressing I then B from the main menu whose menu letter string was s. The following screenshot shows the result of pressing the G key:

Screenshot of Galeon spawned by the browser menu

The menu spawned the browser, and then the menu terminated. This is one of many ways you can configure UMENU to behave:

Command line argument
Choice properties
Menu returns after spawned program termination

This is a persistent menu, and is typically used when UMENU is the primary shell. This can be done to "lock" the user out of the operating system, and is also helpful when not multitasking.
Menu does not return after spawned program termination

This is your typical "start menu". You don't want used menus cluttering up the desktop, so it's best to destroy them. Best choice on a GUI system.
Spawned command line app runs in same window as UMENU. A new menu appears on command termination

C: command
This is typically how you run command line apps from UMENU.
Same as above, but a new command does not appear on command termination

C: command
S: 1
The S: 1 causes UMENU to wait for a keystroke before repainting the window with a new menu. This is essential when you want to read the output of the command.
Spawned command line app runs apart from UMENU window, but UMENU stops while spawned command runs.

C: xterm -e command
There is typically no reason to do this.
Same as above, but UMENU is fully functional while spawned command is running:

C: xterm -e command
B: 1
This is typical of how you configure persistent menus (not start menus).
Spawned GUI app

C: command
B: 1
The command runs, the menu remains functional. Note that if UMENU was started with the --terminate argument, UMENU terminates. In such case, had you not included the B: 1, in most cases the spawned app would have terminated along with UMENU.
Spawled GUI app, alternative to above

C: nohup command &
Use this if the B: 1 doesn't work -- sometimes this alternative will. However, the B: 1 is preferred.

My UMENU menu system has 304 commands in 5 menu levels. UMENU is capable of easily running huge menu systems.
Steve Litt is the author of "Troubleshooting Techniques of the Successful Technologist".  Steve can be reached at Steve Litt's email address .

Installing UMENU

By Steve Litt
UMENU is a Perl program. It, and all its configuration files, are stored in a single directory. This article discusses the "standard" way to install it -- there are many more ways.

The first step is to download UMENU. Get it from Troubleshooters.Com (see URL's section). As of August 2003 the current version is 0.6.1. Downloadumenu-0.6.1.tar.gz, into your home directory, then untar it to produce a umenu directory below your home directory. Do the following, noting that it could very likely produce an error:
cd $HOME/umenu/program
./ x
It's very likely the preceding will produce an error something like the following:

[slitt@fester program]$ ./
Use of uninitialized value in pattern match (m//) at line 173.
Use of uninitialized value in pattern match (m//) at line 164.
Can't exec "ver": No such file or directory at line 181.

dia ver =><
Fatal Error Cannot determine operating system! at line 158.
[slitt@fester program]$

The preceding error is produced by UMENU's faulty operating system detection feature. Disable this feature and strongarm the OS to LINUX, which should work on any UNIX based operating system (but not Windows). Edit $HOME/umenu/program/ Here's the original:

package OS;     

#The constructor is always called new(). It can take as many args
#as required.

sub new
my($type) = $_[0];
my($self) = {};
bless($self, $type);
if ($self->checkLinux) {$self->{'OS'} = 'LINUX';}
elsif ($self->checkUnix) {$self->{'OS'} = 'LINUX';} # for this version assume UNIX and Linux equvalent
elsif ($self->checkWin) {$self->{'OS'} = 'WIN32';}
else {$self->unknownOS;};

The following shows your changes marked in red:

package OS;     

#The constructor is always called new(). It can take as many args
#as required.

sub new
my($type) = $_[0];
my($self) = {};
bless($self, $type);
# if ($self->checkLinux) {$self->{'OS'} = 'LINUX';}
# elsif ($self->checkUnix) {$self->{'OS'} = 'LINUX';} # for this version assume UNIX and Linux equvalent
# elsif ($self->checkWin) {$self->{'OS'} = 'WIN32';}
# else {$self->unknownOS;};

Now rerun this command from the $HOME/umenu/program directory:
./ x
It will probably work, but if it doesn't it's probably the $BSD_STYLE variable, which you'll need to change in 2 places. Edit both and, in each looking for the line that looks like this:
my($BSD_STYLE) = 1;
If set to 1, change to 0 and try again. If set to 0, set to 1 and try again. Make sure both files agree on the value. UMENU will almost certainly work correctly with one of those settings. If neither works, check that you really have x.mnu in $HOME/umenu/menudir, (it ships with UMENU), and that you've made no other errors. If you still can't find the problem, a programmer will need to begin source code debugging techniques.

But probably it will produce a nice menu, in which case you can integrate it into your operating system.

Integrating UMENU into your operating system

Start by copying the mm and mm_startmenu files from $HOME/umenu/program to a directory on your path. Naturally, if that directory is not accessible to your login, you'll need to do this as root. Now you can run UMENU simply by typing mm (for a persistent menu) or mm_startmenu (for a start type menu). Next, associate it with the Ctrl+9 keyboard combination in your window manager:

How to enable UMENU
  • Place the following in ~/.icewm/keys:

  • key "Ctrl+9" rxvt -fg yellow -e mm_startmenu
    where mm_startmenu starts UMENU in terminate-on-select mode.
  • Restart IceWM by logging out and in, or by clicking the restart button in IcePref
  • Center click the desktop
  • Choose Customize
  • Choose Bindings, and the "Sawfish configurator" window appears
  • On the Context list, choose "Global"
  • Click the "Add" button, and the "Edit Binding" window appears
  • Click the "Grab" button, and press the Ctrl+9 key combination
  • From the "Commands" list, choose "Run shell command"
  • Notice that a field opens up for the command to run
  • Into the command field type rxvt -fg yellow -e mm_startmenu
  • Click the OK button on the "Edit Binding" window
  • Click the OK button on the "Sawfish configurator window
  • Ctrl+9 will now run UMENU
Gnome Same as Sawfish!
Thanks to Noel Henson for this information!

  • Run the /usr/bin/kmenuedit program.
  • Click the new item icon from the toolbar.
  • When prompted for the name, type UMENU and click OK. You'll be brough to the menu information screen.
  • Skip the comment unless you want one.
  • The command should be: rxvt -fg yellow -e mm_startmenu
  • Choose application for the type.
  • Leave the work path field blank.
  • DO NOT check the run in terminal box. The rxvt -e in the command already runs it in a terminal, and the rxvt terminal is lighter weight and faster to instantiate than the native KDE terminal.
  • Click the current key button. Notice that you'll see an input window like this:KDE shortcut screen
  • WARNING: NON-INTUITIVE: press the Ctrl+9 keyboard combination and the input window terminates, leaving you back at the original menu edit screen.
  • Observe that the current key button now reads Ctrl+9
  • Click the Apply button.
  • If you want the menu item in a less conspicuous place, observe that on the left is a graphical tree represenation of the KDE menu system. Drag the UMENU item to a less conspicuous place in the menu system.
  • From the menu, File->Quit.
  • Press the Ctrl+9 keystroke combination, and watch UMENU come up.
  • Right click on the desktop
  • Choose "Legacy E-Conf Tool..." from the dropdown menu
  • From the list, choose "shortcuts"
  • Click the "New" button
  • Click the "Change" button and press the "9" key
  • Choose "Ctrl" from the modifier popup list
  • Choose "Run Command" from the "Action to perform" list
  • Type rxvt -fg yellow -e mm_startmenu in the "options for action" field
  • Click the OK button to enable your new hotkey
fvwm2 The following is the high level plan for enabling UMENU:
  • Create ~/.fvwm/.fvwm2rc if necessary
  • Edit ~/.fvwm/.fvwm2rc to run UMENU on Ctrl+9
  • Restart fvwm2
And the following are the specifics:
  • Create ~/.fvwm/.fvwm2rc if necessary
    • CAUTION: This procedure will overwrite your existing rc file.
    • Leftclick->Setup
    • Click desired check boxes (or none at all)
    • Click "Copy Config File(s)" button
    • Click the "Restart fvwm" button
  • Edit ~/.fvwm/.fvwm2rc to run UMENU on Ctrl+9
    • Find the "some simple default key bindings:" section
    • Add the following line:
      • Key 9     A       C       exec rxvt -fg yellow -e mm_startmenu
    • Find the "AddToFunc StartFunction" section followed by lines starting with plus signs
    • Add one more plus sign line like this:
      • + I FuncFvwmFocusPolicyChange ClickToFocus
      • This line changes focus from following the mouse to clicking to focus,
      • which is necessary to use UMENU as a start menu.
    • Save and exit
  • Restart fvwm2
    • Leftclick->Exit Fvwm->Restart
Must be done with bbkeys.
Add the following line to $HOME/.fluxbox/keys:
Control 9 :ExecCommand rxvt -fg yellow -e mm_startmenu
Then restart fluxbox by right clicking the desktop and choosing restart. The Ctrl+9 keystroke should bring up UMENU.

Note the special naming conventions for the fluxbox keys file modifier keys:
keys file designation
Common designation
Mod1 9
Control 9
Shift F12
None 9
Control Mod1 9
I've heard that you can assign an arbitrary command to a keystroke in WindowMaker, but have never succeeded in doing it.

Once you've associated Ctrl+9 with UMENU, it functions beautifully as a start menu.
Steve Litt is the author of the Universal Troubleshooting Process courseware.   Steve can be reached atSteve Litt's email address.

Configuring Your UMENU Menu System Directly

By Steve Litt
A UMENU menu definition file is named with its letter string (all lower case), with extension .mnu. For instance, menu sIB is configured with sib.mnu. These files are typically kept in $HOME/umenu/menudir. Each separate submenu has its own menu definition file. That helps keep memory requirements down.

A UMENU menu definition file starts with a line describing the menu itself, looking something like this:
T_Browser Menu
The initial T stands for "Title", and the information after the underscore is indeed the menu's title. This is the title that shows up on the menu.

Next come a series of choices. Each choice begins with a line starting with the letter L, standing for "letter". This is the letter corresponding to the key which will invoke the choice. From that line until the next line beginning with L, or until end of file, all lines define that choice. Information is categorized by the first character on the line. Common starting characters include the following:

Letter that the user must press to invoke this choice
Command run by this choice. There are also special letters ~ indicating that this choice is a menu, and ^ indicating that this choice will return to the calling menu (or terminate UMENU if this is the top level menu).
The directory to cd to before running the command
A path to prepend onto the existing path
Run the command in the background, meaning that if UMENU terminates, the spawned command will survive.
After the spawned command terminates (or if run in the background, after control returns to UMENU), prompt for a keystroke and wait for a keystroke. This enables you to view the spawned command's output, rather than having this output overwritten by the next menu.

The following is an example of a UMENU menu definition file:
T_Internet menu
#___Menu created by EMDL to UMENU converter
#___Filename=si.mnu, EMDL key=0101.

C_xterm -e


C_nohup kmail &


T_Stats for T.C

T_Transfer files



T_Zope menu

T_fEtchmail configuration
C_python /usr/bin/fetchmailconf


UMENU files use the pound sign (#) for comments. On every line, the first character is reserved for a flag denoting the function of the line. The second character is undefined and unsupported, except for a few ancient, deprecated and nonfunctional scripts from the old days. Everything starting from the third character is data. So each line is a key->value pair.

The top line describes the menu itself, whose keystroke in this example is T and whose title in this example is Internet Menu. The second and third lines are comments inserted by the EMDL parser (see next article). Following the comments is data concerning the menu's choices. Each line starting with  begins a new choice, with all lines until the next Lor end of file supplying data about that choice. The column 1 flag definitions are enumerated earlier in this article.

So configuring your menu system is a simple matter of creating a menu definition file for each submenu. Unfortunately, significant menu system structural modifications are cumbersome in a multi-file configuration. For that reason I created EMDL. Read on...

Steve Litt is the author of the Universal Troubleshooting Process courseware.   Steve can be reached atSteve Litt's email address.

Configuring Your UMENU Menu System with EMDL

By Steve Litt
As mentioned in the preceding article, configuring UMENU directly is cumbersome, at least for large menu systems. I would never have been able to create and maintain my 304 command, 5 level menu system by directly manipulating UMENU menu definition files. So I created EMDL, which stands for Easy Menu Definition Language. You can download an EMDL to UMENU converter from Troubleshooters.Com (URL in URL's section of this magazine).

EMDL is optimized for quick creation and modification. Like C, it's very terse. It's line oriented, with no begin or end tags. In most cases, property names are identified by a single letter (followed by a colon and space). Thus a minimum of typing.

EMDL is an outline. That makes sense, because an outline exactly model hierarchies, and a menu system is a hierarchy. At the top is the main menu. Below it are each of its choices. There are two types of choices, submenus and commands. All choices have a letter (keystroke) that invokes them, and text that identifies them. In a graphic menu system, they can also have an icon file that identifies them.

Command choices have many additional properties: a command to run, a subdirectory to cd to, a path to prepend onto the existing path, whether to run the command in the background, and stop for keyboard input before resuming menu operations. The following is a swatch of EMDL to create a tiny menu system:
S:::Main Menu
Entertainment Menu:::Entertainment Menu
Sound Menu:::Sound Menu
C: aumix
D: /data/oldsongs
B: 1
C: xmms
D: /data/oldsongs
B: 1
C: realplayer
D: /data/oldsongs
B: 1
Games Menu:::Games Menu
Foul Eggs
C: kfouleggs
B: 1
C: ksirtet
B: 1
Vim (graphical)
C: gvim
D: /home/slitt

The preceding EMDL defines a menu system whose main menu contains three choices -- a submenu and two commands (Vim and eXit). The carat starting the eXit choice means it's a termination choice -- go back one level up or terminate. The Vim choice has two properties: the command (gvim), and the directory to cd to (/home/slitt).

The Entertainment submenu contains two submenus and a termination choice (Quit, which starts with a carat). Each submenu contains command choices to run sound programs or computer games. Notice that all these programs specify to run the command in the background, so that if UMENU terminates, the command will still survive.

The very first line is a special case -- it defines the menu letter and title of the top level menu. Notice that it is on the same level as its submenus. This inconsistency is justified by increased editability due to less indentation. EMDL was built for easy creation and modification.

Menu choices contain a triple colon (:::). On the left of the colons is the text appearing on the submenu. On the right of the colons is the title shown on the submenu. They can be, but don't have to be, the same. The only children a menu choice can legally have is other choices.

Command choices always have exactly one child, a line consisting of the word param. Each param line has children corresponding to the command choice's properties, such as command, directory, prepath, stop, background, etc, but not menu letter, which is defined in the choice's main line. A command line starting with a carat (^) returns to the calling menu, or terminates UMENU if you're on the top level menu.

You'll notice in the EMDL snippet displayed earlier, that I haven't explicitly specified each choice's choice letter. As part of its shorthand, EMDL has a four step default system to determine the choice letter:
  1. The first character of the line, unless...
  2. The first upper case character in the line overrides the preceding, unless...
  3. The first & followed by a non-whitespace, in which case the non-whitespace is the activation letter, overrides all the preceding, unless...
  4. If the line starts with _LX_, where X stands for any letter, that letter is the activation letter and overrides all the preceding.
In practice I've never gone past #2.

Installing the EMDL Parser

Simply download the EDML parser into your home directory. As of August 2003 the file is emdl-0.5.0.tar.gz. Untar it to produce the $HOME/emdl tree. It's now installed.

Creating and Modifying EMDL

EMDL was specifically crafted to be useful with a simple text editor. Text editors maximize productivity by limiting input to keyboard activities. The menu system structure can quickly be modified with cut and paste operations and insertion/deletion of leading blanks. The Vim editor is especially good at this.

Better yet, the Vim editor can be made to expand and collapse subtrees using foldmethod=indent.

Best, you can use the VimOutliner outline processor (downloadable at Troubleshooters.Com, URL in URL's section of this magazine) to effect lightning quick changes.

Creation of additional menus often takes the form of cut and paste. This minimizes the chance for indentation errors, or leaving out a paramline, or other common errors.

Compiling EMDL

You can download an EMDL to UMENU converter from Troubleshooters.Com (URL in URL's section of this magazine). This converter is a Perl program that parses the EMDL file, creating corresponding UMENU menu definition files for the main menu and each submenu. The current version of the converter has excellent error detection and error messages, such that you can quickly and easily find and correct errors. Typical errors include:
Typical warnings include:
Some menu systems allow or even encourage same-letter choices on a single menu. Such menu systems typically toggle between same-letter choices, requiring the user to press Enter to choose one. Later versions of EMDL parsers might make this warning configurable.

Lack of a termination choice can be legitimate on menus intended to be shells, so later versions of EMDL parsers might make this warning configurable.

My menu system has command choices for all UMENU configuration:

Umenu configuration menu screenshot
Umenu ::: Umenu Configuration Menu
Persistent Umenu menu
C: xterm -e ./ scu
D: ~/umenu/program
B: 1
Maintain s.emdl file
C: gvim /data/s.emdl
S: 1
Error report on S EMDL file maintenance
D: ~/emdl
P: ~/emdl
C: rm -f s*.mnu;./ /data/s.emdl | grep ERROR
S: 1
Warning report on S EMDL file maintenance
D: ~/emdl
P: ~/emdl
C: rm -f s*.mnu;./ /data/s.emdl | grep WARNING
S: 1
Compile s.emdl file
D: ~/emdl
P: ~/emdl
C: rm -f s*.mnu;./ /data/s.emdl
S: 1
Transfer S EMDL files
D: ~/umenu/menudir
P: ~/emdl
C: cp -f ~/emdl/s*.mnu .
Standard Umenu (x)
D: ~/umenu/program
P: ~/umenu/program
C: ./umenu x
S: 1
Vi in menudir
D: ~/umenu/menudir
C: gvim
scripts/mm edit
D: /scripts
C: gvim /scripts/mm /scripts/mm_startmenu
icewm keys configuration ::: Icewm keys config menu
edit icewm keys
D: ~/.icewm
C: gvim keys
Append example
D: ~/.icewm
C: echo 'key "Ctrl+9" rxvt -fg yellow -e /scripts/mm_startmenu' >> keys

Therefore, whenever I want to change my menu, my menu itself is the front end for editing, compiling, and transferring the files. But what happens if you don't have a functional menu? If you try to run UMENU on a nonfunctional menu system, you'll get the following screen:
Screenshot of a broken menu system

In that case, you use the script included with the EMDL parser package. You can either completely or partially bootstrap from

Complete bootstrap

Get into your EMDL directory. Make sure that your UMENU setup is in a tree starting at $HOME/umenu. If not, change accordingly. Then run the program from within your EMDL directory (typically $HOME/emdl):
Now, get into your umenu/program directory (typically $HOME/umenu/program), and type this command:
./ e
You should now get a UMENU menu system including entries to change your existing e.emdl and compile (parse) it, and transfer the newly compiled .mnu files to your umenu/menudir directory. Build your menu system from there.

Partial bootstrap

If you already have an EMDL file, you can simply modify to compile and transfer that EMDL file.

First, edit the script and change the e.emdl to the fully pathed filename of the EMDL file you want to compile. Next, you change the e in e*.mnu to the main menu's choice letter as defined by the first character of the first line containing a triple colon. If your UMENU installation isn't in the ~/umenu tree, change directory specs accordingly. Then, from the EMDL directory (which is typically ~/emdl), run the script, and you'll obtain a working UMENU based on the EMDL file.

Future EMDL Parsers

You'll notice that little in EMDL is specific to UMENU. EMDL captures the vast majority of information needed by any menu system, and can be used to define almost any menu system. Unfortunately, the current EMDL parser has so much UMENU inspired code that it's almost impossible to adapt for other types of menu systems. However, one day per month I've been working on a tool called, which can parse an outline into a structure very much like a DOM tree. This pseudo-DOM tree can easily be programmatically manipulated into almost any type of output.

At the LEAP Installfest on 8/2/2003 I got the new, equipped converter running. The new program has almost no UMENU specific code outside the small UMENUwriter module, and it converts 4 times faster than the current version.

I anticipate a time in the not too distant future when, from one EMDL file, you'll be able to built a UMENU menu system, an Icewm menu system, a KDE menu system,and a Gnome menu system. Creating other menu system output filters will be as simple as subclassing a class. This makes your menus "write once, run everywhere".
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist. He can be reached atSteve Litt's email address.

Front Ending a Command or Application

By Steve Litt
Need a front end to a complex command but have only 10 minutes to make it? Need to write an app but don't want to take the trouble to write a user interface? Let UMENU do the front-ending for you.

UMENU has a feature called prompted argument substitution. You can configure a menu choice to prompt for an argument to the command being run. For instance, the following real-life menu choice prompts me for my weight, and for a comment, and passes these to them both to

T_Record todays weight
C_./ %1%Weight please%% "%2%Comment please%%"

In the preceding, arg0 is, arg1 is whatever the user enters after UMENU prompts him with Weight please", and arg 2 is whatever the user enters when prompted with Comment please. As written, the weight prompt would be presented to the user before the comment prompt. But the presentation order to the user could be reversed by reversing the%1% and %2%. Such reversing does not change the order of the arguments presented to the command. A prompt is delineated on the left with a percent sign, a sort character, and another percent sign. It's delineated on the right with two percent signs.

Look at the opportunity this presents. You can now build an entire app out of various shell commands and simple, no user interface scripts. Database access can be via the psql program. Reports can be presented in Mozilla or via enscript to the printer, depending on which menu item you select. Form input could be through a Perl-TK program or via an old fashioned command line cycle-through script.

About the only thing this scenario is missing is a picklist. Hey -- wait a minute -- didn't I see one of those in the March 2003 Linux Productivity Magazine? (URL in URL's section).

So you can quickly write a few simple and completely modular scripts, and then turn them into a user friendly app with UMENU. At least twice in my life I was contracted to quickly (a couple days) create a simple version of an app that the company's  employees needed a month to complete. In one of those cases I wrote the prototype in Perl while the employees struggled with Java. I wonder if someone could hire themselves out as a professional prototyper and make a living. Hmmmm...
Steve Litt is the author of the Universal Troubleshooting Process courseware.   Steve can be reached atSteve Litt's email address.

Life After Windows: Why UMENU?

Life After Windows is a regular Linux Productivity Magazine column, by Steve Litt, bringing you observations and tips subsequent to Troubleshooters.Com's Windows to Linux conversion.
By Steve Litt
UMENU doesn't run on Windows, although at least one person modified a former version enough to run on Windows. So it's ironic that if it did run on Windows, it would help Windows users much more than Linux users. Unlike Windows, many Linux window managers are very keyboard friendly. IceWm's menu system is easily manipulated from the keyboard. So why do I use UMENU instead of the IceWM menu system?

One reason is ease of configuration. With EMDL, in minutes I can make structural menu changes that would take hours using IcePref or MenuDrake. But what about manually editing IceWM's menus? IceWM's menu definition file might be OK for a programmer, but for a casual menu system user it's a horror, with begin and end tags and non-intuitive space dependencies. Once again, EMDL configures much faster.

I like the fact that, via EMDL, UMENU can be configured with any text editor. No front end program to screw up. The compiler's a fairly simple Perl script. Contrast this to the various menu front ends. If they break or malfunction, you're out of luck. Imagine configuring KDE manually. KDE's menu structure is a directory structure. You'd need a pretty slick file manager to quickly configure it by hand.

Then there's data integrity. Make no mistake about it -- when you've tweaked your menu system exactly how you want it, it's data -- valuable data. You want to back it up. Of course, most menu systems could be backed up by backing up your entire home directory, but for those of us not wanting to back up hundreds of web cache files and maybe a local Star Office installation, it's much nicer to have a single file (which can be kept anywhere), to back up.

And of course there's replication. With one single EMDL file you can go to any computer with EMDL and UMENU, and compile up a menu identical to the one on your regular computer. You could easily and quickly install the same menu on a few hundred computers.

I'm mostly in GUI mode on my desktop computer, but every once in a while I'm in the command line interface, and when there, I'm glad I can run UMENU.

UMENU is extremely lightweight. I once put together a chess playing computer using an ancient, memory starved Pentium box, Red Hat 5.2 (when 7.3 was the current version), Window-managerless X, and UMENU. In /etc/passwd I specified the user's shell as UMENU. Worked great!

I think UMENU is a great addition to Linux.
Steve Litt is the author of the courseon the Universal Troubleshooting Process.  He can be reached at Steve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Linux or Open Source. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

Any article submitted to Linux Productivity Magazine must be licensed with the Open Publication License, which you can view at At your option you may elect the option to prohibit substantive modifications. However, in order to publish your article in Linux Productivity Magazine, you must decline the option to prohibit commercial use, because Linux Productivity Magazine is a commercial publication.

Obviously, you must be the copyright holder and must be legally able to so license the article. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity, within the scope of the Open Publication License. If you elect to prohibit substantive modifications, we may elect to place editors notes outside of your material, or reject the submission, or send it back for modification. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

Copyright (c) 2003 by <your name>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, version  Draft v1.0, 8 June 1999 (Available at (wordwrapped for readability at The latest version is presently available at

Open Publication License Option A [ is | is not] elected, so this document [may | may not] be modified. Option B is not elected, so this material may be published for commercial purposes.

After that paragraph, write the title, text of the article, and a two sentence description of the author.

Why not Draft v1.0, 8 June 1999 OR LATER

The Open Publication License recommends using the word "or later" to describe the version of the license. That is unacceptable for Troubleshooting Professional Magazine because we do not know the provisions of that newer version, so it makes no sense to commit to it. We all hope later versions will be better, but there's always a chance that leadership will change. We cannot take the chance that the disclaimer of warranty will be dropped in a later version. 


All trademarks are the property of their respective owners. Troubleshooters.Com(R) is a registered trademark of Steve Litt.

URLs Mentioned in this Issue