The text-graphics (curses) interface is reminiscent of the vi visual editor, but is user-configurable to simulate other editors. This interface does not require graphics capabilities of the computer or the terminal on which it is run, but the terminal must have the minimum capabilities required by any visual screen editor.
The window interface for the Sun Workstation utilizes the icon and menu based (mouse selectable) windowing system. This tool (graphics) mode is highly subject to the version of operating system your Sun may be running. It is intended to be run on Sun versions 3.5 and higher (those that have the SunView window system).
See the corresponding sections for more information on the user interface desired. Most of this manual deals with commands, variables and actions that are common to all three interfaces although some attention is paid to individual characteristics of each interface.
The following command line arguments are understood by Mush (full word forms in parentheses):
NOTE: The -t option is obsolete and may be eliminated in future revisions. The preferred way to run the tool mode of Mush is to use the command mushtool, which is a link to mush.
New mail.
If during a Mush session, new mail arrives for you, it is automatically incorporated into your system mailbox and you are told that new mail has arrived.
In the default line mode, new mail is checked after each command issued. In the curses mode, new mail is checked on each command and is displayed in the bottom line of the screen. In the tool based graphics mode, new mail is checked approximately every minute or the number of seconds specified by the -T option on the command line.
If you are using your system mailbox as your "current folder," then the new mail is added immediately to your current list of messages and information similar to the following example is displayed, to tell you whom the mail is from:
New mail (#15) argv@zipcode.com (Dan Heller)
If you are not in your system mailbox, then the new mail is not added to your list of messages, but you are instead informed of the new arrival.
If you are using the tool based mode and Mush is closed to an iconic state, then the number of messages in the current folder is displayed on the mailbox icon and the flag on the mailbox goes up.
Displaying messages.
Depending on the interface you use, you can display any message in your list of messages as long as the message is not marked for deletion. If the message is marked as deleted, then use the undelete command supplied by the interface you are using. To display a message in line mode, specify the message using print, type, p, t, or type a message number to display that message on the screen.
In curses mode, move the cursor over the message you want and type a `t' or `p' to read the message. You may "bind" other keys to call the function that displays messages if `t' and `p' are uncomfortable.
In the tool mode, move the cursor over the header summary of the message you wish to be displayed and select the LEFT mouse button. The MIDDLE mouse button deletes the message, and the RIGHT button brings up a menu of additional options, including help. If the message you want is not visible (in the header subwindow), you may type the number of the message in the "Range:" item, and press return. That message number is displayed. Finally, the "Next" item in the panel below the header display can be used to step through the folder, one message at a time.
In the line or curses mode, if the message has more lines than the variable crt, then a pager is invoked to allow the user to page through the message without having it scroll off the screen. The pager used is determined by the variable pager. If that variable is unset, then a default pager is used. Note that if pager is set, but not to a value, or is set to the value of "internal", then the internal pager is used. The internal pager is very simple; the spacebar displays the next crt lines, carriage return prints the next line, and "q" quits the pager.
In the tool mode, if a message is larger than the size of the message subwindow, the scrollbar at the left side of the window may be used to page the message forwards and backwards. The variable crt_win may be set in an initialization file to preset the size of the message display subwindow.
An alternative to displaying messages is the top command. This command prints just the top few lines of a message. The number of lines is determined by the variable toplines. If this variable isn't set, top prints a number of lines equal to the value of the variable crt.
Sorting mail.
Mush allows you to sort your mail according to various constraints such as time, size, status (new, unread, deleted, etc.), author and subject. See the sort command in the COMMANDS section for more information on sorting. Sorting has a panel item in the tool mode, and is bound by default to the `o' (sort) and `O' (sort reverse) keys in curses mode.
Picking specific messages.
You can select messages that contain unique information, or from messages that have special attributes. You have the option of restricting your search to messages between dates, message numbers, author names and other constraints. See the pick command in the COMMANDS section for complete details. This feature is not directly accessible from the tool mode, and is available only as a search action in curses mode (see, however, the CURSES INTERFACE section for temporary escapes to line mode).
Sending mail.
You can send mail by listing addresses on the command line when Mush is started, by using the mail command from within Mush, or by responding to other mail. In curses mode, the `m' key invokes mail, and the `r' key begins a response. In the tool mode, selecting the "Compose" or "Reply" items on the main panel opens a separate frame for message composition. The message replied-to is either the current message or one specified in the "Range:" item.
When you are sending mail, you are in a mode where everything you type is added to the contents of the message. When you are done typing your message in line or curses modes, you can type `^D' (control-D) to signify the end of the message. If you have the variable dot set, then you can end a message with a `.' on a line by itself. In the tool mode, select the "Send" item in the composition frame to finish and send the message.
While you are composing a message, Mush treats lines beginning with the character `~' specially. This is called a tilde escape. For instance, typing "~i" (alone on a line) places a copy of the "current message" into your message body. It does not include the message headers of the message, just the body of text that comprises the message. A subset of these escapes are available in the tool mode, and others are provided as panel items or as menu selections from the "Include" item. Tilde escapes which alter message headers are not usable when the variable edit_hdrs is set or when the -E option was passed to the mail command.
The tool mode composition window uses header editing at all times, but provides some of these escapes anyway; see the descriptions below, and the description of the edit_hdrs variable, for complete details.
Available tilde escapes: [OPTIONAL arguments in square brackets]
The variable escape may be set to describe a character other than `~' to be used as the escape character. However, tilde escapes are normally NOT interpreted when Mush is started with redirected input. If tilde-interpretation is desired, use the -i option when starting mush.
Mail Aliases.
Mail aliases are shorthand names for long mail addresses. These are supported in the same manner as UCB Mail supports them. Because Mush has command line history reminiscent of csh, commands that use UUCP's `!' character for user-host and host-host separation should be escaped (preceded by a backslash). This is not necessary in the initialization file (.mushrc) because history referencing is ignored while these files are being sourced. See the INITIALIZATION and LINE-MODE INTERFACE sections for more information on initialization file format and the history mechanism.
Aliases reference normal mailing addresses as well as other aliases. If a loop is detected, then the user is notified and the message is forced into the file dead.letter in the user's home directory. The unalias command is used to reverse the effects of the alias command. From the tool mode, aliases can be set and unset in an aliases subwindow. Press the RIGHT mouse button on the "Options" item in the main frame, and select "Aliases" from the menu.
Help.
Mush was designed so that each command or action should not be a mystery. Helping the user understand what to do and how to do whatever he wishes is the goal behind the help facility. For this reason, the help command gives information on both general usage and a few specific help categories.
In text mode, most help is obtained by typing -? as an argument to a command. Almost every command has the -? option. When this option is specified, most commands attempt to read from a help file a brief explanation of the functionality of the command. If necessary, a pointer to other sources of information is given to fully explain a concept.
In line mode, typing `?' as a command displays a list of possible commands. In the curses mode, the `?' key displays help message, which explains how to obtain a list of the current key-to-command bindings; a keystroke or set of keystrokes correspond directly to a command.
In the tool mode, this is also available, but more extensive help is provided in the pop-up menus. Press the RIGHT mouse button (the "menu button") when pointing to any panel button and a number of items appear in a menu. The last command in the menu list is often one labeled "help". If a button does not have a menu or has no help item, check the menu of the "Help" button for related topics. Selecting any help item opens a new scrollable window with help text. Note: The limited number of file descriptors in SunOS 3.5 forces Mush to display help information in the message window in the main frame.
The user's file is determined by first looking for the environment variables MUSHRC or MAILRC. If neither of those environment variables is set, then the file .mushrc is searched for in the home directory of the user. If that file cannot be found, Mush attempts to read the file .mailrc from the same directory. Finally, if that file cannot be read, no initialization is done and the default values are in effect.
If the user has no home directory, or permissions prevent read/write access to $HOME, /tmp is used as the home directory. See the home variable under the VARIABLES section.
Once in the shell, the source command may be used to specify a file if you want to read commands from a file other than the default. The command saveopts saves all variable settings, aliases, and all other Mush settable attributes, to aid in creating an initialization file. If no filename is given on the command line, the source and saveopts commands choose a file in the manner described above. Saveopts does not overwrite the file if it exists. In such cases, you are prompted to confirm overwrite. If you confirm overwriting the existing file, remember that existing "if" expressions or other manually entered comments or non variable-setting type commands that previously existed in the file are lost.
No interactive commands should be called from any initialization file. These commands are not prevented because it is impossible to trace which commands are actually UNIX(TM) commands that are interactive. The responsibility of not running interactive commands is left to the user. Because the initialization file is read before any messages are read into the program, message filtering commands should not be placed in this file unless you know you're going to re-source the file later as a command.
Initialization File Format. When reading the initialization file, Mush recognizes the `#' character as a comment character. It may be anywhere on a line in the file. When that character is encountered, processing of that line is discontinued to the end of the line. If the `#' is enclosed in quotes (single or double), then it is not considered a comment. Examples:
set shell = /bin/csh # set the shell variable
# this entire line has been commented out.
set prompt = "Message #%m: " # The `#' is within quotes
The exit command has special meaning in the initialization file. If the command is found, Mush does not exit, but rather, discontinues reading from the file immediately.
There may be "if" expressions within the initialization file to determine certain runtime states of Mush. No parentheses are allowed and only one boolean expression may be evaluated per line; that is, no "&&" or "||" may be used in expressions. An "else" on a line by itself may precede alternative actions. "If" expressions may be nested to any reasonable depth, but there must always be an "endif" matching each "if" expression. The statements associated with an "if" expression are never on the same line with the conditional expression.
Conditional expressions understood include the internal variables istool, iscurses, is_shell, hdrs_only, is_sending, and redirect. These are internal variables whose values cannot be referenced using the "$variable" method of variable expansion. If istool is true, the program is going to run in the tool mode. If iscurses is true, the program is in or is going to run in the curses mode even though the screen package may not yet have been started. If is_shell is true, then Mush has entered the shell; is_shell is always false at startup when initialization files are read, and is always true when files are sourced after initialization with the source command or the -F option.
If hdrs_only is true, then the -H flag on the command line has been given. If is_sending is true, then the user is sending mail to another user. This does not imply that the user is not going to be running a shell after the mail is sent. If redirect is true, then input to the program is redirected. The test for redirection tells whether input, not output, has been redirected to the program. The -i option on the command line is required to run the shell if redirect is on. If -i is specified, the value for redirect is set to false. Note that any time Mush runs when not connected to a terminal, it believes that input has been redirected. See the MUSH SCRIPTS section for more details.
The `!' operator may be used to negate expressions, thus,
if !istool
exit else
set autoprint endif
means that if you are not running as a tool, stop reading commands from this file. Otherwise, set the autoprint variable.
set hdr_format = "%25f %7d (%l/%c) %25s" if hdrs_only
exit endif
This tells the program to set the hdr_format variable and check to see if we're running the program to read headers only. If so, stop reading this file (exit) and continue on with the program. This speeds up runtime quite a bit for those who have lengthy initialization files, because no other shell variables are necessary.
if !iscurses
set crt = 24 screen = 18 endif
This segment checks to see that we're not running in curses mode, and if not it sets our crt and screen sizes. This is mostly because the curses mode sets those values for us by looking at the size of the screen. See the CURSES INTERFACE section for configuring your environment so you enter curses mode each time you run the shell.
String evaluation is allowed in "if" expressions, and the operators "==" and "!=" may be used to determine equality or inequality, and "=~" and "!~" may be used for pattern-matching. Usually, variables are compared with constants for evaluation.
Note that it is not possible to compare variables to an empty string, and variables that evaluate to an empty string may cause errors. It is possible to test whether a variable is set by using the syntax "$?variable" (as in csh) but there is not currently any way to test for an empty string value.
if $TERM == adm3a
set pager = more else
set pager = less endif
This segment tests to see if the user's terminal type is "adm3a". If it is, then it sets the pager variable to be the more program. Note that the variable TERM is obtained from the user's environment if a shell variable is not set already. Otherwise, the pager variable is set to "less". This exemplifies the fact that less frequently fails to function correctly for the terminal type "adm3a" so we don't use it.
Also supported in "if" expressions are the test flags "-e" and "-z". These flags test to see if a file exists ("-e") or if it is zero-length ("-z"). These are most useful in command files that are to be read after the shell has started; see the examples in the MUSH SCRIPTS section.
After sourcing the initialization file, Mush reads all the mail out of the specified folder (the system spool directory if no folder is given) and creates a list of messages. The current maximum number of messages the user can load is set to 1000 by default. The system administrator who configures the program can reset this value higher or lower if you ask nicely. If the user has the sort variable set, then when the current folder's messages have all been read, the messages are sorted according to the value of the variable (see the sort entry under the VARIABLES heading for more information). Each message has a number of message header lines that contain information about whom the mail is from, the subject of the message, the date it was received, and other information about the letter. This information is then compiled into a one-line summary for each message and is printed out in an appropriate manner depending on the interface you're using.
At this point, commands may be input by the user. Lengthy or complex commands can be placed in a file and then executed via the source command. Such files use the same format as the initialization files and may use all the same tests in "if" expressions. Sourcing of a file of filter commands such as those in the example above can be automated by using the -F option when Mush is started. Also see the MUSH SCRIPTS section for other uses.
When a command line has been parsed and placed in an argument vector, the first argument in the vector (the "command") is searched for in a list of legal Mush commands. If found, the function associated with that command is called and the rest of the line is passed to that function as command line arguments.
Before commands are called, however, the input the user gives is preprocessed
in a style reminiscent of the C-shell
(csh).
Mush
also supports a subset from each of the following aspects of
csh:
* Command history.
* Command line aliasing.
* "Piping" mechanism to
redirect "input" and "output" of commands.
* Filename metacharacters.
Command history.
Mush supports a history mechanism similar to that supplied by csh. A subset of csh history modifiers are supported to reference previously issued commands and to extract specified arguments from these commands.
The history mechanism remembers a list of past commands whose length is bounded by the value of the history variable. If this variable is not set, only the most recent command is remembered. To reference previously typed commands, the `!' character is used in the same manner as in csh. There is a limited implementation of history modification; supported are the argument selectors that reference command line arguments and ":p" (echo, but don't execute the command).
Examples:
!-2:$ two commands ago, last argument. !3:2-4 the third command, arguments two through four. !!:p print the last command in its entirety.
During the sourcing of initialization files (.mushrc), history is not in effect and therefore the `!' character does not cause history expansion. This includes startup of the program and when the command source is issued. UUCP style addresses that contain the `!' character may be given in the initialization file without the need to be preceded by a backslash. However, `!' does need to be escaped if cmd's are used to reference command line arguments.
Command line aliasing.
Command aliases are different from mail aliases in that they are used to expand to commands. This feature enables command substitution similar to csh. To be backwards compatible with UCB Mail, the alias command is used for address aliasing. Thus, the command cmd is introduced in place of alias.
Examples:
cmd d delete cmd t type cmd dt 'd ; t' cmd - previous cmd r 'reply \!* -e -i'
In the last example, if the user types "r 5", Mush replies to sender of the fifth message and pass all the other arguments along to the reply command. Note the escaping of the `!' character. This must also be done if set in the initialization file (.mushrc). Had the user not specified a message number on the `r' command line, reply would respond to the "current message" rather than the fifth message.
Piping commands.
Mush commands can be "piped" to one another so as to provide output of one command to be used as input to the next command in the pipeline. However, the output of commands is not the "text" that is returned (as it is in sh and csh), but instead is a message list of the messages that were affected. A message list is defined as the set of messages that the user specifies in a command or the messages a command affects after it is through executing. When one command is piped to another, the effect is that the second command considers only those messages affected by the first command. In most cases, Mush is smart enough to know when piping is occurring and may suppress text output that a command might produce.
Examples:
pick -f fred | save fred_mail
This finds all the messages from "fred" and saves them all in the file named fred_mail.
lpr 4-8 | delete
This sends messages 4, 5, 6, 7, and 8 to the printer and then deletes them.
headers :o | delete
Deletes all old (already read) mail.
Because action is taken on mail messages, not files, metacharacters such as `*' and `?' are not expanded to file names as csh does. Instead, Mush commands take message lists as arguments (a list references one or messages) to take action upon. When referencing message numbers, Mush understands the following special syntax:
* All messages ^ The first message $ The last message . The current message N-M A range of messages between N and M, inclusiveIn the last case, N and M may be * ^ $ . or digits referencing explicit message numbers. The range must be in ascending order.
You can also negate messages by placing the message list inside braces, `{' `}' -- thus, the expression "2-19 {11-14}" references messages 2 through 19 except for messages 11 through 14.
Note that message lists are parsed left to right. Negated messages may be reset by turning them on again later in the argument list. A common error new users make is to specify a negated list without specifying any beginning messages.
delete { 6 }
In this example, the user attempted to delete all messages except for number 6. He should have specified `*' beforehand. A correct example:
preserve ^-. { 3 }
Here, the user specifies a valid message list and causes Mush to preserve all messages from the beginning of the list (message 1) to the current message, excluding message 3.
As discussed, after the command line is parsed, the command given is called and the rest of the arguments on the command line are passed to it. If no Mush command has been found that matches the one given, then the variable unix is checked. If it is set, Mush attempts to run the command line as a UNIX(TM) command.
If unix is not set, or if the command could not be found in the user's PATH environment, a message is printed indicating that the command was not found.
Since no "messages" are affected by UNIX commands, those that appear within Mush pipelines are executed by the pipe command. A UNIX command may never be the first command in a pipeline unless the pipe command is used explicitly. If the user wishes to execute UNIX commands that are to be piped to one another (or use any sort of redirection), the command sh is provided for such purposes. Since Mush parses the entire command line, caution should be taken to enclose questionable shell variables or metacharacters with quotes to prevent Mush from expanding them. See the COMMANDS heading below for more detail.
This shell-like quality is for the convenience of the user and is not intended to replace the functionality of sh, csh, or any other command interpreter.
Filename metacharacters.
Mush's command interpreter does not normally pre-expand metacharacters in the manner of other shells, because the metacharacters may refer to either messages or files. Instead, those commands that deal with file names do any necessary metacharacter expansion. Two metacharacters are nearly always recognized: `~' refers to the user's home directory, and `+' refers to the user's folder directory ("~/Mail" or the value of the variable folder). Another user's home directory can also be referenced as "~username", and for this reason files in the user's home directory must be referenced as "~/filename". However, the `/' character is optional when referring to folders; that is, "+filename" and "+/filename" both refer to the same file in the folder directory.
If filename completion is enabled by setting the variable complete, the command interpreter expands csh-style metacharacters when completing filenames. A completion containing metacharacters expands to all the files matching the pattern when the completion key is pressed (defaults to ESC, `^['). See the description of complete for limitations of this facility.
Many users who prefer the curses interface might want to always start all their mail sessions in the curses interface. Putting the curses command in your initialization file is allowed, but you can also create an alias or function in your login shell to always use the -C option. Mush attempts to know not to run a shell if you're just sending mail to someone, so the csh command sequences:
% alias mail 'mush -C'
% mail fred
sends mail to fred but does not enter the shell. However, if you just said "mail" with no arguments, you enter the shell in curses mode if you have mail. If you have no mail, you are told so, and the shell does not start. If you want to enter curses mode even if you don't have mail, use the -S option on the command line.
In curses mode, the user's terminal has its "echo" turned off so commands that are issued are not echoed on the screen. Certain commands cause the mode to return to normal for typing purposes (sending mail, for example). In normal operation, the screen displays the current set of message headers, the current message number is in the top left corner, the mail status on the top line, and the cursor is placed on the current message. The number of message headers displayed is set by the variable screen. If the user does not have that variable set, the baud rate is checked and the size of the screen is set according to optimal refresh time. Usually, 300 baud gives 7 lines, 1200 gives 14, 2400 gives 22 lines, and all higher baud rates give the size of the screen, whatever that may be. Note that the top line is reserved for "status" and the bottom line is for user interaction should it be required.
The user may now type commands via key sequences that are not echoed to the screen. Thus, function keys may be bound to "commands" by using the bind command. A list of key-to-command bindings can be found at runtime by typing `?' in curses mode or by using the bind command in line mode.
The commands to which you can map sequences are intended to be as self explanatory as possible, but admittedly, it might be easier to figure out via trial and error than to try to wade through this documentation. A list of the legal curses commands can be obtained when executing the bind command. Regular tty line-mode commands are not issued from the curses interface; only special curses mode commands are understood. The current list of valid curses commands is:
alias last-msg saveopts back-msg line-mode screen-back bind lpr screen-next bind-macro mail search-again bottom-page mail-flags search-back chdir map search-next copy map! shell-escape copy-list mark sort delete my-hdrs sort-reverse delete-list next-msg source display preserve top display-next quit top-page exit quit! unbind exit! redraw undelete first-msg reply undelete-list folder reply-all update goto-msg reverse-video variable help save write ignore save-list write-list
The following is a list of default key-command bindings. If you specify bind commands in your initialization file that conflict with these defaults, your settings override the defaults. The default settings given in this manual use the ^-character method to indicate control characters (mostly because nroff makes printing the backslash character so amazingly difficult). Thus, `^X' means control-X even though you have to type "\CX" to set the binding and actually use the control key and the `X' key simultaneously to really do a Control-X.
goto msg: `pick -f argv`
This causes the current message to move to the first message in the current folder from the user "argv" that comes after the message pointed to when the "goto" was issued. So, if messages 1 and 5 are from the user "argv" and the current message the user was on was message 3, then the new current message is message 5, since it is the first message found after message 3 that is from "argv". If none of the messages are found after the current message, the new current message is the first one returned by the command.
When setting new key sequences to be bound to commands, the user may use control keys and the ESCAPE character for extended commands. Exceptions are control-C, control-\, and possibly other control characters depending on your system's configuration or your current tty mode settings.
When assigning key sequences to commands, the user enters the bind command and prompting is done. If the user wishes to have control characters or the escape character in a key sequence while still using ASCII format, a special notation for control characters is provided. This sequence is used primarily for the use of binding control character sequences in the initialization file. This format is also used to display the current key-command mappings by the program.
To specify control characters in ASCII format for the bind command, the sequence "\Cc" is used where `c' is the character that the control key translates to and must be in upper case. The sequence "\CP" maps to control-P. If the user wishes to indicate the RETURN key, this is specified with the string "\n" and the tab key is specified by the string "\t". As a more complex example, on a Wyse-50 terminal, the 8th function key outputs the three characters: control-A, H, line-feed. To map this function key to a command, the user must enter the sequence "\CAH\n" as the key sequence, then follow up with a valid curses command. From then on, if the user presses that function key, the command mapped to it is executed.
The ESCAPE key is signified by the sequence, "\E". On a Sun-3 workstation, the R1 key outputs the character sequence: ESC, [, 2, 0, 8, z. The corresponding bind key sequence is "\E[208z". Restrictions are that key sequences may not contain the space character unless bound in line mode, and can never begin with a digit.
Whenever a command is entered, other than `^L' (redraw), which causes the screen to scroll or be refreshed in any way, Mush is left in the continue mode. When in this mode, the user is given his line-mode prompt followed by "...continue..." indicating that he may issue a new command or return to the top level where the current message headers are displayed on the screen. Remember that this is still the curses mode, but much time is saved by avoiding redrawing the screen after each command. The user may move up and down messages using the appropriate commands (j/k by default) or anything else the curses mode allows. Only the exit and quit commands return to the top level. Because of this, there are 2 additional ways to "quit" from curses mode and return to the login shell. The "exit" and "quit" commands quit from the top level, but the commands exit! and quit! are used to exit from the "continue" level in the curses interface as well as from the top level.
Note that the best way to understand the curses interface is to just use it. In line mode, the command "curses" puts you into curses mode.
In the header summary window, pressing the LEFT mouse button while pointing at a message header displays that message in the large message window at the bottom of the frame. Pressing the middle button deletes the message, and pressing the RIGHT mouse button displays a menu of actions that affect the message. Possible actions are to display the message, delete or undelete it, reply to it, save it, preserve it (see the preserve command), or print it (hardcopy).
All panel items in the frame have labels describing their functionality. Selecting a panel item with the LEFT mouse button causes the action to be executed. The RIGHT mouse button displays a menu of options that the command may branch to. For example, the Save panel item by default saves messages to the file "mbox", but the RIGHT mouse button causes a menu to be displayed, and the choices of where to save the message increase to include the items in the menu. These typically include the files in the user's folder directory (see the folder variable below).
At the end of most lists of menu entries for panel items is an item labeled "help". When this item is chosen, an new window is opened where help for that command is displayed. The help windows can be scrolled in the same ways as the message display window. Note: The limited number of file descriptors in SunOS 3.5 forces Mush to display help information in the message window in the main frame.
When composing letters, a separate frame is created which includes a panel of command items, a four-line scrollable window, and a large window for editing the letter. Panel items for including messages, editing (via your usual text editor), sending, aborting the message, and various other manipulations are supplied. See the section on "Sending mail", under the summary of tilde escapes, for more details of composition frame command items. As long as the composition frame is open, all Mush command output is redirected from the small window in the main frame to the small window here. Note: This subwindow is not present in SunOS 3.5 due to the limited number of file descriptors; command output stays in the main frame in that case. The SunView textsw interface is used by default in the large window for paging and editing. Cursor movement with the function keys (R8, R10, R12, and R14 by default) is supported.
The ability to customize commands using the cmd facility allows users to customize Mush to resemble other mailers. However, efforts have already been made to include commands that are backwards compatible with other line-mode mailers. Users of the graphics tool mode of Mush may have little need for the command line mode because the icon based interface allows interaction with many commands. The tool mode is much more restrictive in favor of a simpler, user friendly interface, but most useful commands may be achieved anyway.
The following is a list of all recognized commands. Since most commands accept a message list as an argument, arguments are noted only when they differ from a message list.
alias dan dheller@cory.berkeley.edu argv@zipcode.com
This defines the name "dan" to be shorthand for two addresses, both of which happen to be Dan Heller.
The command unalias can be used to remove an alias definition.
With no arguments, alias prints out all the current aliases. With one argument, it prints the list associated with that name, and with more than one argument, it creates a new alias.
If you have another login name on the local or remote machine, then that login may be specified either as "user@machine" or by preceding the login name or a UUCP path to the login name by a `!' character.
For example,
alts zipcode maui1 dheller@cory.berkeley.edu !root
are all either hostnames or pathnames to accounts owned by the same user. The last item, "!root" matches mail to "root" only if it is destined for the local machine, e.g. a workstation. Root accounts elsewhere are not considered to be equivalent. The address "dheller@cory.berkeley.edu" indicates that at the machine "cory.berkeley.edu" the user "dheller" is the same person as the current user at the local machine. This could also have been specified in UUCP format:
alts !cory.berkeley.edu!dheller
The leading `!' character is required to differentiate paths ending in a login name from those to which the user's login name should be appended.
If the alternates command is given with no arguments, the current set of alternate names is displayed. Names entered in "user@machine" form are displayed in UUCP format. Note that alternates is not cumulative; any arguments given to the alternates command removes the current list and replace it.
If no arguments are given to bind, the current set of curses bindings are listed; if only a string argument is given, the binding for that string is listed; and if both a string and a command are given, a curses binding is created such that when the string is typed in curses mode, the function specified by command is executed.
Bindings can be removed by using the unbind command.
If no arguments are given, bind-macro lists the current curses mode macros. It is otherwise identical to bind string macro expansion.
The argument off may be used only in initialization files, including those read with -I (-init), and has the effect of turning off the -C switch. Off is ignored at all other times, even in files read with -F (-source).
If the user suspects memory allocation problems, a debugging level of 5 or higher prevents memory from being freed so that memory bounds won't get overwritten.
If the user suspects Mail Transport Agent errors, a debugging level of 3 or higher prevents the MTA from starting and outgoing mail is directed to the standard output instead of actually being sent.
Examples:
echo -h This message is from %a and is dated %d.
might produce:
This message is from zipcode!argv and is dated Dec 14, 1988.
echo -p There are %n new messages to read in %F.
might produce:
There are 5 new messages to read in /usr/spool/mail/argv.
Note that -h and -p cannot be specified together.
If the -h option is given, eval expands header format strings in the argument list before executing the command. Similarly, the -p option expands prompt format strings in the argument list before executing. These formats are expanded last, after all history and variable expansion is completed, and are implicitly quoted, so embedded quotes, spaces, tabs, `!'s, etc. are handled correctly. Header formats are expanded using the current message. For example,
eval -h pick -f %a
finds all messages from the same author as the current message. See the the entries for hdr_format and prompt in the VARIABLES section for more details.
Note that -h and -p cannot be specified together.
D deleted f forwarded N new O old P preserved p printed R read r replied-to S saved U unread
If a `+' or `-' is included in the list of bits, the specified bits are turned on or off respectively, without modifying other bits. If no `+' or `-' is given, then the list of bits is set explicitly and all other bits are lost. The `-' modifier can be escaped with a backslash (i.e., "\-") to prevent its interpretation as part of a message range, or it may be given after the list of bits for the same reason.
Message lists can be piped to or from the flags command; for example, you may use
cmd r 'flags \!* + r | reply'
to mark as replied-to all messages included in a reply.
-N No headers are displayed upon entering new folder -n The current folder is not updated -r Set Read-Only mode (can't alter new folder) %[user] Change to /usr/spool/mail/[user] (default is yours) # Switch back to the previous folder & Change folder to $mbox (default is ~/mbox)
File names that do not begin with `/' are interpreted relative to the current directory unless they begin with one of the metacharacters `+' or `~'. As in csh, the character `~' expands to the user's home directory (or to some other user's home directory if used as "~username"). The character `+' is expanded to the name of the user's folder directory (defaults to "~/Mail" or the value of the variable folder). For compatibility with other mailers, no `/' character needs to appear between the `+' and the name of the folder (see "Filename metacharacters" in the LINE-MODE INTERFACE section).
This command can only appear in a pipeline if it is the first command; it returns a list of all the messages in the new folder. This command cannot be used in initialization files before the shell has started.
For compatibility with older versions, the argument `!' with no leading `-' is interpreted as -n.
The special arguments `-' and `+' can be given to move the current message pointer to the previous or next message, respectively, while also printing that message's header. If a message list was given in addition to `-' or `+', then the current message pointer is set to the first or last message, respectively, in the message list given. Examples:
from + Dan
prints the headers of all messages that contain "Dan" in in the author's name and set the current message pointer to the last one of that kind in the list.
from - 10-30 {16}
prints the headers of messages 10 through 30 except for message 16 and set the current message pointer to 10.
from +
prints the header of the message after the current message and increments the current message pointer to the next message.
from $
prints the last message's header but does not move the current message pointer.
A typical header may look like:
> 5 N argv@spam.istc.sri.com Feb 19, (10/278) Test
This line indicates that it is message number 5 and the `>' indicates that the "current message pointer" is pointing to this message. The next two positions indicate the message status. The first may be one of, "N" (new and unread), "U" (old, but still unread), "*" (deleted), "S" (saved), "P" (preserved), or " " (read). The second position may have an "r" if the message has been replied to, an "f" if it has been forwarded, or a "p" if it has been printed.
The author of the example message header is argv@spam.istc.sri.com, the date is Feb 19, the number of lines in the message is 10, the number of characters is 278 and the subject of the message is Test. The format of the message header shown here is described by the string variable hdr_format. The example given above has a hdr_format of
set hdr_format = "%25f %7d (%l/%c) %25s"
See the description of hdr_format in the VARIABLES section for more information on header formats.
You can print a special subset of message headers by using the -H:c option, where `c' is one of:
a all messages d deleted messages f forwarded messages m marked messages n new messages o old messages p preserved messages r replied to messages s saved messages u unread messagesNote that the -H is not required; "headers :c" is valid.
More options to the headers command include `+' and `-'. Each prints the next or previous screenful of message headers. The z command can also be used; `z' alone prints the next screenful (thus, the `+' is optional) and "z -" is equivalent to "h -".
Headers affects all the messages it displays, so piping may be done from the headers command. Piping to the headers command causes the message headers affected by the previous command to be printed. This action is identical to piping to the from command.
If no help file is found, an error message is printed. The location of the help files may be reset by setting the variables cmd_help and tool_help to the paths of the new help files.
The tool_help variable is recognized only by versions capable of using suntool mode (tool mode need not be active).
If a number N is given, then that number of previous commands is echoed rather than the number set by the variable history.
See the LINE-MODE INTERFACE section for a description of referencing the history in commands.
ignore Received Date Message-Id
ignores the three specified fields. Additional ignore commands are cumulative. The command unignore is used to reverse the effects of ignore.
For another way to control this, see the variable show_hdrs.
If the variable print_cmd is set, the command described by that variable is used instead of the default system command. In such cases, the -P option and the printer variable are ignored and the command is simply executed as is.
The "printed" status bit is set for each message printed by this command.
Note: If "lpr -Pprinter" produces an error message, your system administrator may have configured Mush to require -d in place of -P.
Example:
mail username, /path/to/filename, "|program_name", +folder_name, ~user/mbox
Options are:
-b addr-list set list of blind carbon recipients -c addr-list set list of carbon copy recipients -E edit outgoing message headers -e immediately enter editor (autoedit) -F add random fortune to the end of message -f [msg-list] forward messages (not indented) -H file read file as prepared text (no headers) -h file read file as a draft (text and headers) -I [msg-list] include messages with headers (indented) -i [msg-list] include messages in letter (indented) -s [subject] prompt for subject [set subject explicitly] -U send draft immediately (use only with -h) -u unsigned: no signatures or fortunes added -v verbose (passed to mail delivery program)
The verbose option may not be available depending on the mail transport agent on your system.
The -e flag causes you to enter the editor described by the variable visual.
The -E flag causes Mush to place the headers of the outgoing message in the editor file so they can be changed. See the description of the variable edit_hdrs for details.
The -i flag includes the current message into the body of the message you are about to send. The included message is indented by the string "> " or by the string described by the variables indent_str, pre_indent_str, and post_indent_str. See the VARIABLES section for more information on these string values. If a message list is given after the -i option, then the messages described by that list are included. The -I option is identical to the -i option except that the headers of the message are also included.
The -s flag looks at the next argument and sets the subject to that string. If the string is to contain spaces, enclose the entire subject in quotes. If there is no following argument, then the subject is prompted for. This flag is useful if the user:
* does not have the variable ask set, or * wishes to change the subject used with reply
The subject is not prompted for and is ignored completely if the -f flag is specified (see below).
The -f flag is for message forwarding only. An optional message list can be given just as the -i option has. The forward option does not allow you to edit the message(s) being forwarded unless the -e flag is also specified. The subject of the message (if available) is the same as the current message; it is not necessarily the subject of the message being forwarded. The subject of forwarded mail cannot be changed. However, using the -e flag allows the user to change the subject once in editing mode either by using the escape sequence, "~s", or by editing the "Subject:" header.
Forwarded mail that has not been edited by the user contains special headers such as
Resent-To:
Resent-From:
and perhaps others, depending on your mail transport agent. Sendmail, for example, may add a number of other "Resent-*" headers.
The -u option, meaning "unsigned", prevents signatures and fortunes from being appended to the message. It overrides the variables autosign and fortune, but affects the -F option only if given after it on the command line.
The -h option indicates that the given file is a previously prepared message, possibly a partial one saved with "~w". Such a file is called a draft. The file argument must be given, and in the current implementation all message headers must either be present in the file or must be added manually by the user. At minimum, there must be a "To:" header; Mush adds "From:" and "Date:" headers when sending, if necessary. To read a prepared text file that does not contain headers, use -H. If the -U option is also given, then the letter is sent immediately without further editing.
If no arguments are given, these commands display the list of macros and expansions for the appropriate mode. If only a string is given, they display the expansion associated with that string for the appropriate mode. Otherwise, they create a macro, associating the given expansion with the specified string.
Line mode macros are unset with the unmap command, and composition mode macros are unset with the unmap! command.
If no pririty is specified, the message is given a temporary mark. Messages may have both a temporary mark and a priority, but may not have more than one priority. Priorities are shown by the appropriate letter code immediately following the message number in the header display. The presence of a temporary mark is shown by a `+' character. Temporary marks are considered to have the highest priority for sorting and are shown in place of the regular priority if both are set on a given message. However, temporary marks are not saved when the folder is updated.
The command
headers -H:m
(abbreviated as ":m") can be used to generate the list of messages
with temprary marks.
For example:
mark -C 7
assigns priority C to message 7. You can clear the priority of a message by specifying a lone `-' argument:
mark -
This does not remove temporary marks, only priorities. The command unmark is used to remove temporary marks.
Command usage: my_hdr print all your headers my_hdr header print value of header my_hdr header: string set header to string un_hdr header: unset headerTo set a header, the first argument must be a string that contains no whitespace (spaces or tabs) and must end with a colon (:). The rest of the command line is taken to be the text associated with the mail header specified. If any quotes are used in the header and the header itself is not set in quotes, then quotes should be escaped (preceded) by a backslash. This holds true for semicolons, pipe characters or any other metacharacter that Mush might interpret as a command line modifier.
If the variable no_hdrs is set, then your headers are not added to outgoing messages, but no headers are unset. The un_hdr command may take `*' as an argument to un_hdr everything set.
Example:
my_hdr Phone-Number: (415) 499-8649
Mush treats the the header "From:" as a special case. If you have set your own From:, a simple test is performed to determine whether the address given is valid. Any UUCP or domain address that directs mail to your login at the local machine should be acceptable, but certain configurations may prevent some combinations from being recognized. If the address is valid, your From: header is used; otherwise, an address known to be valid is generated and used instead. Some mail transport agents are "picky" and do not allow Mush to supply a From: header; in these cases, your From: header is silently removed at send time, and replaced with one generated by the MTA.
Note: You cannot set the "Date:". Attempting to do so does not result in any error messages; your date is simply overwritten by the system when your mail is sent.
Options: +<num> keep only the first <num> messages matched (head). -<num> keep only the last <num> messages matched (tail). -ago <format> search for messages relative to today's date. -d [+|-]date messages sent on or [+ after] [`-' before] date. -e take all remaining arguments to be the pattern. -f search for pattern in "From" field only. -h header search for pattern in specified header only. -i ignore case of letters when searching. -p priority select messages with given priority (A,B,C,...) -r msg-list search only the listed messages. -s search for pattern in "Subject" field only. -t search for pattern in "To" field only. -x select messages that do not match the pattern.
The -ago option can be abbreviated as -a. Only one of -a, -d, -f, -h, -p, -s and -t can be specified at once, but multiple -p options may be specified to select several priorities. Entire messages are scanned for the <pattern> unless -a, -d, -f, -h, -p, -s or -t is specified. Messages marked for deletion are also searched. No patterns can be specified with the -a or -d options. The -x option may not be used in conjunction with +n (head) and -n (tail).
For the -d option, "date" is of the form:
month/day/year
with an optional `-' to specify that the messages of interest are those older than that date. Omitted fields of the date default to today's values. Examples of selecting on date:
pick -d 4/20 on April 20, this year. pick -d -/2/85 on or before the 2nd, this month, 1985. pick -d +5/4 on or after May 4 of this year. pick -d / today only.
At least one `/' char must be used in a date. There is no strong date checking; 2/30 is considered a valid date.
For the -ago option, the format is very simple. Specify the number of days followed by the word "days", or the number of weeks followed by the word "weeks", and so on with months and years. Truncation is allowed, since only the first character is examined, so all of the following are equivalent:
pick -ago 1 day, 2 weeks pick -ago 2Weeks 1Day pick -ago 2w,1day pick -a 2w1d
These examples find all messages that are exactly 2 weeks and 1 day old. All "ago" dates collapse into "day" time segments. This means that months are 30.5 days long. If more precise date selection is required, use the -d option and specify specific dates.
Also note that the -ago option allows the "before" (-) and "after" (+) arguments. Thus, you may pick all messages older than 1 week with:
pick -ago -1 week
Other examples of pick:
pick -d 2/5/86 | pick -d -2/5/87 | pick -s "mail stuff" | lpr
Will find all the messages between the dates February 5, 1986, and February 5, 1987, that contain the subject "mail stuff" and send them to the printer.
pick -s Re: | delete
Deletes messages that have "Re:" in the Subject header.
folder +project | pick -f frank
Finds all messages from frank in the folder described by +project.
pick -h return-path ucbvax
Searches all messages that have the header "Return-Path:" and determines if the string "ucbvax" is in the header. Note that case sensitivity applies only to the pattern searched, not the header itself.
pick -ago +1w | save +current
This finds all messages that are a week or less old and saves them in the file called current, which is found in the user's folder variable.
pick +3 mush-users
Finds the first three messages containing the string "mush-users".
eval -h "pick +2 -r .-$ -s %s" | pick -1
Finds the next message with the same subject as the current message.
pipe 3 5 7 patch
sends the text and headers of messages 3, 5 and 7 to the patch utility.
If a pattern is specified with the -p option, Mush searches the message for a line beginning with that string. The matching line and all succeeding lines are sent to the unix-command. If -p is not given, and the unix-command is omitted, Mush searches for a line beginning with "#!" and feeds that line and all succeeding lines to "/bin/sh". Thus, pipe with no arguments treats the current message as a shell script.
The pattern may also be of the form
/pattern1/,/pattern2/
in which case printing begins with the line containing
pattern1
and end with the line containing
pattern2
(inclusive).
Patterns of this form must still match at beginning of line, and
regular expressions are not currently allowed.
The pipe command can also be invoked as Pipe (note capitalization), in which case only the body of the messages, and none of the message headers, are sent to the unix command.
When the variable unix is set, UNIX(TM) commands can appear anywhere except as the first command in a Mush pipeline without explicitly using pipe. However, it is still necessary to specify Pipe in order to exclude all headers.
Note: All messages listed as arguments to pipe or Pipe are sent to the standard input of the same process as a continuous stream, in message number order! This is probably not desirable when extracting shell scripts in particular, so take care.
The `+' and the `-' keys can be used to display the "next" and "previous" messages respectively. The `+' key has the caveat that the message is not paged at all and none of the messages headers are displayed.
When constructing a return mail address to the author of a message, reply searches for special mail headers in the author's message that indicate the most efficient mail path for return mail. Mush searches for the "Reply-To:", "From:", and "Return-Path:" headers, in that order, by default.
If none of these fields are found in the message, the first line of the message is parsed if possible; this "From " line is different from the "From: " line. If the user wishes to change the order or the actual fields to search for return paths, then the variable reply_to_hdr may be set to a list of headers to be used (in the order specified). If it is set, but has no value, the first "From " line is used regardless of what headers the author's message contains. The "From " line may be specified explicitly as an item in the list of reply-to headers by specifying the header "From_". See the VARIABLES section for more information about reply_to_hdr.
When replying to all recipients of the message using the replyall (R) command, only the original author's address can be obtained from the message headers. There is no way to determine the best path to the other recipients of the message from message headers aside from taking their addresses directly from the "To:" and "Cc:" lines.
Example:
replyall 3,4,5 -i 4,5 7 -s response mail-group
Here, messages 3, 4 and 5 are replied to (all the authors are obtained from each of those messages as well as the recipients from those messages) and the text from messages 4, 5 and 7 are included in the body of the reply. The subject is set to "response" and the alias mail-group is appended to the list of recipients for this message.
The -r flag prefixes the address of each recipient in the address list with the indicated path. This overrides the value of auto_route, but has the exact same functionality. See the explanation of the variable in the VARIABLES section. Also see the MAIL ADDRESSES section for more information concerning replying to messages.
If the file exists and is writable, the specified command appends each message to the end of the file. If -f is given, then the file is overwritten causing whatever contents it contains to be lost. For compatibility with older versions, the character `!' may be substituted for -f (no `-' is used with `!'). Note that -f has no effect when used with -a or -s.
If the current folder is the system mailbox, then saved messages are marked for deletion when the user exits using the quit command. If the variable keepsave is set or the current folder is not the system mailbox, then messages are not marked for deletion.
The write command differs from save and copy in that the message headers are not saved in the file along with the body of text. The copy command is is like save except that messages are never marked for deletion, whether or not keepsave is set.
Note: The permission mode of files created by these commands allow read and write only by the owner of the file. The permissions of existing files are not changed when messages are saved or written to those files.
The special command
set ?all
prints all known variables utilized by the program and a brief description of what they do. The user may set and manipulate his own set of variables, but internal variables that are utilized by the program are the only ones displayed.
The command
set ?variable_name
prints the same information for one variable instead of all variables. You may unset everything by issuing the command "unset *". Note that some variables are essential to the operation of the program and are restored to a default value even when they are explicitly unset.
It is possible to set a variable to a list of messages returned by another command by using the piping mechanism. For example,
pick -s Status Reports | set reports
The variable reports now contains a message list which can be used as the message list argument to any command which accepts a list.
mail -i $reports boss
This command sends mail to "boss" and includes the text of all the messages held in the reports variable.
Options: -i ignore case in alphabetical sorts -r reverse sort order of next option -a sort by author (alphabetical) -d sort by date -l sort by length of message -p sort by message priority -R sort by subject including "Re:" -s sort by subject (alphabetical) -S sort by message status
By default (no arguments), sort sorts messages by status. New, unread messages are first, followed by preserved messages, and finally deleted messages are placed at the end of the list. If status is otherwise the same, priority is used to order the messages. If -r is the only option given, the status ordering is reversed.
Sorting by priority orders marked messages first, followed by messages having a priority setting (A having higher precedence than B, and so on), and finally messages having neither a mark nor a priority. See the mark command for information on attaching marks and priorities to messages.
When sorting by date, the boolean variable date_received is checked. If it is set, then sorting goes by date received. Otherwise (default), sorting is by date sent by the original author.
If more than one sort option is specified, they are applied in left-to-right sequence to each comparison. Thus:
sort -a -d
sorts messages by author and, if the author of any set of messages is the same, sorts within that set by date. Note that the -r option applies to only one other option at a time; to reverse the sort of both author and date requires:
sort -r -a -r -d
The options can also be grouped:
sort -ra -rd
sort -rard
Currently, only the line mode interface supports multiple sort criteria, but the other interfaces allow subsorting indirectly when appropriate actions are taken, as discussed below.
It is also possible to sort a consecutive sublist of messages by using pipes. If the mailbox is already sorted by author,
pick -f argv@zipcode.com | sort -s
finds all messages from the user "argv@zipcode.com" and sort them by subject. You may specify the exact message list by specifying that message list on the command line and using a pipe:
10-. | sort d
This command means to sort the messages from 10 to the current message according to the date.
To specify subsorting from with the curses interface, the temporary curses escape key must be used (the colon `:') and the command issued at the `:' prompt (as if giving an "ex" command to "vi"). When the command is finished, the "...continue..." prompt is given and the user may continue or return to the top level of the curses mode.
In the tool mode, subsorting can be specified only by typing message numbers in the "Range:" item at the top of the main frame, before selecting the "Sort" item. The sort range must consist of consecutive messages. Reversed sorting is not currently available in tool mode.
If the variable sort is set, messages are sorted each time the user's system mailbox is read as the current folder. The sort variable can be set either to nothing or to legal "sort" arguments.
Note: For compatibility with older versions, sort options are recognized even if they are not preceded by a `-'. Also, if a `-' is given by itself (separated by spaces from any following arguments) it is interpreted as -r.
The -m option merges these messages into the current folder. Otherwise, if a filename is specified, a new folder is created and the user can change folders to read the messages separately.
The -p option specifies an alternate pattern to be used as the digest article separator. This pattern must match literally at the beginning of the line. The default pattern is "--------" (eight hyphens). This is the defacto USENET standard digest article separator and should work for most digests, but some use another separator. The -p option is also useful for "bursting" forwarded messages out of a wrapper message; for example:
undigest -m -p "--- Forward"
bursts out messages forwarded by another user of Mush and merges them into the current folder.
If a message list is specified, each digest in the list is disassembled to the same filename (if given). If no filename is given and the user did not request a merge, then a temporary file is made. The name of the temporary file is generated from the subject of the digest.
See the folder command for complete information.
If you or the program references a variable that is not explicitly set, then the environment variables are checked and that data is returned. A few variables (notably prompt, cmd_help, and tool_help) do not check the environment.
Variable values can be modified by one of four variable modifiers, or by a numeric string. The modifiers `:h', `:t', `:l' and `:u' may be applied to the variable names. The current implementation allows only one `:' modifier on each `$' expansion.
Following is a list of all variables with predefined meanings.
This variable can also be set to a list of words separated by commas or spaces. Currently recognized words, and their meanings, are:
forward Ignore headers when forwarding messages (~f). include Ignore headers when including messages (~I). pipe The pipe command ignores headers. printer The lpr command ignores headers.
Also see the ignore command and the show_hdrs variable for more information.
For example, if the original sender of a message came from the remote host c3p0 and the list of recipients looked like
From: c3p0!user1 To: yourhost!you Cc: r2d2!user2, r2d2!user3
then clearly, "user1" on the machine c3p0 can talk to your machine and the machine named r2d2. However, you would not be able to respond to those users if your machine did not exchange UUCP mail with the host r2d2.
Mush attempts to solve this problem by reconstructing the addresses for "user2" and "user3" according to the address of the original sender, "c3p0". The new addresses for "user2" and "user3" should therefore become
c3p0!r2d2!user2, c3p0!r2d2!user3.
If your machine not only talks to c3p0, but talks to r2d2 as well, it becomes unnecessary to route the mail through both c3p0 and r2d2. So, the variable known_hosts may be set to a list of hosts which you know your machine to have UUCP mail connections with. This list is checked when constructing mail addresses for replies only and the shortest path is made by removing from the UUCP path those hosts that do not need to be called or are redundant. See the entry for known_hosts for more information.
If auto_route is set to a specific pathname (host names separated by !'s), all addresses in the reply have this route prepended to their addresses. This ignores the original path of the author. This is quite useful for hosts which talk uucp to a node which is connected to the internet or uunet since both of those machines tend to be one-hop away from all other hosts (or reroute accordingly). For example, if a message was addressed like so:
To: root@ucbvax.berkeley.edu, argv@zipcode.uucp Cc: ucbcad!foo!barIf auto_route is set to "ucbcad", then replies to this address are directed addressed like so:
To: ucbcad!ucbvax.berkeley.edu!root, ucbcad!zipcode.uucp!argv Cc: ucbcad!foo!bar
This assumes that the host in question talks uucp with ucbcad. This example demonstrates several things. First, notice that all addresses are converted to uucp-style format. Whenever routing is changed, the format is converted like this. Secondly, note that the Cc: line did not change. This is because all redundant hostnames from UUCP pathnames are removed to avoid unnecessary UUCP connections and speed up mail delivery.
Another example of how auto_route truncates UUCP paths:
pixar!island!sun!island!argv
Here, mail was probably originally sent to users at pixar and sun from somewhere undetermined now. Since sun and pixar do not talk to each other, the users on those machines may have responded to mail creating the type of addresses stated above. Here, it can be seen that we can reduce the path to the host island:
pixar!island!argv
See the MAIL ADDRESSES section for more detailed information about legal mail addresses.
Note that the -r flag to reply and replyall overrides the value of auto_route.
Otherwise, the variable is interpreted in one of four ways. By default, the string is interpreted as a pathname relative to the current directory. For this reason, it is advisable to use full pathnames here. As usual, the special characters `~' and `+' are expanded. If a file is found, it is opened and its contents are read into the message buffer.
If the variable is set to a string that begins with `$', then that string is interpreted as a user-definable variable and is expanded and appended to the letter.
If the variable is set to a string that begins with a backslash (\) then the string itself (minus the `\' character) is used; no expansion is done and no files are read.
Finally, if the variable is set to a string that begins with a vertical bar (or "pipe") character (|), the rest of the string is interpreted as a command whose output is used as the signature. The special characters `~' and `+' are NOT expanded in the command name, but the command is run via /bin/sh so $PATH is searched and redirection can be specified. The list of addresses to which the letter is sent is passed to the command as its arguments, in the same form that they are passed to the Mail Transport Agent (MTA). Depending on your MTA, each address may be followed by a comma.
In the latter three cases, it is advisable to set the variable using single quotes to protect the `$', `\' and `|' characters from being interpreted. Examples:
set autosign = '$foo'
set autosign = '\ Dan Heller zipcode!argv@ucbcad.berkeley.edu'
Warning: if redirection from the calling shell is used, no signature or fortune is added to outgoing mail. For example,
% mush -s report manager < report_file
In this command, mail is being sent to the user "manager" and the subject is set to "report" and the file "report_file" is being redirected as input. In this case, no signature is appended.
Note: The `|' syntax for calling a program to sign the letter is a little counterintuitive and may change in future releases.
autosign2 = "address1, address2, ... : <signature>"
Each address can be one of these types:
Example:
set autosign2 = "!zipcode @sun.com @mit.edu *schaefer root: --dan"
This means that any mail sent to 1) anyone at zipcode, 2) anyone within the sun domain, 3) anyone within the mit domain, 4) Bart Schaefer (at any host anywhere -- even locally), and 4) root on the local machine only (or, root@local-machine-name) is signed with the "alternate" signature. If any address on the recipient list fails to satisfy these four matches, the mail is signed by my regular signature.
One can have a local signature and a remote signature by specifying the autosign2 to include the hostname of the home machine the user is logged into. Note the "zipcode" example above.
The list of recipients, after alias expansion and comment removal, is then scanned and the following patterns are matched against those addresses specified in the autosign2 or fortunates variable according to these rules.
The signature description is the same as described by autosign variable. The colon (:) separates the list of addresses from the signature description. If there is no colon or the address list is missing, the entire string is considered the signature (except for the colon).
If autosign is not set, then autosign2 works ONLY if the tilde command "~S" is specified. In this way, a user may never have autosign set and just set autosign2 to be some signature value. The user may then issue the tilde command to automatically sign the letter. If a list of addresses is given (terminated by a colon), then all recipients of the message must be in the list of addresses in autosign2; otherwise, the signature in autosign (if set) is used instead. A null signature in autosign2 does not sign the letter.
Example:
set autosign2 = "fred, barney, wilma, betty: ~/flintstone.sig"
If a message is sent to:
To: fred, wilma
Then the file ~/flintstone.sig is used. However, if the address are:
To: barney, betty, bambam
Then autosign2 is not used because bambam is not in the list.
Note that mail sent via redirection from the calling shell does not sign letters or append fortunes.
The second character of the value of complete is used as the completion listing character. When this character is typed, the possible completions are printed, and Mush prompts again with the original prefix. If complete is set to only a single character, completion listing is disabled; if it is set with no value, control-D (^D) is used as the default listing character.
If the first and second characters of complete are the same character, then Mush completes unique matches as usual However, partial matches produce a listing of the possible completions before completing as far as possible. This can become rather verbose. See the description of the variable fignore for ways to exclude filenames from completions.
Word completion is currently supported only for file names. Command name and alias completion may be added in a future version. Completion is not possible if the -e (-echo) flag was given. Tool mode does not check the value of complete, but instead provides simple completion only, using the ESC key.
When sorting messages by date, this variable is queried to determine whether the messages should be sorted by date sent or date received.
Warning: For mailers that store messages without a line that starts with "From ", this option does nothing.
There must be a To: header. Without this, Mush does not deliver the letter. Instead, the editor must be reentered and a To: header with a valid recipient must be inserted. A valid Cc: header does not remove this restriction. You may have as many To: and Cc: headers as you like.
The From: header normally should not be changed. If you change this header to an address that Mush is unable to identify as authentic, the original From: header is silently put back.
The Date: header is always replaced by one with a more accurate time and date stamp. Therefore, changing or removing this header has no effect.
You cannot add a Status: header, and blank headers are dropped. For example, if an empty Cc: header exists, the header does not show up in the outgoing message. Therefore, leaving empty headers has no effect.
Aliases specified on the command line are expanded and put into the message buffer in their expanded form regardless of the value of no_expand. However, if the user changes the headers using the editor and specifies aliases, those aliases are not expanded if no_expand is set. Otherwise, they are expanded as usual.
The headers Bcc: and Fcc: are removed as expected.
One added side effect of edit_hdrs is that you can add an Fcc: header to specify a "File Carbon Copy". This must be a pathname to a file or program. For programs, the pathname must be preceded by a pipe character (|). Note that all addresses on the Fcc: line that do not begin with `|' are interpreted as file names; don't put other kinds of addresses there.
When using edit_hdrs, certain tilde escapes don't work. Specifically, any tilde escape that allows you to add or set headers or to empty the file are inactive. These functions are to be done in the editor only.
Once a letter is being edited, edit_hdrs cannot be set or unset; the user must end the letter (either by sending it or forcefully terminating it) first.
Header editing is required (and happens automatically) when using the "Compose" tool mode item.
For example,
set fignore = ".o .s [Mm]ake*"
causes any filename ending in ".o" or ".s", and any filename beginning with "Make" or "make", to be excluded from completions.
If all files in the current directory match the extensions or patterns, fignore is disabled and completion occurs. For this reason, it is usually not a good idea to include "*" in the list.
WARNING: Certain errors are ignored during this update, because it is presumed to be impossible to query the user for instructions. Except in the event of a write error, the folder is forced to contain exactly those messages that were not deleted at the time of the hangup. In particular, this means that if an error occurs when loading new mail before the update, the new mail is lost. Write errors still cause both the working tempfile and as much of the folder as possible to be preserved.
%a address of the author %c number of characters (bytes) in the message %f entire "From:" field (author) %l number of lines in the message %i the message-id (may not be present) %n name of the author %s subject of the message %t "To:" field (recipients) %u user name (login) of the author %d date and time of the message %T time only of the message %N day number of the month of the message %W day of the week (Sun, Mon, etc.) %M month name of the message %Y year of the message %y last two digits of %Y %Z time zone of the message \n a newline \t a tab
A field width specifier may be used in all options. Thus, "%20f" prints the first 20 characters of the from line. No matter what the formatting string, the message number is printed, possibly preceded by a `>' (for current message).
The "address" and "name" of the author are extracted from the "From:" field of the message. The name may be given in parentheses and the rest of the line is the address, or the address is given in angle brackets (`<' and `>') and the rest of the line is the name. Sometimes the address is the only thing on the line, in which case the name and address are the same.
A special format is also provided to obtain the contents of any header not listed above. If a format of the form "%?header-name?" (both leading and following `?' characters are required) appears in the value of hdr_format, the named header is looked up. For example,
set hdr_format = "%a %n %?phone?"
causes the electronic address, name, and (if a "Phone:" header is present) phone number of the sender to be displayed.
Note: the user should not have to set this variable since it should be set automatically by the system. However, it may happen that the system's hostname cannot be queried and the user may have to set this variable manually.
For example, if the user responds to a message from Dan Heller that was sent on October 21, 1987, at 10:39pm, with in_reply_to set to the string
%n's message as of %d.
the header line In-Reply-To: Dan Heller's message as of Oct 21, 1987, 10:39pm.
is added to the message.
For example, if you respond to mail that contains the path
unicom!pixar!root
but your know your machine already calls pixar, then sending the mail to unicom first is unnecessary. If you have set your known_hosts string to include pixar in its list, the resulting address looks like
pixar!root
Also see the command replyall for more information on constructing correct return addresses.
If set, but not to a string, the log file defaults to ~/mail.log.
The program specified by metamail is invoked in tool mode as well, instead of paging the message in the message subwindow. This program is therefore expected to be able to determine for itself (e.g., via the mailcap configuration file) that SunView is running, and to create appropriate windows as needed.
set pre_indent_str = '[In the message entitled "%s", on %7d\n %n writes:]'
You can then include a message body using "~i", and you might get something like this:
[In the message entitled "This is a test.", on Jan 19, Dan Heller writes:] > This is a test message to show how > pre_indent_str might be used.This example assumes that the string value of indent_str is not set.
set pre_indent_str = "/*" set indent_str = " * " set post_indent_str = " */"
An included message might look something like this: /* * This is a test message to show how * post_indent_str and pre_indent_str * can work together with indent_str. */
set print_cmd = 'ptroff -ms -Plp'
lpr .-$
This command sends all messages from the current message to the last message through the ptroff command, supplying the appropriate arguments.
"Msg %m of %t: "
If you have 10 messages and your current message is 5, then your prompt looks like:
Msg 5 of 10:
The string value that prompt is set to is printed as your prompt. If the string contains a `%', then that character is ignored, the next character is evaluated and an appropriate value is printed in its place:
%F full path name of the current folder %f name of the current folder (tail of %F) %m "current message" number %t total number of messages %n number of "new" messages %u number of unread messages %d number of deleted messages %T current time (hours and seconds) %N today's date (Number of the day in the month) %W weekday name (Sun, Mon, Tue, ...) %M current month %Y this year %y last two digits of %Y \n a newline \t a tab
To include the values of variables in the prompt string, the format "%$variable" can be used, where variable is the name of any variable. If the `$' character is not preceded by a `%', it is included literally, rather than introducing a variable name. Thus, two equivalent ways of including the name of the current folder in your prompt are:
set prompt = '%F> ' set prompt = '%$thisfolder> '
Note the use of single quotes to prevent the value of thisfolder from being expanded at the time the prompt is set. The only difference between these settings is that "%F" adds the string "[read-only]" if the folder was loaded in read-only mode.
autosign Suppress messages when appending signature. await Suppress await's bell for new mail. complete Suppress word completion error bells. fkey Suppress warnings about unset function keys. fortune Suppress messages when appending fortune. iconlabel Suppress showing message count as icon label. newmail Suppress new mail notification messages. pick Suppress descriptions of pick searches. startup Suppress the startup message. tool Suppress tool mode bell for new mail.
Error conditions for signatures and fortunes are still reported. See the variables autosign, complete, and fortune for more details. The newmail setting does not prevent automatic inclusion of new mail, it only suppresses the announcement of its arrival, including tool mode bells. The fkey setting applies only to tool mode.
set realname = "Your name here"
set reply_to_hdr = "sender reply-to return-path from_"
This example shows that Mush searches (in order) the headers listed in the reply_to_hdr variable. If one header isn't found, then Mush looks for the next in the list. If none of the headers in the list are found, the default headers (mentioned above) are searched. The last header listed in the example is the special "From " header. Also see the reply command.
set show_hdrs = "from date subject to cc"
only displays the headers From: Date: Subject: To: Cc: in their entirety.
Due to the lack of real job control, input/output redirection and UNIX command piping, this mode of Mush is not intended to be used as a login shell.
If a Mush command name conflicts with a UNIX command, use the command sh to force execution as a shell command or use the full pathname of the command (e.g. starting with a '/').
Warning: Be aware that Mush pipes transmit message lists, NOT TEXT. You cannot pipe the output of UNIX commands to or from Mush commands or other UNIX commands with the Mush pipe mechanism. You can, however, pipe Mush commands to a final UNIX command (see the pipe command for more information). UNIX commands should be simple commands without pipes or metacharacters.
This feature is not available for the tool mode.
mail Confirm sending of mail (as above). save Confirm save-item selections (tool only).
Appending of messages to files that are not folders is verified regardless of the setting of this variable.
The intent is so that users who are used to their own environments become aware of changes in other environments should they be forced to use them. There may also be warning messages of failed routines or assertions that are not fatal enough to interrupt normal running of the program.
Line wrapping occurs only at whitespace (spaces or tabs). Lines containing no whitespace to the left of the specified column are not wrapped. If Mush was started with the -e (echo mode) option, or is in tool mode, line wrapping cannot be done due to I/O incompatibilities.
In addition to the named variables described above, three special variable forms are recognized.
save $[%4n]:l
saves the current message in a file whose name is the first four characters of the name of the author, converted to lower case.
echo $(%T)
prints the current time. Note that "$(%F)" is equivalent to "$thisfolder".
NOTE: Evaluation of many "$[%...]" or "$(%...)" values in a single command is inefficient. If expansion of several formats is desired, it is better to use the -h and -p options of echo or eval, which also provide better quoting of the interpolated strings.
For example, a filtering file, "filter", might contain:
set newfolder = /usr/spool/mail/$USER if is_shell if -z $newfolder
set newfolder = $mbox# mbox must be set! endif if -e $newfolder
folder $newfolder else
quit endif endif pick -f Mailer-Daemon | save mail_errors pick -f yukko | delete pick -s -i thesis | save +thesis_mail pick -t unix-wizards | +wizmail update sort d
Then the first command the user types when beginning a Mush session might be "source filter", and the following happens:
First, a new variable called newfolder is set to the user's spool mailbox (the system mailbox). A test is made to see if the shell is running, because the folder command can only be used from the shell. Then a test is done to see if the spool mailbox is zero length, and if it is, the variable is reset to the value of the user's mbox variable (mbox must already be set by this time or this fails). A final test assures that the new folder exists. If it does, Mush changes folders to the new folder. If it doesn't exist, the program exits (via quit).
Once the correct folder has been loaded, all messages that have "Mailer-Daemon" in the From header are saved in the file mail_errors. Then, all mail from the user "yukko" is simply deleted. Next, all mail that has in the Subject field, "thesis" (case ignored, so "Thesis" would also match) are saved in the file $folder/thesis. The next command finds all messages that are addressed to the group "unix-wizards" (of which the user is an elite member) and saves them in the file $folder/wizmail. Last, the folder is updated, removing all deleted mail (saved mail may be marked as deleted) and the folder is reread and sorted according to the date of the messages.
If the "#!" mechanism is supported, the "filter" script can be made into a program by adding as the first line:
#! /usr/local/bin/mush -F
(The actual location of mush may vary from system to system; /usr/local/bin is used as an example.) Then make the file executable:
chmod +x filter
Now, when the command "filter" is typed at the user's regular shell prompt, the mush program is invoked by the operating system. Mush first reads the commands from the "filter" file and performs them, exactly as described above, and then continues into the usual interface. If it is preferable for mush to exit after reading the script, the first line can be changed to:
#! /usr/local/bin/mush -F!
The -F! option should also be used when running scripts in the background or in other circumstances where the standard input cannot be a terminal, and the only commands to be executed are those in the script itself.
Note that any additional arguments passed to a "#!" script are interpreted by mush; they are not passed along in any way that makes them accessible to the script. Thus,
% filter -f mbox
applies the commands in the "filter" script to the "mbox" folder.
In general, macros consist of two parts: a key sequence and an expansion. The key sequence is the character or string of characters which, when typed in the appropriate mode, is recognized by Mush as a reference to a macro. The expansion part of a macro is the string that is actually "seen" by Mush when the key sequence is recognized. Macros are like an interactive search-and-replace function; if a key sequence appears in the input, the associated expansion is substituted in its place. Thus, if you create a macro whose key sequence is "^X^W" (control-X control-W) and whose expansion is "save", then when you hold down the control key and type the two characters `x' and `w', the effect is as if you had actually typed the four characters `s', `a', `v' and `e'. This is called "expanding" the macro. More detailed examples of macros are presented in the subsections for each mode in which macros can be used.
Key sequences are usually made up of control characters or special strings of characters generated by "function keys," but may in fact be almost any string the user desires. Keys that generate a signal or an end-of-file from the keyboard (for example, on BSD systems, control-Z generates a TSTP signal and control-D generates an end-of-file) can never appear in key sequences, and macros in line or composition modes cannot begin with a newline, control-D, or any of the editing keys (erase, word-erase, line-erase, etc.). Otherwise, there are no restrictions. It should be kept in mind, however, that for the line and composition modes, key sequences should be unusual characters or combinations of characters, not individual lower-case letters. If common characters or strings are used for key sequences, much confusion can result when typing commands or messages. This is not important in the curses mode.
In the line and composition modes, a timeout is used for key recognition; that is, once the first character of the key sequence has been typed, the succeeding characters must be typed after it relatively quickly, or Mush fails to recognize them as a continuous sequence. It is for this reason that key sequences are usually either very short, or are strings that are automatically generated by pressing a special key on the terminal. On the other hand, the timeout can be used intentionally to prevent a macro from being expanded; simply type the first character of the macro, then wait for it to echo before typing the next. This does not work in curses mode, because curses macros never "time out."
In any mode, macros are recursive; that is, if the key sequence of one macro appears in the expansion of another macro (or even of the same macro), the second key sequence is recognized when the first macro is expanded, and this new key sequence is also expanded. Great care should be taken when creating macros to be certain that recursive expansions do not happen unintentionally. Expansion can be prevented in line or composition modes by using a literal-next character.
Literal-next characters may be used from the keyboard or embedded in expansions. In either case, they prevent the next character from being interpreted as part of a key sequence. Mush recognizes the literal-next character from the tty settings of the terminal, if the "new" BSD-style device driver is available; otherwise, `^V' (control-V) is recognized as a literal-next. Note that, if you have a tty literal-next character, then when typing you need to type two of them in order to send one to Mush; this is because the tty driver consumes the first one. It is not necessary to use two literal-nexts in macro expansions unless you wish to cause the second literal-next to be literal.
Backslash can be used as a literal-next when typing, and can sometimes be used as a literal-next in expansions; but use it with caution, because it also introduces escape sequences (see "Macro syntax," below). There is no literal-next mechanism for curses mode.
A macro always aborts whenever any command called by the macro returns an error. This includes recursive expansions, so no matter how often a macro has recurred, it is terminated completely. Errors in curses mode include illegal cursor movements, such as up from the top of the screen or down from the last message.
Macro syntax.
A special syntax is provided for specifying control characters and other non-printing characters in macro key sequences and expansions. This syntax is the same as that for bindings, discussed in the CURSES INTERFACE section; it can be summarized as:
\CX control-X (where X is any capital letter) \E the escape character \n a newline (other C-style escapes also work)
Thus, to create a line mode macro for control-X control-W, as in the example above, the command is
map '\CX\CW' save
Also provided is a syntax for executing functions from within macros. There are two special functions that are effective in all modes; these are getstr and getline. Both of these functions interrupt expansion of the current macro, and wait for a newline-terminated string to be entered from the standard input. This input string is inserted into the macro expansion. The functions differ in that getline retains the newline character (carriage-return) at the end of the input string, whereas getstr strips off the newline (one must still be typed to terminate input). These functions can be executed by surrounding their name with square brackets ([, ]); for example,
map '\CX\CW' save [getline]
creates a line mode macro, which is expanded when control-X control-W is typed, and which displays "save" followed by a space and then waits for the user to type a line of input; the input line is used as the arguments to the save command.
Additional functions are currently available only in the curses mode. However, the syntax of enclosing the function name in square brackets applies to all functions, regardless of mode. Note that ONLY the function name can appear in the brackets; no whitespace is allowed.
Curses mode macros.
Macros in curses mode are the most versatile, because they can access the full range of curses commands quickly and easily. Every character that appears in the expansion part of a curses mode macro can reference a curses command or another macro. Like other curses functions, curses mode macros are created with the bind command. For example, to sort your messages by date and then send the most recent one to the printer, you could use
bind @ macro 'od$|'
When the `@' key is typed, this macro first invokes sort (`o' from the default bindings) and instructs it to use date (d) for sorting; it then moves the current-message pointer to the last message ($) and prints that message (|).
Admittedly, the above macro is somewhat cryptic, and is dependent upon the bindings for sort, last-msg, and lpr being set to the defaults. It is better, and possibly more understandable, to refer to the desired curses functions without using their key bindings. To allow this, the "[function]" syntax described above may be used in curses mode macros to reference curses functions. The only function that is prohibited from appearing in the "[]" is the special macro function, which cannot be called when it has no binding. The example macro can therefore be rewritten as
bind @ macro [sort]d[last-msg][lpr]
Such references to curses functions may be made only in curses mode macros, and are effective only when Mush is actually in curses mode. That may sound strange, but the most common use of curses macros is to quickly perform functions that require an escape to the line mode. For example, although there is a variation of the curses mode mail function that prompts for additional flags, there is no function to prompt for flags to be passed to reply. A macro can easily be created to provide this:
bind R macro '[line-mode]reply '
This macro binds `R' to perform an escape to line mode and type the string "reply" followed by a space. Macro expansion then ends, leaving it up to the user to supply flags to the command or to backspace over it if a different command (or none) is desired. Of course, the macro could also have provided some default arguments:
bind R macro '[line-mode]reply -ei '
Note that, if the getline or getstr function is used in a line-mode escape, it is not possible to erase the text that is typed before the get; that is, if the macro is
bind R macro '[line-mode]reply -ei [getline]'
then the user is forced to use the -ei flags.
Line mode macros.
Line mode macros combine some of the convenience of single-keystroke commands with the versatility of the line-oriented text interface. As has been noted, the choice of characters for line mode key sequences should be made carefully, so as not to interfere with normal typing. Line mode macros are created with the map command; for example, suppose you frequently forward messages to a friend named "fred." You could create a macro to do this:
map '\CF' 'mail -f . fred\n'
This macro causes the single keystroke `^F' (control-F) to forward the current message to "fred." Note the newline character "\n" at the end of the expansion; this causes the command to be executed immediately, without you having to type a carriage-return.
The expansion part of a line mode macro echoes to the screen when it is expanded, so you can see what the macro is doing. You can therefore use parts of the expansion as a "prompt." In the above example, suppose you wished to enter a message list rather than always forwarding the current message. Change the macro to:
map '\CF' 'mail -f [getstr] fred\n'
This version of the macro prints "mail -f" and a space, then waits for a newline-terminated string from the standard input. The newline is stripped, and the string is used as the message list passed to the "mail -f" command. The address "fred" is also passed to mail, so the messages in the list are forwarded to fred.
If you want to be able to "change your mind" after starting a line mode macro, you must leave the "\n" out of the expansion. Without the newline, the macro is not executed immediately, so you have a chance erase the line (or part of it) and type something different. Remember that the getline function keeps the newline in the string it gets, so if you don't want a newline to appear, you must use getstr. When using the get functions, you should also remember that you can never backspace past the "beginning" of a getline, and you can backspace past the beginning of a getstr only after the get has been completed.
When the getstr function is used in line mode macros, Mush reprints the current input line so you can see what the whole thing looks like, but does not redisplay the line mode prompt (see the entry for prompt in the VARIABLES section for information on what the prompt looks like). Don't let this worry you. The input line is also reprinted when getline is used, but the newline in the input string usually results in a new prompt being displayed.
NOTE: Line mode macros are not available when using the line-mode escape function in curses mode. It is necessary to escape all the way to line mode (that is, leave curses mode by typing carriage-return at the `:' prompt) in order to access line mode macros. This is to prevent possible confusion when similar macros exist in both line and curses modes.
Composition mode macros.
Composition mode macros are very similar to line mode macros, and provide a "power typing" function when composing messages. For example, you might want to have the word "percent" inserted into your message whenever you hit the `%' key:
map! % percent
Another use is to simulate the indentation features of editors. For example, you might
map! '\CT' ' '
(where the expansion is four spaces, enclosed in single quotes). This macro causes four spaces to be inserted into the message whenever control-T is typed.
Composition mode macros can also be used to execute tilde-escapes (see the GENERAL USAGE section for a list of these). For example, you could create a macro to invoke the editor:
map! '\CE' '\n~v\n'
When control-E is typed, this macro prints a newline (to be sure that the tilde-escape is the first thing on a line), then types "~v" followed by another newline, to start the editor. Similar macros can be created for other tilde-escapes.
Mixed mode macros.
It is not normally possible to mix macros among the different modes. However, once expansion has begun, it is interrupted only by an error or by the appearance of one of the special get functions. It is therefore possible to have a macro expansion which causes the mode to change before the expansion has completed. In this case, recursive expansions apply to the new mode. Suppose we are using a variation of the editor-starting macro shown above for composition mode:
map! '\CE' '\n~v emacs\n'
This macro causes the "emacs" editor to be started when control-E is typed in composition mode. We can now create a line mode macro that makes use of this composition mode macro:
map '#' 'reply -i [getline]~t[getline]\CE'
When the `#' key is pressed in line mode, this macro prints "reply -i" and waits for a message list, then enters composition mode (by executing the reply command). In composition mode, it displays the To: line (the "~t" escape) and waits for other addresses to be added. Finally, it recursively expands the control-E macro, to start editing the message with emacs.
As can be seen from this example, the Mush macro facility is very powerful. Be very careful not to accidentally expand recursive macros, especially when using macros that change modes. When testing new macros, it is a good idea to start Mush in read-only mode (the -r command line flag) to be sure that messages are not lost or altered.
Getting rid of macros.
It is not necessary to delete a macro in order to redefine it. New expansions for existing key sequences automatically replace the old expansions. If it is necessary to remove a macro completely, the commands unbind, unmap and unmap! can be used to remove curses mode, line mode, and composition mode macros, respectively. Remember to use a backslash or other literal-next character to prevent the expansion of line mode macros when using these commands, especially unmap.
mail fred barney wilma betty
In these cases, Mush can figure out that they are separate addresses and insert commas between addresses automatically.
To: fred, barney, wilma, betty
Addresses may also contain `!', `@' and `%' characters which are used to separate hostnames and the final user name from each other. This is primarily used to mail to users on other machines. UUCP addresses are specified as
host1!host2!user
where there may be as many hosts as necessary to route the message to the recipient user. Here, the user's account is on "host2" and that machine is connected to "host1". Domain addresses (also called Arpanet, Internet, RFC822, and "fully qualified" addresses) are specified as
user@host.domain
user%host2.domain@host1
where "domain" is a domain name such as ".berkeley.edu" or ".com". As in the first example, the user is on "host2", but that machine talks to "host1". It is beyond the scope of this document to discuss in detail the ramifications of inter-network mailing. More information can be obtained through your system manager.
Mush understands addresses containing a comment field. Comment fields do not affect the destination address of mail being sent. These fields are purely for human legibility and may be specified according to the following constraints:
Anything within angle brackets is an address; whatever is outside of the address is considered a comment:
Dan Heller <zipcode!argv@cad.berkeley.edu>
Dan Heller <argv@zipcode.com>
Anything that has parentheses is a comment; whatever is outside of the parentheses is considered the address:
zipcode!argv (Dan Heller)
argv@zipcode.com (Dan Heller)
Double quotes (") are treated just like parentheses:
"Dan Heller" zipcode!argv
"Dan Heller" argv@zipcode.com
If the comment is to contain a comma, the first case above may not be used; you must use either the parenthesis or double-quote cases.
fred@flintstone.bed.rock (Fred Flintstone, Cave Man)
If the comment contains unbalanced quotes, unpredictable results may occur (Mush won't deliver the mail).
Since the angle brackets have the highest precedence, quotes or parentheses may be used in conjunction with one another.
Yabba Dabba Doo (Fred Flintstone) <fred>
Scoobie "Doobie" Doo <scooby@shaggys.mystery.machine>
Multiple addresses may appear on a line:
argv@zipcode.com argv@garp.mit.edu dheller
Because there is no indication of comments (parenthesis, angle bracket, or quotes), it is assumed that these are separate addresses and Mush inserts commas between these addresses accordingly. It is for this reason that the user is encouraged to explicitly insert commas between all mail addresses and not depend on the automation of comma insertion to correctly separate addresses from one another.
Mail aliases may contain addresses of the form described above.
alias george George Jetson <george@spacely.space.sprockets> alias jane Jane Jetson <jane@sky-high.appts> alias group george, jane
You can mail using the alias as an address and it is expanded accordingly. You cannot, however, reference an alias and specify a comment or another address at the same time.
To: The Jetsons <group>
The comment "The Jetsons" is not retained when the alias "group" is expanded, because the entire address and comment are replaced by the expansion.
/usr/spool/mail/* Directory for incoming mail ~/Mail Default folder directory ~/mbox File where old mail is saved ~/.mushrc File giving initial Mush commands ~/.mailrc Alternate initialization file ~/.edXXXXXXX Temporary for file for outgoing messages ~/.mushXXXXXX Temporary mail file (copy of current folder)
Temporary files that are created by the program, and folders written with save and related commands, are always created with read/write access to the owner only; group and other permissions are never set. This is also true for the /usr/spool/mail/* files. All other files created by the user via commands internal or external to the program have permissions set by the user's default umask. If the umask is reset within the program, the mask remains intact even after exiting. Remember to set the variable unix before attempting to set the umask value.
If your system is using Sun Microsystem's NFS, take special note to read the manual page for mount(1). Filesystems mounted for read/write access should be mounted as "hard" NFS mounts or you may lose mailboxes during a timeout during a write or update.
Filesystems that use RFS still have bugs to be ironed out in the way of owners and permissions concerning utime(2).
argv@sun.com zipcode!argv
UNIX is a trademark of AT&T.
The Flintstones and The Jetsons are trademarks of Hannah-Barbara Inc.
Toggling from the curses mode to the line mode to get the full functionality of the shell/line mode is unfortunately necessary in order to maintain the display in a sensible manner and to keep the keystroke-command interface simple and "user friendly". Mostly, such escapes are only necessary for piping of commands and using the pick command. Macros are a big help with this.
If the program is already running and the system [later] has to swap and there is no swap space left, there may be problems. One such problem is sending mail. If this happens, then sending mail fails and a segmentation fault from the spawned/forked child may occur (unless the -v flag was given to mail). The unsent letter is not removed from the editing file ($home/.edXXXXXX) and may be recovered.
Many functions available to the line oriented mode (shell mode) are not available to the tool mode. For example, pick may not be directly accessed although experienced users may find that typing pick commands within single backquotes in the "Range:" panel item above the header window and then selecting a command that uses the range does indeed pick messages. This is mostly for selecting the "delete range" item or the middle mouse button icon in the header panel.
Version 6.5.6 was the last version designed to run under SunWindows, and is therefore the most recent version that functioned under SunOS 2.x. Starting with versions 7.x, the interface used is SunView, and may have a completely new set of problems in addition to those described below. Also, some of those described below may have been eliminated, and remain in this discussion only for completeness.
Shell escapes (of any kind) may be called only from the "pipe" command in the tool mode, should not be interactive, and should produce output only to a file. The reason for this is that there is no tty window in which to do input/output. Since the interactive function-key binding interface has gone away, it is unfortunately only possible to execute commands that have been pre-defined in the initialization file. Future revisions may correct these deficiencies.
The function keys and their ability to work has been variable depending on the version of SunWindows/SunView your Sun Workstation has. From time to time, it works, but when it doesn't, it seems to be related to other user or system definable dot-files or whatever.
Changing the value of the screen_win, crt_win, or msg_win variables after the tool is running simply has no effect.
When using vi in the tool mode, the window is periodically one or more lines "short." That is, scrolling is off by one line and you have to redraw the window (using "z." in vi) to get it in sync again. The problem is caused by the window having less than 24 lines in the window. Having the tty subwindow be exactly 24 lines usually eliminates the problem. This is a bug with SunView and will not be fixed since Sun no longer supports it.
When running on full filesystems, Mush may complain or not even run since it needs temporary space with which to work. Instead of finding new filesystems on its own, Mush leaves this task up to the user. The workaround is to set the variable tmpdir in the initialization file to be a writable place in a filesystem that has enough disk space. Note: some systems' setcwd() system call writes temporary information in /tmp and this cannot be overridden. You may get error messages such as "file system full" even if your tmpdir variable is set to a directory in a partition other than that of /tmp. There is nothing to be concerned about; chance are that you changed directories and the setcwd() system call can't write to its temp file.
Repeated sequences of creating and destroying compose frames uses up file descriptors in Sun OS 3.5, due to a bug where a destroyed ttysw does not free up its fd's.
Most of the other known and documented bugs are in the supplied README files accompanying the source. The source is also an excellent place to look as many known bugs are documented in comments. A good way to track suspicious bugs is to use the debug command, but note that this command is very difficult to use in curses mode.