Maybe mhmail needs a '-server servername' option and perhaps some other send
options as well.
Norman Shapiro
_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Norm wrote:
> Maybe mhmail needs a '-server servername' option and perhaps
> some other send options as well.
Perhaps, though is that necessary? It seems that mhmail was
intended to be lean. The man page recommends using comp and
send for interactive use. For scripts, a different mts.conf
could be used by setting MHMTSCONF, e.g.,
$ cat /tmp/mts.conf
servers: localhost
$ MHMTSCONF=/tmp/mts.conf mhmail levine \
-from guesswho <at> localhost -subject test -body hello
Note that mhmail uses post, not send. And it doesn't read
the user's profile or aliases. And I think that -from is
now required when sending, so we'll have to update that in
the man page.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
David Levine <levinedl <at> acm.org> writes:
>Norm wrote:
>
>> Maybe mhmail needs a '-server servername' option and perhaps
>> some other send options as well.
>
>Perhaps, though is that necessary? It seems that mhmail was
>intended to be lean. The man page recommends using comp and
>send for interactive use. For scripts, a different mts.conf
>could be used by setting MHMTSCONF, e.g.,
>
>$ cat /tmp/mts.conf
>servers: localhost
>
>$ MHMTSCONF=/tmp/mts.conf mhmail levine \
>-from guesswho <at> localhost -subject test -body hello
Ah! I did not know about MHMTSCONe Thank you.
Suppose I want to do something like:
mts=/usr/local/nmh/etc/mts.conf #depends on installation
sed < $mts >| /tmp/mts.conf -e '/^servers:/s/:.*/: localhost/'
MHMTSCONF=/tmp/mts.conf mhmail norm -from norm -subject "$1"
But replacing /usr/local/nmh/etc/mts.conf with the location of mts.conf.
Is there some way a script can know the location of nmh's etc directory?
Norman Shapiro
(Continue reading)
Norm wrote: > Suppose I want to do something like: > > mts=/usr/local/nmh/etc/mts.conf #depends on installation > sed < $mts >| /tmp/mts.conf -e '/^servers:/s/:.*/: localhost/' > MHMTSCONF=/tmp/mts.conf mhmail norm -from norm -subject "$1" > > But replacing /usr/local/nmh/etc/mts.conf with the location of mts.conf. > Is there some way a script can know the location of nmh's etc directory? `mhparam etcdir` To save a few cycles and file creation, I'd create a mts-localhost.conf and in etcdir or my Path dir, `mhpath +`. That also avoids the issue of /tmp running out of space. Failure to open $MHMTSCONF is a silently ignored error/bug. David _______________________________________________ Nmh-workers mailing list Nmh-workers <at> nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
> mts=/usr/local/nmh/etc/mts.conf #depends on installation > sed < $mts >| /tmp/mts.conf -e '/^servers:/s/:.*/: localhost/' > MHMTSCONF=/tmp/mts.conf mhmail norm -from norm -subject "$1" I'm wondering ... do you really think these gyrations are appropriate for mhmail? Back in "the day", needing to change the server used by post and friends was very rare, so putting it all in mts.conf was reasonable. But now we have alternate ports and changing servers is more common (it occurs to me that there's no way of specifying an alternate port via mts.conf for email submission). We also have options for SASL and TLS, which are also not configurable via mts.conf (although maybe they should be?). So I'm actually thinking that maybe it makes sense to have mhmail pass through various post options (kinda like what "send" does now). --Ken _______________________________________________ Nmh-workers mailing list Nmh-workers <at> nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
David Levine <levinedl <at> acm.org> writes: >Norm wrote: > >> Suppose I want to do something like: >> >> mts=/usr/local/nmh/etc/mts.conf #depends on installation >> sed < $mts >| /tmp/mts.conf -e '/^servers:/s/:.*/: localhost/' >> MHMTSCONF=/tmp/mts.conf mhmail norm -from norm -subject "$1" >> >> But replacing /usr/local/nmh/etc/mts.conf with the location of mts.conf. >> Is there some way a script can know the location of nmh's etc directory? > >`mhparam etcdir` OK. I will use it. Thank you. But without you to hold my hands, how could I have known that? It's not in the mhparam man page, In fact, share/doc/nmh/README.manpages and bin/mhparam are the only files anywhere in the nmh-1.5 hierarchy in which the string "etcdir" occurs. Also 'mhparam -all | grep etc' shows nothing. >To save a few cycles and file creation, I'd create a >mts-localhost.conf ... in etcdir or my Path dir, `mhpath +`. Wouldn't I then have to remember to rebuild mts-localhost.conf every time I installed a new version of nmh lest mts.conf include a new component? >That also avoids the issue of /tmp running out of space. >Failure to open $MHMTSCONF is a silently ignored error/bug.(Continue reading)
norm <at> dad.org wrote: > David Levine <levinedl <at> acm.org> writes: > >Norm wrote: > > > >> Suppose I want to do something like: > >> > >> mts=/usr/local/nmh/etc/mts.conf #depends on installation > >> sed < $mts >| /tmp/mts.conf -e '/^servers:/s/:.*/: localhost/' > >> MHMTSCONF=/tmp/mts.conf mhmail norm -from norm -subject "$1" > >> > >> But replacing /usr/local/nmh/etc/mts.conf with the location of mts.conf. > >> Is there some way a script can know the location of nmh's etc directory? > > > >`mhparam etcdir` > > OK. I will use it. Thank you. > > But without you to hold my hands, how could I have known that? > It's not in the mhparam man page, In fact, share/doc/nmh/README.manpages and > bin/mhparam are the only files anywhere in the nmh-1.5 hierarchy in which > the string "etcdir" occurs. Also 'mhparam -all | grep etc' shows nothing. i'll bet a patch to the man page would be welcomed!(Continue reading)(i didn't know about it either, and needed the "libdir" variant just the other day, to find the "ap" command.) paul =---------------------
Ken wrote: > I'm wondering ... do you really think these gyrations are appropriate > for mhmail? > > Back in "the day", needing to change the server used by post and > friends was very rare, so putting it all in mts.conf was reasonable. > But now we have alternate ports and changing servers is more common > (it occurs to me that there's no way of specifying an alternate port > via mts.conf for email submission). We also have options for SASL > and TLS, which are also not configurable via mts.conf (although > maybe they should be?). > > So I'm actually thinking that maybe it makes sense to have mhmail > pass through various post options (kinda like what "send" does now). I noticed that last night when I tried to write a test for it and saw that it needs a port option. Should we consider putting an end to the current mhmail? mhmail's man page says that it is "compatible with nmh", but it looks like that just means it reads mts.conf. With the shortcomings you noted. Can we make send look like mhmail (mhmail with arguments, when sending)? Then mhmail could be a simple wrapper around it. The only thing we'd lose is that it would read the profile and aliases, but I don't see those as a drawback these days. If it is important, we could add an option to send to not read them.(Continue reading)
>Can we make send look like mhmail (mhmail with arguments, when >sending)? Then mhmail could be a simple wrapper around it. >The only thing we'd lose is that it would read the profile and >aliases, but I don't see those as a drawback these days. If >it is important, we could add an option to send to not read >them. Okay, here's my thinking, for what it's worth: - "send" in my mind is mostly a front-end to "post" (or whatever you have your postproc set to). You need to give it a already-formed draft. - mhmail is more of a replacement for "mailx"; it does the draft composition for you. So I'm thinking ... well, I think putting a lot of mhmail into send is the wrong way to go. Different tools and all. We still have people using mhmail, so my vote would be to simply fix up mhmail. --Ken _______________________________________________ Nmh-workers mailing list Nmh-workers <at> nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
David Levine <levinedl <at> acm.org> writes: >Ken wrote: > >> I'm wondering ... do you really think these gyrations are appropriate >> for mhmail? >> >> Back in "the day", needing to change the server used by post and >> friends was very rare, so putting it all in mts.conf was reasonable. >> But now we have alternate ports and changing servers is more common >> (it occurs to me that there's no way of specifying an alternate port >> via mts.conf for email submission). We also have options for SASL >> and TLS, which are also not configurable via mts.conf (although >> maybe they should be?). >> >> So I'm actually thinking that maybe it makes sense to have mhmail >> pass through various post options (kinda like what "send" does now). > >I noticed that last night when I tried to write a test for >it and saw that it needs a port option. > >Should we consider putting an end to the current mhmail? >mhmail's man page says that it is "compatible with nmh", but >it looks like that just means it reads mts.conf. With the >shortcomings you noted. > >Can we make send look like mhmail (mhmail with arguments, when >sending)? Then mhmail could be a simple wrapper around it. >The only thing we'd lose is that it would read the profile and >aliases, but I don't see those as a drawback these days. If >it is important, we could add an option to send to not read(Continue reading)
Ken wrote: > Okay, here's my thinking, for what it's worth: > > - "send" in my mind is mostly a front-end to "post" (or whatever you > have your postproc set to). You need to give it a already-formed > draft. > - mhmail is more of a replacement for "mailx"; it does the draft > composition for you. > > So I'm thinking ... well, I think putting a lot of mhmail > into send is the wrong way to go. Different tools and > all. We still have people using mhmail, so my vote would > be to simply fix up mhmail. mhmail has traditionally been a front end to post, too. But it's now inadequate and it's a maintenance headache. I think that replacing it with a script that relies on send or post could solve both problems. Let me take a deeper look tonight and see what I come up with. Paul wrote: > i'll bet a patch to the man page would be welcomed!(Continue reading)
>mhmail has traditionally been a front end to post, too. >But it's now inadequate and it's a maintenance headache. >I think that replacing it with a script that relies >on send or post could solve both problems. I don't really care about the implementation details (although it occurs to me that one of the lessons from the test suite is that it's tricky to write a truely portable shell script). As long as mhmail has similar functionality as to what it has now, then I'm fine with that. --Ken _______________________________________________ Nmh-workers mailing list Nmh-workers <at> nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
David Levine <levinedl <at> acm.org> writes: >Ken wrote: > >> Okay, here's my thinking, for what it's worth: >> >> - "send" in my mind is mostly a front-end to "post" (or whatever you >> have your postproc set to). You need to give it a already-formed >> draft. >> - mhmail is more of a replacement for "mailx"; it does the draft >> composition for you. >> >> So I'm thinking ... well, I think putting a lot of mhmail >> into send is the wrong way to go. Different tools and >> all. We still have people using mhmail, so my vote would >> be to simply fix up mhmail. > >mhmail has traditionally been a front end to post, too. >But it's now inadequate and it's a maintenance headache. >I think that replacing it with a script that relies >on send or post could solve both problems. > >Let me take a deeper look tonight and see what I come up >with. > > >Paul wrote: > >> i'll bet a patch to the man page would be welcomed!(Continue reading)
>4. YES THERE IS!! mhmail is more properly thought of as draft composition >utility, and not as a cheap version of send. I wouldn't claim to have greater knowledge of MH history than you, Norm ... but are you sure about that? I was looking at the man page for mhmail just now, and it specifically says that it's intended for things like "cron", where it's pretty common to do something like: 0 2 * * * some cron command | mailx -s "Nightly job" admin,root Easy enough to drop in "mhmail" instead of mailx there. So it looks like to me that mhmail is around because it's kind of a pain to do that with the existing nmh suite. But if we're talking about draft composition ... well, shoot. We already have "comp" for that. Give it a custom form file and you're all set. But it doesn't exactly fit in a cron pipeline, does it? We have a bunch of tools that want to pass through the options for "post" so it occurs to me we should maybe factor that out into some common code to make it easier. If we did that then making the existing mhmail use that would be a snap. --Ken _______________________________________________ Nmh-workers mailing list Nmh-workers <at> nongnu.org(Continue reading)
Ken Hornstein <kenh <at> pobox.com> writes:
>>4. YES THERE IS!! mhmail is more properly thought of as draft composition
>>utility, and not as a cheap version of send.
>
>I wouldn't claim to have greater knowledge of MH history than you, Norm ...
>but are you sure about that?
I did not intend to make a historical claim, but a propriety claim.
Norman Shapiro
798 Barron Avenue
Palo Alto CA 94306-3109
(650) 565-8215
norm <at> dad.org
_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
I just committed uip/mhmail.in. It's a .in file because autoconf will eventually digest it, but it can be run as-is for now. By default, it uses post. It emulates mhmail plus passes along any post options. So this works, and ignores the server in my mts.conf: uip/mhmail.in levine -subject test -body hello -server localhost -snoop Optionally, it can use send, thereby obeying the user's profile and aliases: uip/mhmail.in levine -from levinedl <at> acm.org -body hello -profile If anyone wants to try it without getting it from the git repository, let me know and I'll email it to you (using itself
Norm wrote: > It's not in the mhparam man page, In fact, > share/doc/nmh/README.manpages and bin/mhparam are the only files > anywhere in the nmh-1.5 hierarchy in which the string "etcdir" > occurs. Also 'mhparam -all | grep etc' shows nothing. I added etcdir and libdir to the mhparam man page. David _______________________________________________ Nmh-workers mailing list Nmh-workers <at> nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
David Levine <levinedl <at> acm.org> writes:
>Norm wrote:
>
>> It's not in the mhparam man page, In fact,
>> share/doc/nmh/README.manpages and bin/mhparam are the only files
>> anywhere in the nmh-1.5 hierarchy in which the string "etcdir"
>> occurs. Also 'mhparam -all | grep etc' shows nothing.
>
>I added etcdir and libdir to the mhparam man page.
Also, uip/mhparam.c should be fixed so that -all includes etcdir and libdir.
Norman Shapiro
_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Norm wrote:
> David Levine <levinedl <at> acm.org> writes:
> >Norm wrote:
> >
> >> It's not in the mhparam man page, In fact,
> >> share/doc/nmh/README.manpages and bin/mhparam are the only files
> >> anywhere in the nmh-1.5 hierarchy in which the string "etcdir"
> >> occurs. Also 'mhparam -all | grep etc' shows nothing.
> >
> >I added etcdir and libdir to the mhparam man page.
>
> Also, uip/mhparam.c should be fixed so that -all includes etcdir and
> libdir.
That's a bigger change to mhparam than I'd like to make
right now. The code (and test suite!) change wouldn't be
difficult, but much of the man page would have to be
rewritten because it currently doesn't sound like those fit
the purpose ("profile and context components"). Maybe
that's why these hadn't been documented.
This excerpt from the test suite shows what I mean. -all
provides the verbatim contents of .mh_profile plus the
current folder, which is context:
# check -all
cp $MH_TEST_DIR/Mail/.mh_profile $expected
# -all adds current folder
(Continue reading)
RSS Feed