headers
David Levine | 22 Jun 2012 04:50
Picon
Favicon

mhmail is now stable

mhmail now has -header-field and -attach options.  I'm
done with it for the time being, assuming no bugs or
requests.

SYNOPSIS
mhmail [addrs ...] [-attach file] [-body text] [-cc addrs ...]
       [-from addr] [-header-field name:body] [-subject subject]
       [switches for post ... | -profile [switches for send ...]]
       [-resent] [-send | -nosend] [-version] [-help]

There can be multiple -attach and -header-field switches.

It has these differences from the old mhmail:
* Adds -send/-nosend, -header-field, and -attach options.
* Supports all post(8) (by default, without -profile) or send(1)
  (with -profile) options.
* Optionally (with -profile) obeys the users profile, including
  AliasFile and send entries.
* Instead of silently not sending an empty message, notifies user
  "mhmail: empty message not sent, use -body '' to force."
* The compiled mhmail dropped a trailing newline from the -body argument.
* Drops support for undocumented -queue option.

David

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
(Continue reading)

Permalink | Reply |
headers
norm | 22 Jun 2012 13:43

Re: mhmail is now stable

David Levine <levinedl <at> acm.org> writes:
>mhmail now has -header-field and -attach options.  I'm
>done with it for the time being, assuming no bugs or
>requests.
>
>SYNOPSIS
>mhmail [addrs ...] [-attach file] [-body text] [-cc addrs ...]
>[-from addr] [-header-field name:body] [-subject subject]
>[switches for post ... | -profile [switches for send ...]]
>[-resent] [-send | -nosend] [-version] [-help]
>
>There can be multiple -attach and -header-field switches.
Also multiple -cc fields?
>
>It has these differences from the old mhmail:
>* Adds -send/-nosend, -header-field, and -attach options.
>* Supports all post(8) (by default, without -profile) or send(1)
>(with -profile) options.
>* Optionally (with -profile) obeys the users profile, including
>AliasFile and send entries.
>* Instead of silently not sending an empty message, notifies user
>"mhmail: empty message not sent, use -body '' to force."
>* The compiled mhmail dropped a trailing newline from the -body argument.
>* Drops support for undocumented -queue option.
>
>
    Norman Shapiro

_______________________________________________
Nmh-workers mailing list
(Continue reading)

Permalink | Reply |
headers
David Levine | 22 Jun 2012 15:32
Picon
Favicon

Re: mhmail is now stable

Norm wrote:

> David Levine <levinedl <at> acm.org> writes:
> >
> >SYNOPSIS
> >mhmail [addrs ...] [-attach file] [-body text] [-cc addrs ...]
> >[-from addr] [-header-field name:body] [-subject subject]
> >[switches for post ... | -profile [switches for send ...]]
> >[-resent] [-send | -nosend] [-version] [-help]
> >
> >There can be multiple -attach and -header-field switches.
> Also multiple -cc fields?

Yes.  As before, there can be multiple cc addresses, either
in separate -cc switches or together.  So this:

  recip1 -cc recip2 recip3 -cc recip4

results in:

  To: recip1
  Cc: recip2, recip3, recip4

There can be intervening switches between addresses. To
avoid confusion, -attach and -header-field each require
exactly one argument (whoops, that needs to be enforced).
So they can appear multiple times.

An address goes to Cc: if -cc has appeared anywhere on the
command line before it, To: if not.  Again, that behavior
(Continue reading)

Permalink | Reply |
headers
norm | 22 Jun 2012 16:18

Re: mhmail is now stable

David Levine <levinedl <at> acm.org> writes:
>Norm wrote:
>
>> David Levine <levinedl <at> acm.org> writes:
>> >
>> >SYNOPSIS
>> >mhmail [addrs ...] [-attach file] [-body text] [-cc addrs ...]
>> >[-from addr] [-header-field name:body] [-subject subject]
>> >[switches for post ... | -profile [switches for send ...]]
>> >[-resent] [-send | -nosend] [-version] [-help]
>> >
>> >There can be multiple -attach and -header-field switches.
>> Also multiple -cc fields?
>
>Yes.  As before, there can be multiple cc addresses, either
>in separate -cc switches or together.  So this:
>
>recip1 -cc recip2 recip3 -cc recip4
>
>results in:
>
>To: recip1
>Cc: recip2, recip3, recip4
>
>There can be intervening switches between addresses. To
>avoid confusion, -attach and -header-field each require
>exactly one argument (whoops, that needs to be enforced).
>So they can appear multiple times.
>
>An address goes to Cc: if -cc has appeared anywhere on the
(Continue reading)

Permalink | Reply |
headers
Jerrad Pierce | 22 Jun 2012 17:00

Re: mhmail is now stable

A hyphenated switch (without long-opt beginning) seems awkard,
can we add -H (a la curl) as a synonym? I might also suggest
calling the header content a value rather than a body,
for unambiguity's sake.

Cheers!

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply |
headers
David Levine | 22 Jun 2012 17:23
Picon
Favicon

Re: mhmail is now stable

Norm wrote:

> David Levine <levinedl <at> acm.org> writes:

> >An address goes to Cc: if -cc has appeared anywhere on the
> >command line before it, To: if not.  Again, that behavior
> >has been retained from compiled mhmail.
> 
> Had I realized that, I would have suggested a, sometimes but always,
> redundant, -to switch.

I'll add optional -to:

  [[-to] addrs ...]

David

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply |
headers
David Levine | 22 Jun 2012 17:37
Picon
Favicon

Re: mhmail is now stable

Jerrad wrote:

> A hyphenated switch (without long-opt beginning) seems awkard,
> can we add -H (a la curl) as a synonym?

nmh doesn't have any other -<upper case> switches, either.
I'll change it to -headerfield, that's consistent with
-draftfolder, all the -no* switches, etc.

The switch can be abbreviated to -hea(derfield), I think
that's good enough.  

> I might also suggest calling the header content a value
> rather than a body, for unambiguity's sake.

We have the RFCs to blame for that.  I'll update the
documentation (and -help message, which was its only
appearance in the code.)

David

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply |
headers
Jerrad Pierce | 22 Jun 2012 17:41

Re: mhmail is now stable

>nmh doesn't have any other -<upper case> switches, either.
...
>The switch can be abbreviated to -hea(derfield)
Fair enough

>> I might also suggest calling the header content a value
>> rather than a body, for unambiguity's sake.
>We have the RFCs to blame for that.  I'll update the
I suspected as much, I guess they were expecting more recursive use,
or simply did not think of the confusion that could occasionally result :-P

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply |
headers
Robert Elz | 24 Jun 2012 13:48
Picon

Re: mhmail is now stable

    Date:        Thu, 21 Jun 2012 21:50:00 -0500
    From:        David Levine <levinedl <at> acm.org>
    Message-ID:  <915251.91332.qm <at> smtp111.sbc.mail.mud.yahoo.com>

  | mhmail now has -header-field and

Sorry, I've just been catching up on nmh mail after a few weeks of
ignoring it...

Any chance that could be just -field ?  -header-field is kind of
long (even given mh's ability to contract option names).

I know that will make the min abbrev of -from be -fr rather than
just -f but I don't think that's much of a disadvantage is it?

kre

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply |
headers
David Levine | 24 Jun 2012 19:53
Picon
Favicon

Re: mhmail is now stable

kre wrote:

> Any chance that could be just -field ?  -header-field is kind of
> long (even given mh's ability to contract option names).
> 
> I know that will make the min abbrev of -from be -fr rather than
> just -f but I don't think that's much of a disadvantage is it?

I prefer -headerfield because it's a bit more descriptive.
As you noted, it can be contracted to -head or -header (or
-hea), which are still descriptive and not too long, I think.

David

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply |

Gmane