Re: Problem with mhmail

[Ralph Corderoy]

Hi Norm,

Copying back in address@hidden because it's of wider interest.

> > I think you want just
> > 
> >     send $draft
> > 
> > there because send wants a path, not a message number.
>
> The use of the word, "file", in the documentation would certainly
> imply that.  But, in fact, send wants message numbers.

That confused me so I dug further.

send(1) says ‘file ...’ in the Synopsis but doesn't explain that the
-draftfolder option changes the meaning of those file arguments to
messages.

So ‘send foo’ wants a file called foo to exist in ‘mhpath path’.

    $ send foo
    send: unable to stat draft file /home/ralph/mail/foo: No such file or 
directory

An absolute path is used absolutely.

    $ send /tmp/foo
    send: unable to stat draft file /tmp/foo: No such file or directory

A relative path still has ‘mhpath path’ prepended.

    $ send tmp/foo
    send: unable to stat draft file /home/ralph/mail/tmp/foo: No such file or 
directory

A filename that happens to be a number doesn't affect this behaviour.

    $ send 42
    send: unable to stat draft file /home/ralph/mail/42: No such file or 
directory

It's using -draftfolder that changes the arguments from files to message
numbers.

    $ send -draftfolder drafts 314
    send: message 314 doesn't exist
    $ send -draftfolder drafts last
    $

That's despite my .mh_profile stating a general draft folder.

    $ mhparam draft-folder
    drafts

send(1) doesn't explain this.  It makes a reference to mh-draft(5), but
it isn't obvious to read that for this behaviour of send.  By its name
and section, mh-draft(5) should only be describing the file format of
draft emails; something needed by Arthur recently when confused about
comp(1)'s -to description.

    The -draftfolder +folder and -draftmessage msg switches invoke the
    nmh draft folder facility.  This is an advanced (and highly useful)
    feature.  Consult mh-draft(5) for more information.

Thus if your script works with specifying a message number then it
suggests your .mh_profile has ‘send: -draftfolder’ or similar.

By my reading of the documentation, this should break ‘send’ at the
whatnow(1) prompt because that will pass a filename but it will attempt
to be interpreted as a message.  That it works is probably because
whatnow spots the command is send and calls a function to implement it
rather than forking and execing the read send.  I think this is another
wrong approach.  Perhaps useful when a fork/exec in response to an
interactive request was costly, but not now when it only allows for
confusion due to varying behaviour behind the scenes.

-- 
Cheers, Ralph.