Re: [Nmh-workers] temporary files

[David Levine]

> >Hell, it's not even that much of an edge case. It's a reasonably common
> >situation, and it silently fails by simply relinking the @ for each new
> >reply. Unless anyone has any strong rationale for keeping it around (and
> >I haven't seen any posted here so far), I'm all in favour of nuking it
> >altogether.
> 
> I am loath to get rid of an interface like this that has been around
> forever (and like Valdis said, exmh might use it).  AFAICT, this has
> only come up as an issue because of dropbox, and I think having a switch
> to turn it off might be the right solution here.

Agreed.  Though I'd be surprised if another program depended
on it because it's not created if the current directory isn't
writable.

If it's not used by exmh (and mh-e and xmh?), how about if we
disable it by default?

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Paul Fox]

ralph wrote:
 > Hi Jon,
 > 
 > > I guess that I avoid multiple concurrent compositions of all sorts
 > > because it's painful because of the shared draft file unless one uses
 > > long options.
 > 
 > I use them all the time and see no pain or need of long options?
 > 
 > $ grep draft ~/.mh_profile
 > draft-folder: drafts
 > $ apropos mh-draft
 > mh-draft (5) - draft folder facility for nmh message system
 > $
 > 

yeah, i'm a little confused by jon's problem.  i have a similar
draft-folder setting in .mh_profile, and i can reuse the most
recent draft (the usual case) with:
comp -use
and a specific former draft N with
comp -use N

no sharing of drafts, or long options, involved.

paul
=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 32.4 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Paul Fox]

ken wrote:
 > >Hell, it's not even that much of an edge case. It's a reasonably common
 > >situation, and it silently fails by simply relinking the @ for each new
 > >reply. Unless anyone has any strong rationale for keeping it around (and
 > >I haven't seen any posted here so far), I'm all in favour of nuking it
 > >altogether.
 > 
 > I am loath to get rid of an interface like this that has been around
 > forever (and like Valdis said, exmh might use it).  AFAICT, this has
 > only come up as an issue because of dropbox, and I think having a switch
 > to turn it off might be the right solution here.

i agree.  i've never had a use for @, and i almost said "nuke it"
earlier today, but adding an option to suppress it would be the right
choice.

paul

=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 32.4 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>>Anyway ... check out the man page for mhshow.  And also mhn.defaults
>>has an example.
>
>Hm, I realize now that attach does NOT CHECK mhn.defaults!  Whoops.
>Looks like you have to do extra work to make that happen.

Alright, so I just fixed that ... and I added a smattering of common
content types to mhn.defaults.  Others are welcome to add to the list.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Lyndon Nerenberg]

On 2012-03-15, at 7:35 PM, Jon Steinhart wrote:

> Oh, I can't take him like that -- it's against regulations.

*whack*

Ahh, thanks very much!

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>Anyway ... check out the man page for mhshow.  And also mhn.defaults has
>an example.

Hm, I realize now that attach does NOT CHECK mhn.defaults!  Whoops.
Looks like you have to do extra work to make that happen.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Jon Steinhart]

Lyndon Nerenberg writes:
> 
> On 2012-03-15, at 7:09 PM, Jon Steinhart wrote:
> 
> > What killed x-?
> 
> The IETF has been trying to stamp out x-* headers and commands (off all forms)
> for years.  The momentum has finally grown to the point where it looks like 
> it will happen.

Here's one -- nine pence.
I'm not dead!
What?
Nothing -- here's your nine pence.
I'm not dead!
Here -- he says he's not dead!
Yes, he is.
I'm not!
He isn't.
Well, he will be soon, he's very ill.
I'm getting better!
No, you're not -- you'll be stone dead in a moment.
Oh, I can't take him like that -- it's against regulations.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Lyndon Nerenberg]

On 2012-03-15, at 7:09 PM, Jon Steinhart wrote:

> What killed x-?

The IETF has been trying to stamp out x-* headers and commands (off all forms) 
for years.  The momentum has finally grown to the point where it looks like it 
will happen.



___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Jon Steinhart]

Lyndon Nerenberg writes:
> 
> On 2012-03-15, at 6:50 PM, Jon Steinhart wrote:
> 
> > Are you suggesting having a header like nmh-attachment which is rfc-problem
> atic
> > or just that we change the MH to NMH?
> 
> x-* is dead. ...

Please excuse my ignorance here.  What killed x-?

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Lyndon Nerenberg]

On 2012-03-15, at 6:50 PM, Jon Steinhart wrote:

> Are you suggesting having a header like nmh-attachment which is 
> rfc-problematic
> or just that we change the MH to NMH?

x-* is dead. If we're going to abuse the header namespace for things that 
trigger nmh-specific functionality, let's at least put them in a namespace that 
we can succinctly document as "these are not real rfc2822 messages headers; 
instead they trigger internal nmh actions."
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>Full disclosure:  I am using NMH version 1.3.  Alas, version 1.4 has not
>been ported to FreeBSD yet.  (Is this the real root of the problem?)

When you say "not ported" ... do you mean, "It doesn't work when I
tried to compile it?", because that's a serious problem.  Or do you
mean, "Not in the ports system", which is also a problem, but not
one we have control over.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Ken Hornstein]

>Hell, it's not even that much of an edge case. It's a reasonably common
>situation, and it silently fails by simply relinking the @ for each new
>reply. Unless anyone has any strong rationale for keeping it around (and
>I haven't seen any posted here so far), I'm all in favour of nuking it
>altogether.

I am loath to get rid of an interface like this that has been around
forever (and like Valdis said, exmh might use it).  AFAICT, this has
only come up as an issue because of dropbox, and I think having a switch
to turn it off might be the right solution here.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Jon Steinhart]

Lyndon Nerenberg writes:
> 
> On 2012-03-15, at 6:37 PM, Ken Hornstein wrote:
> 
> > With X-MH-Attachment?
> 
> Could we please use nmh-* for this stuff?  Just to make it clear this is 
> nmh-specific?

Are you suggesting having a header like nmh-attachment which is rfc-problematic
or just that we change the MH to NMH?

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Lyndon Nerenberg]

On 2012-03-15, at 6:37 PM, Ken Hornstein wrote:

> With X-MH-Attachment?

Could we please use nmh-* for this stuff?  Just to make it clear this is 
nmh-specific?
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>This all goes back to the "don't break things" approach that I took
>when I wrote this originally.  Maybe it's time to revisit it.  It's
>a complex issue because of the linkage between mime types and helper
>applications.  I used what was there which comes from mhshow.  No real
>objection to changing it althout /etc/mime.types may not exist on all
>systems.

A (very) quick survey seems to indicate to me that's a Linux-ism.

I see no reason why can't simply improve mhn.defaults; that should
make things better for the usual case.

Also, since we're revisiting things ... maybe we should make -attach
the default?  With X-MH-Attachment?  The people who use it haven't reported
any problems, right?  From what I see it doesn't affect anything if you
don't use it (and make -attachformat 1 be the default as well).

--ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Jon Steinhart]

valdis.kletni...@vt.edu writes:
> --==_Exmh_1331860781_2149P
> Content-Type: text/plain; charset=us-ascii
> 
> On Thu, 15 Mar 2012 18:02:48 PDT, Jon Steinhart said:
> 
> > And yes, having defaults for common content types in the profile would
> > be a good thing.  At the time that I wrote this stuff suffixes were not
> > nearly as standardized as they are today.
> 
> Wow.  Maybe somebody should gather them all up into a file and call
> it /etc/mime.types or something, so all programs could benefit?
> 
> 

Whoa, sarcasm.  It's SOO appreciated :)

This all goes back to the "don't break things" approach that I took when I
wrote this originally.  Maybe it's time to revisit it.  It's a complex issue
because of the linkage between mime types and helper applications.  I used
what was there which comes from mhshow.  No real objection to changing it
althout /etc/mime.types may not exist on all systems.  Also, there are
probably considerable differences in choices of helper applications.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Valdis . Kletnieks]

On Thu, 15 Mar 2012 18:02:48 PDT, Jon Steinhart said:

> And yes, having defaults for common content types in the profile would
> be a good thing.  At the time that I wrote this stuff suffixes were not
> nearly as standardized as they are today.

Wow.  Maybe somebody should gather them all up into a file and call
it /etc/mime.types or something, so all programs could benefit?




pgpcbXVhfyRyz.pgp
Description: PGP signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Valdis . Kletnieks]

On Fri, 16 Mar 2012 01:12:09 -, Tethys said:

> Hell, it's not even that much of an edge case. It's a reasonably
> common situation, and it silently fails by simply relinking the
> @ for each new reply. Unless anyone has any strong rationale for
> keeping it around (and I haven't seen any posted here so far),
> I'm all in favour of nuking it altogether.

exmh may use that for something, I'll check in more detail later tonight...


pgpUnvVcWA1v5.pgp
Description: PGP signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Tethys]

Jerrad Pierce writes:

>An edge-case issue with @ be it in . ~/ or `mhpath +`
>is that it does not allow for multiple concurrent replies.

Hell, it's not even that much of an edge case. It's a reasonably
common situation, and it silently fails by simply relinking the
@ for each new reply. Unless anyone has any strong rationale for
keeping it around (and I haven't seen any posted here so far),
I'm all in favour of nuking it altogether.

Tet

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Jon Steinhart]

>The only portion of the one I have here that seems at all relevant is
>this:
>
>   For file names with dot suffixes, the context is scanned for a
>   mhshow-suffix- entry for that suffix.  The content-type for
>   the part is taken from that context entry if a match is found.
>   If no match is found or the file does not have a dot suffix,
>   the content-type is text/plain if the file contains only ASCII
>   characters or application/octet-stream if it contains characters
>   outside of the ASCII range.

Yeah, that's the exact bit.  But like I said, it's rather short and
should contain a reference to mhshow.

>I am reading this and immediately asking myself: "Context?  What
>context?"

Now that I read that ... context is probably the wrong term (the nmh context
has stuff in it like the current message, folder, etc).  mh-profile(5)
explains that in greater detail, but in this case it should be "profile".

Anyway ... check out the man page for mhshow.  And also mhn.defaults has
an example.

>Anyway, even setting that issue aside for a moment, I'm still not seeing
>anything in this man page that tells me where to go or what to do if I'd
>like NHM to Do The Right Thing for various possible attachment types.
>Could you please elaborate for my edification?  If it is easily possible
>to make this work right, then I'd like to take a whack at it.

Sure.  Here's a sample line I used in my .mh_profile that I just
tested right now with the attach command; it did exactly what it was
supposed to do.

mhshow-suffix-application/pdf: .pdf

--Ken

Ah, I didn't understand the thread correctly.  Yes, it should be profile
and not context.  My mistake, although it lasted for years :)

And yes, having defaults for common content types in the profile would
be a good thing.  At the time that I wrote this stuff suffixes were not
nearly as standardized as they are today.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>The only portion of the one I have here that seems at all relevant is
>this:
>
>   For file names with dot suffixes, the context is scanned for a
>   mhshow-suffix- entry for that suffix.  The content-type for
>   the part is taken from that context entry if a match is found.
>   If no match is found or the file does not have a dot suffix,
>   the content-type is text/plain if the file contains only ASCII
>   characters or application/octet-stream if it contains characters
>   outside of the ASCII range.

Yeah, that's the exact bit.  But like I said, it's rather short and
should contain a reference to mhshow.

>I am reading this and immediately asking myself: "Context?  What
>context?"

Now that I read that ... context is probably the wrong term (the nmh context
has stuff in it like the current message, folder, etc).  mh-profile(5)
explains that in greater detail, but in this case it should be "profile".

Anyway ... check out the man page for mhshow.  And also mhn.defaults has
an example.

>Anyway, even setting that issue aside for a moment, I'm still not seeing
>anything in this man page that tells me where to go or what to do if I'd
>like NHM to Do The Right Thing for various possible attachment types.
>Could you please elaborate for my edification?  If it is easily possible
>to make this work right, then I'd like to take a whack at it.

Sure.  Here's a sample line I used in my .mh_profile that I just
tested right now with the attach command; it did exactly what it was
supposed to do.

mhshow-suffix-application/pdf: .pdf

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Ralph Corderoy]

Hi Jon,

> I guess that I avoid multiple concurrent compositions of all sorts
> because it's painful because of the shared draft file unless one uses
> long options.

I use them all the time and see no pain or need of long options?

$ grep draft ~/.mh_profile
draft-folder: drafts
$ apropos mh-draft
mh-draft (5) - draft folder facility for nmh message system
$

Cheers, Ralph.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ronald F. Guilmette]

In message <201203151405.q2fe5a4o028...@darkstar.fourwinds.com>, 
Jon Steinhart  wrote:

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

What behavior?  Having attach set the proper MIME type, based on the
actual content of the file?

That would seem like a reasonable choice to me.

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

Apparently, yes.  Conveying that into the Content-Type header would also
be Good, in my personal estimation.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ronald F. Guilmette]

In message <201203151323.q2fdnj00026...@hedwig.cmf.nrl.navy.mil>, 
Ken Hornstein  wrote:

>>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.

Marisa Tomei is a fine actress.

>I don't think it's
>unreasonable to use if nmh doesn't know how to handle a content type.

I don't think that I used the word "unreasonable".  The most applicable
adjective might be "sub-optimal".

>The send(1) man page explains how nmh can be configured to map
>particular suffixes to MIME content types when using atttach...

We must be reading two different man pages, you and I.

The only portion of the one I have here that seems at all relevant is this:

   For  file names with dot suffixes, the context is scanned for a mhshow-
   suffix- entry for that suffix.  The content-type for the part is  taken
   from  that  context entry if a match is found.  If no match is found or
   the file does not have a dot suffix, the content-type is text/plain  if
   the  file contains only ASCII characters or application/octet-stream if
   it contains characters outside of the ASCII range.

I am reading this and immediately asking myself: "Context?  What context?"

In short, if anybody wants to call me ignorant, then that's OK with me.
I plead guilty.  But I really have no idea what is being referred to here
when the term ``context'' is mentioned.  (It would have been helpful if
the terminology used here had been defined somewhere within this same man
page, but oh well.)

Anyway, even setting that issue aside for a moment, I'm still not seeing
anything in this man page that tells me where to go or what to do if I'd
like NHM to Do The Right Thing for various possible attachment types.
Could you please elaborate for my edification?  If it is easily possible
to make this work right, then I'd like to take a whack at it.

>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.

OK.  How?

I'm all ears.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Jerrad Pierce]

>I guess that I avoid multiple concurrent compositions of all
>sorts because it's painful because of the shared draft file
>unless one uses long options.
That's what .mh_profile defaults are for, and Jerry Peek's recomp ;-)
http://rand-mh.sourceforge.net/book/examples/mh/bin/recomp

The patch inlined below is for a slightly modified version with some
added conveniences.


--- recomp  2006-05-07 19:31:15.0 -0400
+++ mycomp  2012-03-15 18:51:00.0 -0400
@@ -1,18 +1,21 @@
-#! /bin/sh
-# $Id: recomp,v 1.9 1993/04/22 08:33:46 jerry book3 $
-### recomp - re-compose a draft mesage in MH draft folder
-### Usage: recomp [msgnum]
+#!/bin/sh
+# $Id: mycomp,v 1.3 2005-07-24 belg4mit$
+# Based on Id: recomp,v 1.9 1993/04/22 08:33:46 jerry book3
+### mycomp - optionally re-compose a draft mesage in MH draft folder
+### Usage: mycomp [msg]
+## mycomp -new
+## mycomp [comp options]
 ##
 ##  WHEN YOU TYPE q AT A What now? PROMPT, IT LEAVES THE DRAFT MESSAGE
 ##  WITHOUT SENDING IT.  IF YOU HAVE A DRAFT FOLDER, THE COMMAND LINE
 ##  YOU'D TYPE TO RE-COMPOSE THE DRAFT IS LONG, LIKE:
-##  comp -use -draftm 3 -draftf +drafts -editor vi.
+##  comp -use -draftm 3 -draftf +drafts
 ##  ALSO, IT CAN BE HARD TO REMEMBER THE DRAFT NUMBER--SO YOU HAVE TO
 ##  scan THE DRAFT FOLDER, THEN REMEMBER TO CHANGE YOUR FOLDER BACK.
 ##  
 ##  THIS SCRIPT HELPS WITH THAT.  IF YOU GIVE IT A MESSAGE NUMBER IN THE
 ##  DRAFT FOLDER, IT STARTS comp -use ON THAT MESSAGE WITH YOUR FAVORITE
-##  EDITOR PROGRAM.  WITHOUT A MESSAGE NUMBER, recomp scanS THE DRAFT
+##  EDITOR PROGRAM.  WITHOUT A MESSAGE NUMBER, mycomp scanS THE DRAFT
 ##  FOLDER, THEN LETS YOU ENTER THE NUMBER OF THE MESSAGE YOU WANT TO
 ##  RE-COMPOSE AND STARTS comp -use.
 ##
@@ -40,10 +43,11 @@
 # PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
 # POSSIBILITY OF SUCH DAMAGES.
 
+#   NOTE TO HACKERS: TABSTOPS ARE SET AT 4 IN THIS CODE
 
 draftf=+drafts  # NAME OF DRAFT FOLDER
 folopts="-fast -norecurse -nolist -nototal -nopack"
-mh=/usr/local/mh# WHERE MH PROGRAMS LIVE
+mh=/usr/local/bin# WHERE MH PROGRAMS LIVE
 
 # THIS SCRIPT CHANGES CURRENT FOLDER TO THE $draftf FOLDER.
 # SET TEMPORARY CONTEXT FILE SO OTHER MH PROCESSES WON'T NOTICE CHANGE:
@@ -51,7 +55,7 @@
 MHCONTEXT=$tempctx; export MHCONTEXT
 stat=1   # DEFAULT EXIT STATUS; RESET TO 0 FOR NORMAL EXITS
 trap '/bin/rm -f $tempctx; exit $stat' 0
-trap 'echo "`basename $0`: Interrupt!  Cleaning up..." 1>&2' 1 2 15
+#trap 'echo "`basename $0`: Interrupt!  Cleaning up..." 1>&2' 1 2 15
 $mh/folder $folopts $draftf >/dev/null || {
 echo "`basename $0`: quitting: problem with draft folder '$draftf'." 1>&2
 exit 1
@@ -61,20 +65,37 @@
 0)  # THEY DIDN'T GIVE MESSAGE NUMBER; SHOW THEM FOLDER:
 if $mh/scan
 then
-echo -n "Which draft message number do you want to re-edit? "
+printf "Which draft message to re-edit or cur [Enter] or (n)ew or 
(q)uit? "
 read msgnum
 else
-echo "`basename $0`: quitting: no messages in your $draftf folder?" 
1>&2
-exit
+msgnum="new"
 fi
 ;;
 1)  msgnum="$1" ;;
-*)  echo "I don't understand '$*'.
-I need the draft message number, if you know it... otherwise, nothing.
-Usage: `basename $0` [msgnum]" 1>&2
-exit
+*)
+$mh/comp $@
+exit $?;
 ;;
 esac
 
-$mh/comp -use -e ${VISUAL-${EDITOR-${EDIT-vi}}} -draftm $msgnum -draftf $draftf
+case "$msgnum" in
+0)  echo "comp: no messages match specification" ;;
+q)  exit;;
+n|ne|new|-n|-ne|-new)
+$mh/comp -draftf $draftf -nouse ;;
+*[0-9]*|cur|last)
+$mh/comp -draftf $draftf -use $msgnum;;
+?*)
+$mh/comp $@ ;;
+*)
+# Blank entry selects current message, or last
+if [ -z $msgnum ]; then
+   msgnum=`pick cur`
+   if [ $msgnum -eq 0 ]; then
+   msgnum=`pick last`
+   fi
+fi
+$mh/comp -draftf $draftf -use -draftm $msgnum ;;
+esac
+
 stat=$?   # SAVE comp'S STATUS (IT'S USUALLY 0) FOR OUR exit

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Jon Steinhart]

Jerrad Pierce writes:
> An edge-case issue with @ be it in . ~/ or `mhpath +`
> is that it does not allow for multiple concurrent replies.
> 
> Scripts should use the not-so-unintuitively named $editalt
> to inherit the correct context. Humans will have to live
> with @ pointing to the most recent message being replied to;
> assuming repl unlinks the first @, and unless editors have
> some way of the user accessing environment variables to
> determine which file to load**. Both of these points might
> be worth documenting?

I guess that I avoid multiple concurrent compositions of all
sorts because it's painful because of the shared draft file
unless one uses long options.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Mike O'Dell]

why not put draft files in the "draft" folder?

-mo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Jerrad Pierce]

An edge-case issue with @ be it in . ~/ or `mhpath +`
is that it does not allow for multiple concurrent replies.

Scripts should use the not-so-unintuitively named $editalt
to inherit the correct context. Humans will have to live
with @ pointing to the most recent message being replied to;
assuming repl unlinks the first @, and unless editors have
some way of the user accessing environment variables to
determine which file to load**. Both of these points might
be worth documenting?

** M-x getenv^Jeditalt^J

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[paul vixie]

On 3/15/2012 6:44 PM, Jon Steinhart wrote:
> I would suggest making it `mhpath +`/@ instead of ~/@. Should be fine
> in ~ but people expect mail stuff in the mail directory, and there are
> already plenty of other temporary files that go there such as
> occasional turds left over from post.

darn. i wish i'd thought of that. +1.


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Lyndon Nerenberg]

On 2012-03-15, at 11:46 AM, Jon Steinhart wrote:

> Sure.  But I am still curious as to the purpose intended by @ in the
> first place if anybody knows.

>From dist(1):

   See comp(1) for a description of the -editor and -noedit switches.  Note 
that while in
   the  editor,  the message being resent is available through a link named 
"@" (assuming
   the default whatnowproc).  In addition, the actual pathname of the 
message  is  stored
   in  the  environment  variable $editalt, and the pathname of the folder 
containing the
   message is stored in the environment variable $mhfolder.


It is provided as a fixed-name alias for the file being edited should you want 
to
run an external command on the composition file. (E.g. '!spell @'.)  Remember 
that this functionality pre-dates widespread availability of job control, or 
even cursor-addressable terminals (think DecWriter attached to the VAX).

The idea is that ./@ will always provide an invariant and memorable name for 
the composition file. Moving it to `mh-path`/@ defeats that goal.

I like Ken's idea about having a switch to turn this on and off.  People who 
don't want/need the link could disable it in .mh_profile.

--lyndon


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Jon Steinhart]

Paul Fox writes:
> jon wrote:
>  > Ken Hornstein writes:
>  > > >I agree.  But times have changed, and it doesn't work well with new
>  > > >stuff like dropbox.
>  > > 
>  > > Okay, I was confused a bit because you said the DRAFT temporary file,
>  > > but really the @ file is only created by dist and repl.
>  > > 
>  > > Jon, would you be happy with -atlink and -noatlink options to repl and
>  > > dist?
>  > > 
>  > > --Ken
>  > 
>  > Sure.  But I am still curious as to the purpose intended by @ in the
>  > first place if anybody knows.
> 
> i think in a world where repl doesn't quote the message you're
> replying to, it gives a very convenient place from which to fetch that
> text yourself.
> 
> paul

OK, I can buy that.  Just for the sake of discussion, that's `mhpath cur`
assuming that one doesn't have multiple replies running at once which is
problematic anyway.  So it seems like a bell or whistle.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Paul Fox]

jon wrote:
 > Ken Hornstein writes:
 > > >I agree.  But times have changed, and it doesn't work well with new
 > > >stuff like dropbox.
 > > 
 > > Okay, I was confused a bit because you said the DRAFT temporary file,
 > > but really the @ file is only created by dist and repl.
 > > 
 > > Jon, would you be happy with -atlink and -noatlink options to repl and
 > > dist?
 > > 
 > > --Ken
 > 
 > Sure.  But I am still curious as to the purpose intended by @ in the
 > first place if anybody knows.

i think in a world where repl doesn't quote the message you're
replying to, it gives a very convenient place from which to fetch that
text yourself.

paul
=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 40.3 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Jon Steinhart]

Ken Hornstein writes:
> >I agree.  But times have changed, and it doesn't work well with new
> >stuff like dropbox.
> 
> Okay, I was confused a bit because you said the DRAFT temporary file,
> but really the @ file is only created by dist and repl.
> 
> Jon, would you be happy with -atlink and -noatlink options to repl and
> dist?
> 
> --Ken

Sure.  But I am still curious as to the purpose intended by @ in the
first place if anybody knows.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Jon Steinhart]

paul vixie writes:
> On 3/15/2012 6:12 PM, Lyndon Nerenberg wrote:
> > On 2012-03-15, at 11:04 AM, Jon Steinhart wrote:
> >> But times have changed, and it doesn't work well with new stuff like 
> >> dropbox.
> > And dropbox is not a typical directory in the filesystem.  If you use a 
> > service that explicitly makes files publicly available 
> you shouldn't be surprised when it does what it's advertised to do.
> >
> > MH – quite reasonably – assumes UNIX filesystem semantics.  In particular, 
> > it assumes the permission bits are honoured, and it us
> es those bits to protect the file from public scrutiny.  If dropbox chooses 
> to ignore the permission bits, that's hardly MH's fau
> lt.
> 
> making this always be ~/@ rather than ./@ would fix this, even on
> dropbox systems, wouldn't it?

Answering both at once.

On one hand I agree with you, on another I don't.  The @ file is something that
is hardly every seen; one won't even notice unless one suspends when replying or
is looking at the same directory from another window.  It has the element of
surprise which is not a great thing in the UI sense.

I would suggest making it `mhpath +`/@ instead of ~/@.  Should be fine in ~ but
people expect mail stuff in the mail directory, and there are already plenty of
other temporary files that go there such as occasional turds left over from 
post.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Ken Hornstein]

>I agree.  But times have changed, and it doesn't work well with new
>stuff like dropbox.

Okay, I was confused a bit because you said the DRAFT temporary file,
but really the @ file is only created by dist and repl.

Jon, would you be happy with -atlink and -noatlink options to repl and
dist?

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Lyndon Nerenberg]

On 2012-03-15, at 11:14 AM, paul vixie wrote:

> making this always be ~/@ rather than ./@ would fix this, even on
> dropbox systems, wouldn't it?

Not if you point dropbox at $HOME.  And these days, it wouldn't surprise me 
that people do ...
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Paul Fox]

paul wrote:
 > On 3/15/2012 6:12 PM, Lyndon Nerenberg wrote:
 > > On 2012-03-15, at 11:04 AM, Jon Steinhart wrote:
 > >> But times have changed, and it doesn't work well with new stuff like 
 > >> dropbox.
 > > And dropbox is not a typical directory in the filesystem.  If you use a 
 > > service that explicitly makes files publicly available you shouldn't be 
 > > surprised when it does what it's advertised to do.
 > >
 > > MH – quite reasonably – assumes UNIX filesystem semantics.  In particular, 
 > > it assumes the permission bits are honoured, and it uses those bits to 
 > > protect the file from public scrutiny.  If dropbox chooses to ignore the 
 > > permission bits, that's hardly MH's fault.
 > 
 > making this always be ~/@ rather than ./@ would fix this, even on
 > dropbox systems, wouldn't it?

or making the behavior controllable.

paul
=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 41.0 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[paul vixie]

On 3/15/2012 6:12 PM, Lyndon Nerenberg wrote:
> On 2012-03-15, at 11:04 AM, Jon Steinhart wrote:
>> But times have changed, and it doesn't work well with new stuff like dropbox.
> And dropbox is not a typical directory in the filesystem.  If you use a 
> service that explicitly makes files publicly available you shouldn't be 
> surprised when it does what it's advertised to do.
>
> MH – quite reasonably – assumes UNIX filesystem semantics.  In particular, it 
> assumes the permission bits are honoured, and it uses those bits to protect 
> the file from public scrutiny.  If dropbox chooses to ignore the permission 
> bits, that's hardly MH's fault.

making this always be ~/@ rather than ./@ would fix this, even on
dropbox systems, wouldn't it?

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Lyndon Nerenberg]

On 2012-03-15, at 11:04 AM, Jon Steinhart wrote:

> But times have changed, and it doesn't work well with new stuff
> like dropbox.

And dropbox is not a typical directory in the filesystem.  If you use a service 
that explicitly makes files publicly available you shouldn't be surprised when 
it does what it's advertised to do.

MH – quite reasonably – assumes UNIX filesystem semantics.  In particular, it 
assumes the permission bits are honoured, and it uses those bits to protect the 
file from public scrutiny.  If dropbox chooses to ignore the permission bits, 
that's hardly MH's fault.

--lyndon
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Jon Steinhart]

paul vixie writes:
> On 3/15/2012 1:59 PM, Ken Hornstein wrote:
> >> Much appreciate your taking a crack at fixing it.  Just out of
> >> curiosity, why was this ever there in the first place?
> > I seem to recall that it's been thay way forever.  Maybe one of the
> > greybeards can speak up?
> 
> it worked fine in 1986.

I agree.  But times have changed, and it doesn't work well with new stuff
like dropbox.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[paul vixie]

On 3/15/2012 1:59 PM, Ken Hornstein wrote:
>> Much appreciate your taking a crack at fixing it.  Just out of
>> curiosity, why was this ever there in the first place?
> I seem to recall that it's been thay way forever.  Maybe one of the
> greybeards can speak up?

it worked fine in 1986.


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Ken Hornstein]

>Much appreciate your taking a crack at fixing it.  Just out of
>curiosity, why was this ever there in the first place?

I seem to recall that it's been thay way forever.  Maybe one of the
greybeards can speak up?

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Jerrad Pierce]

This behavior is documented in the repl man page, from context it appears to
be to support for custom editors (or the imaginary replproc) to do things w/o
having to grok the MH message filesystem

   See  comp(1)  for  a  description  of the -editor and -noedit switches.
   Note that while in the editor, the message being replied to  is  avail-
   able  through  a link named "@" (assuming the default whatnowproc).  In
   addition, the actual pathname of the message is stored in the  environ-
   ment  variable  $editalt, and the pathname of the folder containing the
   message is stored in the environment variable $mhfolder.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[Jon Steinhart]

David Levine writes:
> Jon wrote:
> 
> > > >Is there any way to change where nmh puts the draft temporary file?
> > > >Never paid much attention to this before, but nmh creates a file
> > > >named "@" in the current directory when editing a draft.
> >
> > It shows up when doing a reply.  I know that I don't have time to mess
> > with things right now but if somebody could look at it it's probably
> > gonna burn folks other than me.  Can't say that I understand why it's
> > needed.
> 
> Right, it's certainly not needed if the current directory
> isn't writable.  I'll try to look into making that the only
> behavior this weekend.
> 
> With the default Msg-Protect of 600, it shouldn't be group
> or world readable.  Do you have something else in your
> profile?
> 
> David

It's not an issue of permissions; it's creating the file in the cwd which
happens to be exported to other machines where people wonder what it's doing
there and su to find out.  In case you're not familiar with dropbox, it
runs a daemon that automatically imports/exports a set of directories so that
they can be shared with other users.  It differs from nfs in that the other
user's machines are not under your control having the same user names and so
on.  So this is a new problem created by a new product.

Much appreciate your taking a crack at fixing it.  Just out of curiosity, why
was this ever there in the first place?

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Are we ready for 1.5?

[Michael Richardson]

> "Ken" == Ken Hornstein  writes:
Ken> So, I just committed a test suite for the post command to test
Ken> out all of the new stuff I've been working on.  BTW, David
Ken> Levine deserves a big shout-out for all of the hard work he's
Ken> been doing on the test suite!

Test case test case test case!!!
WOOHOO!!

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ken Hornstein]

>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

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ronald F. Guilmette]

In message <84709.1331811...@tristatelogic.com>, I wrote:

>So I just commented that out, and then made sure I had "-attach 
>X-MH-Attachment"
>set for both whatnow _and_ send (apparently it _does_ need to be set on both)
>and now I can do attachements.  Yep, it's working.
>
>Thanks a bunch!!
>
>I am a happy camper.


Hummm... it now appears that I may have broken out the champaign a wee bit
prematurely.

I sent an attachment which was a JPEG file (four-leaf.jpg).

Looking down into the actual message that was sent, I see:

  Content-Type: application/octet-stream; name="four-leaf.jpg";
  x-unix-mode="0644"
  Content-ID: <84621.133181106...@tristatelogic.com>
  Content-Description:   JPEG image data, JFIF standard 1.01 
  Content-Transfer-Encoding: base64


Ahem.  Shouldn't that really say this instead?

  Content-Type: image/jpeg; ...

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"?

I don't expect miracles or clairvoiance, but I _was_ sort-of hoping that
NMH's features for sending attachments would at least be astute enough to
recognise a few of the more common content types, for example:

... well, nevermind.   I'm not going to list them cuz I'm sure you all
can guess what they are.  I'm talking, you know, Postscript files, PDF files,
MSWord (.DOC) files, eXcell spreadsheet files, PowerPoint files, HTML
documents, XML documents, .RTF files, .tar files, gzipped tar files,
shockwave flash files, Nroff/Troff files, .WAV files, .WMA files,
.MP3 files, .AVI files, QuickTime files ... should I go on?

This looks like a pretty comprehensive list:

  http://webdesign.about.com/od/multimedia/a/mime-types-by-content-type.htm


Regards,
rfg


P.S.  It seems pretty apparent that NMH is at least running the UNIX file(1)
command against the file being attached, and that this is where the content
of the Content-Description: header is being generated from.  It seems to me
that it should not be exceptionally difficult to map the output of the
UNIX file(1) command (for the input file) to a suitable MIME content-type
(and then stick that into the Content-Type: header).


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] temporary files

[David Levine]

Jon wrote:

> > >Is there any way to change where nmh puts the draft temporary file?
> > >Never paid much attention to this before, but nmh creates a file
> > >named "@" in the current directory when editing a draft.
>
> It shows up when doing a reply.  I know that I don't have time to mess
> with things right now but if somebody could look at it it's probably
> gonna burn folks other than me.  Can't say that I understand why it's
> needed.

Right, it's certainly not needed if the current directory
isn't writable.  I'll try to look into making that the only
behavior this weekend.

With the default Msg-Protect of 600, it shouldn't be group
or world readable.  Do you have something else in your
profile?

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ronald F. Guilmette]

In message <4f61a9c7.26063c0a.6da5.3...@mx.google.com>, you wrote:

>"Ronald F. Guilmette" writes:
>> Ummm... Well, now at least the failure message is different...
>> 
>>  What now? attach four-leaf.jpg
>>  
>>  What now? s
>>  mhbuild: draft shouldn't contain MIME-Version: field
>>  
>>  What now? 
>
>You're probably mime-ifying the message somehow (maybe in your profile).
>I get the same results if I manually mime-ify:

Ah!  Ok.  I had forgotten that (due to another suggestion that I had
found from googling) I had also put this into .mh_profile:

automimeproc: 1

So I just commented that out, and then made sure I had "-attach X-MH-Attachment"
set for both whatnow _and_ send (apparently it _does_ need to be set on both)
and now I can do attachements.  Yep, it's working.

Thanks a bunch!!

I am a happy camper.


Regards,
rfg

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Anthony J. Bentley]

"Ronald F. Guilmette" writes:
> In message <4f619a7c.c2093c0a.4c8b.2...@mx.google.com>, you wrote:
> 
> >"Ronald F. Guilmette" writes:
> >> Sorry.  I feel sure that this must be an FAQ, but how does one get this
> >> message to go away, you know, so that I can actually send an attachment?
> >
> >Try in .mh_profile:
> >
> >send: -attach X-MH-Attachment
> >whatnow: -attach X-MH-Attachment
> >
> >I actually only found out about this very recently by searching the lists.
> 
> Ummm... Well, now at least the failure message is different...
> 
>  What now? attach four-leaf.jpg
>  
>  What now? s
>  mhbuild: draft shouldn't contain MIME-Version: field
>  
>  What now? 

You're probably mime-ifying the message somehow (maybe in your profile).
I get the same results if I manually mime-ify:


$ comp

What now? mime

What now? attach /tmp/foo

What now? send
mhbuild: draft shouldn't contain MIME-Version: field


If I don't run mime, it goes through fine.


> P.S.  After trying your suggested fix, I realized that I wasn't sure if
> you meant that I should put the "-attach X-MH-Attachment" option on the
> send: or on the whatnow: or on both.

Both lines go in .mh_profile.

> When the option is appended to only to the send: it seems to have no effect
> and I still get the "can't attach because no header field name was given."
> message.

Right. When you use "attach" in whatnow, this header gets added to the draft:

X-MH-Attachment: /tmp/foo

If you don't have "-attach X-MH-Attachment", whatnow doesn't know what
header to put in and errors out. This isn't documented in the whatnow(1)
manpage at all, unfortunately.

>  When I attached it only to the whatnow: everything _seemed_ to
> work, but the e-mail message, when delivered, actually had no attachment
> whatsoever. :-(

Because send isn't told to look for a header, and thus doesn't perform the
replacement described in the man page. From send(1):

   If a header-field-name is supplied using the -attach option, the draft
   is scanned for a header whose field name matches the supplied header-
   field-name.  The draft is converted to a MIME message if one or more
   matches are found.  This conversion occurs before all other processing.

> Full disclosure:  I am using NMH version 1.3.  Alas, version 1.4 has not
> been ported to FreeBSD yet.  (Is this the real root of the problem?)

I'm on 1.4 (it's in OpenBSD ports), but I believe it works in previous
versions too. The mailing list posts were several years old...

--
Anthony J. Bentley

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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

[Ronald F. Guilmette]

In message <4f619a7c.c2093c0a.4c8b.2...@mx.google.com>, you wrote:

>"Ronald F. Guilmette" writes:
>> Sorry.  I feel sure that this must be an FAQ, but how does one get this
>> message to go away, you know, so that I can actually send an attachment?
>
>Try in .mh_profile:
>
>send: -attach X-MH-Attachment
>whatnow: -attach X-MH-Attachment
>
>I actually only found out about this very recently by searching the lists.

Ummm... Well, now at least the failure message is different...

 What now? attach four-leaf.jpg
 
 What now? s
 mhbuild: draft shouldn't contain MIME-Version: field
 
 What now? 

Any other suggestions?

>It would be nice to have adding attachments work by default...

Personally, I agree that that would indeed be admirable.


P.S.  After trying your suggested fix, I realized that I wasn't sure if
you meant that I should put the "-attach X-MH-Attachment" option on the
send: or on the whatnow: or on both.  The above result is what I got when
I tried it on both (as you seemed to suggest).  since that didn't work,
I also tried it individually, first on one and then on the other.

When the option is appended to only to the send: it seems to have no effect
and I still get the "can't attach because no header field name was given."
message.  When I attached it only to the whatnow: everything _seemed_ to
work, but the e-mail message, when delivered, actually had no attachment
whatsoever. :-(

Full disclosure:  I am using NMH version 1.3.  Alas, version 1.4 has not
been ported to FreeBSD yet.  (Is this the real root of the problem?)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers