Re: [Nmh-workers] whatnow: can't attach because no header field name was given.

[Jon Steinhart]

Ken Hornstein writes:
> >Is the attach command of whatnow making no attempt whatsoever to try
> >to determine the correct MIME content type specification?  Is every
> >attachment just going to be sent as "application/octet-stream"?
> 
> Dude, you make it seem like using application/octet-stream is an
> injustice on par with the imprisonment of Alfred Dreyfus or an
> Acadmey Award being given to Marisa Tomei.  I don't think it's
> unreasonable to use if nmh doesn't know how to handle a content
> type.
> 
> The send(1) man page explains how nmh can be configured to map
> particular suffixes to MIME content types when using atttach (although
> it's brief and probably should contain a reference to the mhshow(1)
> man page for the exact syntax).
> 
> Should nmh have some better defaults?  Probably.  In fact ... I forget
> we have mhn.defaults.  I could populate that with a few more things
> (in fact, our defaults are kinda cruddy, now that I look at them).
> But you can fix this yourself in your .mh_profile for at least some
> common types.  Something else for the 1.5 list :-/
> 
> --Ken

Ah, here we go again!

I deliberately did not make whatnow attach the default because I was abiding
by the Hackercratic Oath: "first, do no harm lest you get flamed mercilessly."

This feature requires that some information associated with a draft persist
between nmh commands.  The only sensible way to do it was to use a non-standard
"X" header.  I made it configurable because I didn't want to break anybody's
setup by choosing a conflicting header name as improbable as that sounds.  Plus,
this feature doesn't play well with manual specification of mhbuild stuff, and
amazingly enough there are still people that use that.

However, change seems to be in the wind.  I would be perfectly happy to have
this behavior become the default.

Oh yeah, of course it tries to determine the correct MIME content type.

Jon