Introduction

The most complex, difficult, bug-riskful and error prone part of many applications is their user interface. Using UMENU2, you can bolt a menu driven user interface, with prompted data acquisition, to any Command Line Interface (CLI) computer program or set of computer programs or commands. This document explains the best-practices way to do this, using today's UMENU2 (version 1.9.3).

By bolting on a UMENU2 user interface onto your programs, or assembling an application from Linux utilities plus UMENU2, you maximize the app you can write, given your time constraints. Your app might not be hip, pretty or new, but it provides your user with an easy, discoverable user interface (assuming you use a good menu hierarchy).

Here are some best-practices for assembling a full application from UMENU2 and some simple commands and programs:

Use Environment Variables
Pamper Your Namespace

Use Environment Variables

By using environment variables exclusively, for any value that could ever change or even be used multiple times within the application, you maximize portability and simplicity. Think of a C program, where instead of using magic numbers or magic strings over and over again, you create a #define to define a meaningful name for the number.

The beauty of environment variables is that they can be read by both UMENU2 and the programs/commands it calls. This makes it much easier to make a unified application out of a bunch of executables. Everybody has the same names for the same values: No need to repeat long, hard to remember constants in multiple UMENU commands and multiple programs.

First and foremost, every single directory used in the entire application must be referenced by an environment variable. Furthermore, it will almost certainly turn out best if every file that's referenced from those directories have its own environment variable. This minimizes repetition of code and opportunities to get things wrong.

All these environment variables should be set in a single shellscript with a distinquishable name like myapp_env.sh. It would export all appropriate environment variables, like this:

#!/bin/sh
#### Shellscript to set global environment variables

export myapp_root_dir=$HOME/apps/myapp
export myapp_umenu_prog=$HOME/apps/myapp/umenu2/prog
export myapp_umenu_menu=$HOME/apps/myapp/umenu2/menu

This environment variable setting shellscript is called by other shellscripts as follows:

#!/bin/sh
.   ./myapp_env.sh

# DO THE REST OF THE STUFF BELOW

Pamper Your Namespace

If you perform the env command you'll see a menagerie of environment variables. Confusing. What you want is a way to find only the environment variables created by your application. The easiest way to do that is to precede every environment variable name with a string uniquely identifying the application. For instance, if every environment variable name were preceded by "myapp_", then the following shows all the application's environment variables:

[slitt@mydesk ~]$ env | grep ^myapp_
myapp_root_dir=/home/slitt/apps/myapp
myapp_umenu_prog=/home/slitt/apps/myapp/umenu2/prog
myapp_umenu_menu=/home/slitt/apps/myapp/umenu2/menu