[Nmh-workers] whatnow(1)'s cd Doesn't Affect it's mime.

[Ralph Corderoy]

Hi,

I tend not to use whatnow(1)'s new `attach', etc., preferring to specify
more precisely a content-description, etc., as an mhbuild directive and
asking whatnow to `mime'.  Today, I started comp a directory too high.

    $ mkdir foo
    $ date >foo/bar
    $ comp -ed ed
    227
    /^MIME/;+2d
    $a
    #text/plain bar
    .
    wq
    153

    What now? mime
    mhbuild: unable to access bar for reading: No such file or directory

    What now? cd foo

    What now? ls
    bar

    What now? mime
    mhbuild: unable to access bar for reading: No such file or directory

It's very unintuitive, well, wrong, that a `cd' command at a command's
prompt doesn't change the current working directory as far as all other
commands are concerned.  That's not how other Unix commands that provide
cd work.  If it can't be fixed then whatnow(1) could do with pointing it
out.

Being able to do `cd' and `ls' at an nmh prompt, when MH's raison d'être
is to intermingle its commands with the shell's, always seemed wrong.  I
understand a simple way of attaching files was sought, but this isn't
very "nmh".  anno(1) to add the Attach header, and an mhbuild that
replaces the original on success would provide more the mechanism
letting the user choose the policy.

Anyway, whilst I'm here, grumbling,

    $ comp -ed false
    whatnow: problems with edit--draft left in /home/ralph/mail/drafts/,42
    $

Why isn't the draft left as 42?  I don't see why it should be removed
(not by rmmproc) if the editor complains.  That's ripe to be trampled
instead of a future different draft taking 43.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy