Thanks to Dan Harkless for feedback on how to get this stuff in. Among
other things, he wrote:
> Nothing special. Just let the list know. As for your attachment changes,
> why not just post your diffs (using -c, of course, and vs. the latest CVS
> source if possible) to the list and ask if someone with write access would
> commit them? Doing it this way makes it easier for multiple people on the
> list to audit your changes.
>
> Also, hopefully your diffs include documentation updates.
And, of course, they do. There are even comments in the code, which seems
to go against the nmh grain! Below is the documentation. I'll wait a few
days for feedback on the documentation before posting the diffs in case
anyone suggests changes.
NAME
whatnow - prompting front-end for sending messages
SYNOPSIS
whatnow [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder] [-editor editor] [-noedit]
[-prompt string] [file] [-version] [-help]
DESCRIPTION
Whatnow is the default program that queries the user about
the disposition of a composed draft. It is normally
automatically invoked by one of the nmh commands comp, dist,
forw, or repl after the initial edit.
When started, the editor is started on the draft (unless
`-noedit' is given, in which case the initial edit is
suppressed). Then, whatnow repetitively prompts the user
with "What now?" and awaits a response. The valid
responses are:
edit re-edit using the same editor that was used on the
preceding round unless a profile entry
"<lasteditor>-next: <editor>" names an alternate editor
edit <editor> invoke <editor> for further editing
refile +folder refile the draft into the given folder
mime process the draft as MIME composition file using
the "buildmimeproc" command (mhbuild by default)
display list the message being distributed/replied-to
on the terminal
list list the draft on the terminal
send send the message
send -watch send the message and monitor the delivery process
push send the message in the background
whom list the addresses that the message will go to
whom -check list the addresses and verify that they are
acceptable to the transport service
quit preserve the draft and exit
quit -delete delete the draft and exit
delete delete the draft and exit
cd [dir] change directory from which attachments are read
pwd print director from which attachments are read
ls [ls-options] list files in attachment directory
attach files attach files to draft
When entering your response, you need only type enough char-
acters to uniquely identify the response.
The attach response can be used to attach files to the
draft. It does this by appending a line to the draft for
each file in the mhbuild(1) MIME composition file format.
It is recommended that you set automimeproc in your profile
so that the composition file is automatically converted to
MIME format when you send. The file names are expanded
using your shell as defined by the $SHELL environment vari-
able, so metacharacters and other syntactical sugar is
available.
The cd response changes the attachment directory and can be
used to eliminate the need for entering long file names for
attachments. The pwd response outputs the current attach-
ment directory. The ls response can be used to list files
in the attachment directory; all of the normal ls(1) options
are available. As with the attach response, all file names
are expanded using your shell.
For the edit response, any valid switch to the editor is
valid.
For the send and push responses, any valid switch to
send (1) are valid (as push merely invokes send with the
`-push' option).
For the whom response, any valid switch to whom (1) is
valid.
For the refile response, any valid switch to the fileproc is
valid.
For the display and list responses, any valid argument to
the lproc is valid. If any non-switch arguments are
present, then the pathname of the draft will be excluded
from the argument list given to the lproc (this is useful
for listing another nmh message).
See mh-profile (5) for further information about how editors
are used by nmh. It also discusses how environment vari-
ables can be used to direct whatnow's actions in complex
ways.
The `-prompt string' switch sets the prompting string for
whatnow.
The `-draftfolder +folder' and `-draftmessage msg' switches
invoke the nmh draft folder facility. This is an advanced
(and highly useful) feature. Consult the mh-draft(5) man
page for more information.
FILES
$HOME/.mh_profile The user profile
<mh-dir>/draft The draft file
PROFILE COMPONENTS
Path: To determine the user's nmh directory
Draft-Folder: To find the default draft-folder
Editor: To override the default editor
<lasteditor>-next: To name an editor to be used after exit
from <lasteditor>
attachproc: Program to attach files to the draft
automimeproc: If value is 1, and the draft is a MIME
composition file, then automatically call
buildmimeproc prior to sending.
buildmimeproc: Program to translate MIME composition files
fileproc: Program to refile the message
lproc: Program to list the contents of a message
mhshow-suffix-*: Mappings of file suffixes into MIME content types
sendproc: Program to use to send the message
whomproc: Program to determine who a message would go to
SEE ALSO
ls(1), mhattach(1), mhshow(1), send(1), whom(1)
DEFAULTS
`-prompt "What Now? "'
CONTEXT
None
BUGS
The argument to the `-prompt' switch must be interpreted as
a single token by the shell that invokes whatnow. There-
fore, one must usually place the argument to this switch
inside double-quotes.
If the initial edit fails, whatnow deletes your draft (by
renaming it with a leading comma); failure of a later edit
preserves the draft.
If the buildmimeproc fails (returns a nonzero status), what-
now simply prints a "What now?" prompt. whatnow depends on
the buildmimeproc to tell the user that something went
wrong.
If whatnowproc is whatnow, then comp, dist, forw, and repl
use a built-in whatnow, and do not actually run the whatnow
program. Hence, if you define your own whatnowproc, don't
call it whatnow since it won't be run.
If sendproc is send, then whatnow uses a built-in send, it
does not actually run the send program. Hence, if you
define your own sendproc, don't call it send since whatnow
won't run it.
NAME
mhattach - add attachments to a draft
SYNOPSIS
mhattach [-help] [-draftfolder +folder] [-draftmessage msg]
[-nodraftfolder] [-type content-type] [-notype] file
...
DESCRIPTION
The mhattach command adds attachments to a draft. It is
usually invoked via the whatnow prompter.
Mhattach normally operates on the default draft; this can be
changed using the `-draftmessage', `-draftfolder', and
`-nodraftfolder' options. See mh-draft(5) for more informa-
tion.
Mhattach will not create a draft; it must already exist.
Mhattach does not actually add attachments to a draft.
Instead, it appends a directive in mhbuild(1) MIME composi-
tion file format to the draft for each attachment.
Mhbuild(1) must be invoked prior to sending in order to con-
vert the composition file into a MIME message with attach-
ments. This is typically done in whatnow(1).
The content-type for attachments can be specified on the
command line using the `-type' option. A type specification
applies to all subsequent files unless overridden with
another `-type' option. The `-notype' option sets the
content-type for all subsequent files to undefined unless
overridden with a `-type' option.
Mhattach automatically determines the content-type for any
attachment that did not have the type specified on the com-
mand line. This is the usual mode of operation.
Mhattach searches the context for mhshow-suffix- entries.
These entries map filename suffixes to content-types. See
mhshow(1) for details. The associated content-type is used
if a matching suffix is found. If no matching suffix is
found, the file is scanned to determine whether it contains
non-ASCII characters. The text/plain content-type is used
for ASCII files, otherwise the application/octet-stream
content-type is used.
Three additional pieces of information are included in the
directive for each attachment: the last path component of
the file name as a name attribute, the file permissions as a
x-unix-mode attribute, and a description of the file con-
tents, as obtained using the file(1) command. mhbuild(1)
converts the latter into a content-description.
The full path name of each attachment file is used in the
MIME composition file directives. This allows mhbuild(1) to
work even if the current directory changes between invoca-
tions of mhattach(1) and mhbuild(1).
FILES
$HOME/.mh_profile The user profile
<mh-dir>/draft The draft file
PROFILE COMPONENTS
Path: To determine the user's nmh directory
Draft-Folder: To find the default draft-folder
mhshow-suffix-*: Mappings of file suffixes into MIME content types
SEE ALSO
file(1), mhbuild(1), mhshow(1), whatnow(1)
[nmh-1.0.4+dev] Last change: MH.6.8 2
