Hi Norm,
Copying back in nmh-workers@nongnu.org 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.