Mshell

Section: User Commands (1)
Updated: 13 July 1993
Index Return to Main Contents

NAME

mshell - menu oriented shell

SYNOPSIS

mshell [-r] [-s] initial-menu

DESCRIPTION

mshell is a menuing program designed to be used as a login shell or as the primary program in a wrapper shell script (to set environment, etc.). Menus are intended to be simple to create without sacrificing flexibility.

OPTIONS

-r: mshell runs in "restricted" mode, where only commands found in a command-list file can be executed. I.e., some users may have full access to all menu options while others run under restriction. The command-list file is currently hardwired via the COMMAND_LIST #define in the source, but could easily be turned into a command line parameter. Further, -r inhibits user replies to prompts even for options that are active (to prevent users from entering metacharacters which may allow unintended access). Commands must match *exactly* the way they are listed in the menu's "cmd=..." line, e.g., full path or no path. See below for additional thoughts on security.
-s: Prevents the execution of !command at the menu prompt and prevents users from typing shell meta-characters in their replies to prompts. See below for additional thoughts on security.
initial-menu: The name or path to the initial menu: If the name has a / in it, that is used as the path to the starting menu; if no /, then $MENUDIR/initial-menu is used as the menu.

NOTES

Startup files

If the file .mshellrc exists in $HOME, it is run via "sh". Useful to run some intro commands (e.g., personal stty settings), but note it cannot be used to set variables or other internal state elements.

Logging

If you define LOGDIR (in Makefile) to an existing dir, then user activity will be logged. (I suggest the dir should be mode 733 so users can't poke around as easily). Every menu pick a user makes is appended to a file named with their username; these files grows without bound and must be cleaned up manually.

Environment variables

Work inside menu values (as $VAR), as does ~ for home dir.

Built-in commands

cd and setenv are built in. The built-in command 'menu' invokes mshell recursively (i.e., does not create a new process for submenus).

Security

Take great care if you want to use mshell in a secure environment. It can be an experiment in futility. Using the -s and -r options you can control what programs users may run; however, note that with just -s users can likely find clever ways to subvert the security and get a shell. Even with both -r and -s in effect, many of the programs you're likely to allow users to run may have ways to gain unintended access. For example, 'more' allows users to invoke the shell ('!' command) or vi (e.g. the 'v' command), from which they can gain instant shell access. Monitor what commands you allow in -r very carefully. Even the simplest shell scripts may be subvertible!

It helps to set the SHELL environment variable to something like /bin/true, or better yet, a command that echoes "You can't have a shell, sorry." This still won't foil a determined attack, of course.

Consider a wrapper around the menu that removes .mshellrc, for example.

Note that even with all this, mshell shouldn't be trusted for genuine security, since it's nearly impossible to eliminate the ways one can get a shell (I gave it a good whack, modifying binaries of various programs, hacking on source for others, etc.; it's too much hassle and still can be circumvented).

Multiple commands

If the user types pick1,pick2,pick3 then each will be executed as if the ',' were newlines. Use 'top,...' to get "absolute" picks, starting at the top of the menu tree.

Macros

A file named $HOME/.mshellmac is read at startup for macros. Macros look like:

: name=commands

For example:

: hist=top,i,h,x

which on Nyx means <top, info menu, 'h' for history, 'x' to exit menu back to main>. Execute macros as

: #name

such as

: #hist

Macros may be execute inside multi-command lines, as in

: foo,#hist,bar

and inside other macros, like

: foo=a,#hist,b,c

Online help

If a menu item has help=filename in the definition, that filename is printed prior to execution or prompt input. Users can do 'help o' for an option 'o', in which case, if man=xxx is set, "man xxx" is invoked. Failing that, "cmd=zzz" causes "man zzz" to be run. Thus one may let the cmd= setting default except where this invokes the wrong manual page or one wants to specific a non-man(1) manual page.

MENU DEFINITION

Format of menu file:

screen layout
*****
keyword <tab> action_description

The top part of the screen is what the users sees -- it is just text, put whatever you want there; there is no specific format rules, just make it look good. The bottom describes what commands have what action. The bottom is comprised of two tab-separated columns: a keyword and an action description. The keyword can be any string (without a tab in it), usually alpha-numeric. Presumably these keywords are displayed in the layout portion so users know what to type, but that's up to you to ensure. (That is, there is no marking of items in the top unless you want to for visual effect. Further, you can have "invisible" menu options by listing them in the bottom but not the top; the drawback is that you could have inoperative options if you list them above and forget to list them below.)

The simplest action description is just a shell command, as in

: w who | sort

which would execute "who|sort" when a user selects 'w' from the menu. The actions can be any shell code.

The action descriptions can be built using keywords as follows:

cmd=name_of_command: like arg=, but no _ translation. In addition, it specifies this this as the command to run 'man' for help.
prompt=prompt_to_print: Prints prompt (will be followed by colon and space). The user's response is interpolated as the next parameter.
arg=literal: Argument is included at this position in command string. This is also the default if no keyword= is given.
aarg=literal_to_append: Like arg=, but no space put before it; e.g., to append a filename extension after a prompted value.
aprompt=prompt_to_append: Prompts and appends to previous argument (e.g., a literal value).
help=name_of_helpfile: Prints said helpfile (printed immediately, i.e., before input or execution of command).
man=name_of_manual: Specifies manual entry to use for 'help'; useful if cmd= isn't set to something you want a 'man' on or there isn't anything interesting to set cmd= to.

Notice that no <type>= is the same as "arg=".

In [a]prompt= and [a]arg=, underscores will be translated to spaces on output and are mandatory in multi-word strings (i.e., if you have "prompt=foo bar" the prompt will be foo and bar will be looked on as the next action description word; instead do "prompt=foo_bar"). Tabs in strings don't work (could be handled similar to _ for space, but aren't at present).

The result is put into a string; if it has any meta-characters that should be handled by a shell, then the result is fed to system() so the shell (csh in particular) can deal with it. Otherwise, mshell executes the command directly.

If the first keyword listed in the description section is "_init", this command will be executed upon entry into the menu (before any selection).

At "Enter choice" prompt, a response beginning with ! causes the remainder of the line to be executed verbatim. (E.g., !who will run a who.) (Assuming this has not been disabled by -s.)

All menus respond to certain built-in options, namely 'x' to exit the menu, menu), and 'help xxx' to invoke the help for option xxx.

A sample menu file might be:

                                Main menu
                                =========

f       Upload/Download file menu       i       Information...
s       Status/options/users menu       u       Unix file access menu

c       Communications menu -- bulletins, NetNews, mail, chat

p       Programming menu
e       Education menu                  w       Word processing menu
g       Games menu                      gr      Graphics menu           
faq     Frequently Asked Questions      o       Organization menus

in      Introduce yourself to other Nyx users

fund    Info on the "fund drive" to speed up ol' Nyx

fb      Send feedback to sysop (comments, questions, etc.)
*****
u       cmd=menu arg=$mendir/file.men
c       cmd=menu $mendir/comm.men
w       cmd=menu $mendir/wp.men
p       cmd=menu $mendir/prog.men
g       cmd=menu $mendir/games.men
s       cmd=menu $mendir/stat.men
gr      cmd=menu $mendir/graphics.men
i       cmd=menu $mendir/info.men
f       cmd=menu $mendir/updownload.men
e       cmd=menu $mendir/edu.men
o       cmd=menu $mendir/org.men
fb      /u5/bin/comment
in      /u5/bin/introduction
fund    cmd=more -d $mendir/info/fund.drive
faq     cmd=more -d $mendir/info/faq

Some other random example commands:

_init   cmd=cd $downloaddir
used    cmd=du -s $HOME
s       cmd=fgrep prompt=String_to_find prompt=Files_to_search_(sep._by_spaces)
fn      cmd=find $HOME_-name prompt=File -print
co      echo 'lines____words____chars'; cmd=wc prompt=File
ec      cmd=crypt prompt=Input_file > prompt=Output_file
a       cd $dldir/.areas/ aprompt=Area# help=$dldir/.areas/.list
l       (echo -n "Current area: ";pwd;sort .catalog)|lineup|more
s       mail prompt=To help=$mendir/facmain.help

RECOMMENDATIONS

Use full pathnames for filenames.

Use multiple main menus for different classes of users.

You'll need various script files as wrappers around commands.

Look on Nyx (nyx.cs.du.edu, login as 'new') for various examples.

AUTHOR

Original shell script version by Andrew Burt of the University of Denver department of math and computer science. Initially coded in C by Dinesh Punjabi (yes, as a student project). Subsequent hacks and maintenance by Andrew Burt, reachable as aburt@du.edu.

BUGS

No doubt. I've heard tales of occasional glitches where the menus get very hosed up, but haven't searched for causes. I suspect there are some memory leaks lurking around as well in some of the older code. The reliance on fixed size strings stems from the original, and should be replaced. The original System V code has not been tested in ages and may no longer even compile; the newer diffs haven't been tested.

MENU DEFINITION

RECOMMENDATIONS

Use full pathnames for filenames.
Use multiple main menus for different classes of users.
You'll need various script files as wrappers around commands.
Look on Nyx (nyx.cs.du.edu, login as 'new') for various examples.

AUTHOR

BUGS

This document was created by man2html, using the manual pages.
Time: 06:46:12 GMT, December 12, 2024