Re: vixie out
Ken Hornstein wrote: > >The new system is Office 365 and all employees are *required* to use > >Lookout on their Windows and Mac systems as an MUA using a badge for > >authentication. Given that, I'm pessimistic there is an open way to > >access NASA email. Linux users currently have a waiver to continue using > >IMAP, but that will go away once NASA IT finds a solution. It is likely > >to be a dictated MUA (as with the Mac and Windows) rather than a general > >mechanism. > > Geez, you really should be more up-to-date on the mailing list :-) We're in agreement there! > I can't promise this will work for you, but this message might be > helpful: > > https://lists.nongnu.org/archive/html/nmh-workers/2019-05/msg00029.html Indeed. If you're still associated with the navy, you're certainly feeling the same pain, as the requirements come from the NIST, I think. I'll look forward to trying it when I return to the office. Thanks for pointing out the thread as I clearly missed it during my skim. > --Ken -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Re: vixie out
Ken Hornstein wrote: > Geez, Bill, you HAVE been out of it for a little while, haven't you? :-) > > >Dovecot is a server and Maildir is mail storage format. What are you > >using as a UI? > > Paul has mentioned this before, but to fill you in ... I forget which > MUA he uses (I want to say Thunderbird, maybe?) but the key point here > is Dovecot stores it's messages in Maildir folders. So he was interested > in tools that could work directly on Maildir folders. This is a _BIT_ > challenging. Thanks for that. My mail to p...@vix.com bounced. > As a larger note ... I always thought the use of Maildir as a message > folder format was a bit weird. I have no objections if people want to > add that support for Maildir folders, but there are some challenges, and > I think the number of people who would find that useful is small compared > to the number of people who would find IMAP useful, so it wasn't something > I was going to work on (we do, today, have support in inc(1) for Maildir). > > >Yeah, with all of the security that NASA is adding, my days of fetchmail > >and procmail are numbered at work, and with it, MH and MH-E, unless I > >can find a way to bridge the gap between the NASA Linux email UI > >(Evolution?) and the MH mail store. > > I can't speak for exactly what you guys are doing, but I believe we > support all of the relevant security protocols with regards to POP > and SMTP. So if you guys have a POP server and a SMTP server you point > Evolution to, I don't think there's a reason you couldn't use nmh with it. The new system is Office 365 and all employees are *required* to use Lookout on their Windows and Mac systems as an MUA using a badge for authentication. Given that, I'm pessimistic there is an open way to access NASA email. Linux users currently have a waiver to continue using IMAP, but that will go away once NASA IT finds a solution. It is likely to be a dictated MUA (as with the Mac and Windows) rather than a general mechanism. > --Ken -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Re: vixie out
Paul Vixie writes: > folks, it's been a blast. i used MH from 1985 to 2005 exclusively, > then from 2005 to 2015 in parallel with uw-imapd, and not at all since > mark crispen's death when i moved to dovecot and Maildir. Dovecot is a server and Maildir is mail storage format. What are you using as a UI? > i've helped find and fix bugs in the MH library, i regularly tested > and patched the MH (and Kerberos) parts of uw-imap, i even wrote some > hooks (thanks, jon!) for maintaining and using a BDB index for NMH's > folders. > > i've operated a 32-bit NMH build server back when i had 32-bit > servers, and i've started a few and joined many discussions as to > software portability and system architecture here. > > but i think it's time i admitted that IMAP and MIME are my future, and > that i will probably never use NMH or MH-E again. Yeah, with all of the security that NASA is adding, my days of fetchmail and procmail are numbered at work, and with it, MH and MH-E, unless I can find a way to bridge the gap between the NASA Linux email UI (Evolution?) and the MH mail store. > you are a great team but it's time i said goodbye. i'm about to answer > the unsubscribe-verify e-mail; i don't see any non-cc'd followups. And all the best to you. > goodbye all! > > -- > P Vixie -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Re: Future directions for nmh
gger >warning for Lyndon so he could start drinking heavily before he >read it :-) > >For Maildir, a similar idea, except that you could do annontations >directly in the message. Really, none of that seems hard to me. >Maybe some details to work out, but I don't see any major challenges. >I'd be interested to hear people tell me if I'm wrong, or if they >have suggestions or better ideas. > > --Ken > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers > n...@dad.org writes: > Ken Hornstein writes: > >> >>4) In terms of alternate mail stores, be they Maildir or IMAP (I think >>those are the two major candidates now, right?), I think those ideas >>are interesting. The #1 problem with those ideas is how to map MH >>message numbers (which can range 1-MAXINT, with holes) to the internal >>key used by those mail stores; everything else is relatively easy >>to deal with. > > I can't quite tell if by "alternate", you meant optional. I certainly hope > so. > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers > Ken Hornstein writes: >>>4) In terms of alternate mail stores, be they Maildir or IMAP (I think >>>those are the two major candidates now, right?), I think those ideas >>>are interesting. The #1 problem with those ideas is how to map MH >>>message numbers (which can range 1-MAXINT, with holes) to the internal >>>key used by those mail stores; everything else is relatively easy >>>to deal with. >> >>I can't quite tell if by "alternate", you meant optional. I certainly hope >>so. > > I am not proposing that we replace the current MH mailstore with Maildir, > if that's what you mean. You should still be able to use the traditional > MH mailstore (and we'll keep that the default) for the forseeable future. > > I am saying that we have people who want to use the nmh tools with both > IMAP and Maildir mailstores. So making the nmh tools work with those > mailstores would be useful. > > --Ken > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers > Conrad Hughes writes: > Ken> I am saying that we have people who want to use the nmh tools with both > Ken> IMAP and Maildir mailstores. So making the nmh tools work with those > Ken> mailstores would be useful. > > .. with migration via refile between different store types .. that > sounds cool.. > > C. > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers > -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Re: ics files with nhm / mh-e
Axel, Once you find something that works on the command line, I can think of a couple of ways to access your method with MH-E: 1. Use the `|' (mh-pipe-msg) command to pipe the entire message through an appropriate command. https://mh-e.sourceforge.io/manual/mh-e.html#Files-and-Pipes 2. Use `K e' (mh-display-with-external-viewer) to 'view' the ICS attachment with an appropriate command. https://mh-e.sourceforge.io/manual/mh-e.html#Viewing-Attachments Axel Jantsch wrote: > Hi, > > What are the best ways to deal with ics calendar files with nhm and/or mh-e ? > > I use nmh with mh-e as front end, and get regularly ics files. When > getting such a file I would like to do the following: > > 1 a) Add the event to my google calendar; > b) Make an update to an existing event in my google calendar > > 2 a) Add it to the emacs diary file; > b) Make an update to an existing entry in emacs diary; > > 3) Acknowledge / accept / reject the event; > > > For (1a) I use gcalcli but I feel it is a bit unreliable; it worked > well, then it did not work for several months due to an update; then it > worked again on some of my platforms but not others. So I wonder if > there is a better alternative. > > For (1b) and (3) I have no working solution. > > What methods do others use? > > Cheers, > Axel > > -- > Axel Jantsch > TU Wien > Email: axel.jant...@tuwien.ac.at > Web: www.ict.tuwien.ac.at > > > ___ > mh-e-users mailing list > mh-e-us...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mh-e-users > -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Re: nmh query
[Trying to get through some backlog before upcoming travel builds it back up again.] Hey, you started using MH a couple of years before me. Awesome. I'm still using 1.6, so I'm unfamiliar with the keepbcc and .msmtprc file. Please use nmh-workers@nongnu.org for your question. b...@rfob.org wrote: > i read the faq - honest injun! > > i started using mh in 1982 and it still works - thanks in part to folks like > you! > > if there is a small nit in nmh-1.7.1 (even with keepbcc on in .msmtprc > BCC: line does not show up to bcc recipients) who do i ask? > > thanks much! > cheers > bala > -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD
Re: [Nmh-workers] better HTML rendering for selective emails
David Levine levin...@acm.org wrote: Bill wrote: mhshow-show-text/html: google-chrome '%f' In case anyone is still using nmh 1.5 or earlier (:-), that quoted escape would get expanded to ''%f''. But those quotes aren't necessary anyway because nmh quotes as necessary. And properly in 1.6. Thanks, I've updated my .mh_profile. The quotes should be removed from examples in the FAQ, too. Done. Thanks for the correction. I was reminded of this by Ralph's mention of urlview(1), which says in its man page: Note: You should never put single quotes around the %s. urlview does this for you, and also makes sure that single quotes eventually showing up inside the URL are handled properly. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] better HTML rendering for selective emails
Michael Richardson m...@sandelman.ca writes: I use mh-e under GNU Emacs. (I used to run Xemacs). HTML rendering is okay, and 99% of the time, I prefer the text/plain anyway. But when I need it, I need it bad, and I forw -mime to my gmail account. (Talking HTML emails with tables. The worst offender is a status report *I* wrote. HTML tables was the right answer) Hi Michael, In MH-E, you can use `K e' (`mh-display-with-external-viewer') to view the HTML part in your browser (I use this a LOT). You may have to use `K t' (`mh-toggle-mime-buttons') first to make the text/html button visible. I also have the following in my .mh_profile so that show on the command line goes directly to the browser: mhshow-show-text/html: google-chrome '%f' -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] date math
David Levine levin...@acm.org writes: Ken wrote: [Norm:] Shouldn't that be the default? You know ... maybe? What do others think? No, because date is the sender's context. And it's easy enough to change how it's viewed. Disagree, because the date is viewed in the reader's context. Easy enough? If it were easy, then why did 30 years pass before I found out how to do it. Most of my emails at work are not in my timezone, and it is @#*#@! annoying to have to do the conversion when the message is Meeting in half an hour and trying to figure out if I've missed it or not. Upon further reflection, I think ALL email at work is not in my timezone. NASA uses EST and email from my German colleagues is all in CET. Ken, thanks VERY much for passing on that tip. +1 for making local time the default, unless -noshowproc (or equivalent) is in play. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] date math
Lyndon Nerenberg lyn...@orthanc.ca writes: On Dec 15, 2014, at 9:46 AM, Ken Hornstein k...@pobox.com wrote: So that makes me wonder if we should still try to bother to generate a symbolic timezone name. It looks like the only portable way to do this is to have an internal list of timezone names. A large part of me says to not bother. The IETF has been discouraging symbolic timezone names for many years. I would say ditch them. For those who want a symbolic timezone (usually recipients) it's so they can easily mentally convert to their local time. Those folks are better served by a + offset that their local MUA can unambiguously convert to local time for display. And for those of us who do care about the senders local time, the + format makes it a lot easier for me to do the mental conversion vs. deciphering some unknown-to-me local-to-them timezone abbreviation. Agree with Lyndon here. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.6 has been released!
Ken Hornstein k...@pobox.com writes: Not in 1.6; this change is not on the branch: I WAS sort of vague on the details; I guess I should have said, 1.6 if you've got the right configuration, newer versions it will work automatically. But I didn't want to get bogged down into the weeds here. But I wonder if most people wouldn't prefer that you just stop including these; it's funny that the last post to mh-e-users before yours was a post about forcing MH-E not to download... :) The archives (at least ones that are driven by MHonArc) and I'm told Gmail does the right thing with those message/external-body parts. Although that message DID break MHonArc (but any message with RFC 2231 parameter encoding would have done that; previous messages that didn't have RFC 2231 encoding were fine). What do others think? I kind of think MH-E should be fixed! I know those are out of fashion now, but I still think they're convenient. Agreed :-). https://sourceforge.net/p/mh-e/bugs/475/ -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] MH FAQ update
Ken Hornstein k...@pobox.com writes: The original content of the FAQ came from the comp.mail.mh newsgroup. I haven't had access to that for years, which is the main reason we haven't had a FAQ update in a long time. Does it still exist? If so, is there traffic, and is there an email gateway? Ralph already answered you, but other than the FAQ and spam, the last actual on-topic post on the newsgroup was in April. Before that, the last on-topic post was in 2012 (and Jerry Heyman was nice enough to redirect the person to the mailing list). Thanks, I'll add the reference even if it isn't terribly active. As I was reacquainting myself with the FAQ, my first reaction was to remove all of the obsolete text, or references to sites that were no longer available. However, I thought better of it. This document encapsulates the long history of MH. What do you think? I believe that an FAQ should reflect the most up-to-date information available. I think questions like, Why does inc hang on a Sun?, should totally be deleted. Also, I think a number of URLs (like to additional software) are stale. Maybe take a look at every question that has a date before 2008 and think about deleting it? Okay, yeah, that's probably most of them. But still, there's a lot of stale stuff in there. I'd still like to hear from a few others on where to draw the line for purging old information. A reference to a piece of software whose URL is no longer accessible might still result in a search that turns up some software of some use to the user. I'm inclined to follow Ken's advice. However, once the information is gone, it is gone forever, so I'd like to get some more opinions before going crazy. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] configuring message submission port
Ken Hornstein k...@pobox.com writes: okay -- i can accept all that. but at the least the documentation needs to keep up. mts.conf.man, mh-tailor, the FAQ, should all mention that the basic client connectivity has changed. Fair enough; that's a valid criticism. The FAQ is Bill's baby; it's kind of out of date and I haven't really wanted to tackle it. But I will take on updating those man pages. Yeah, that's true, but then I haven't received any contributions to add to it :-). I'll make a quick pass now and at least update the nmh version number. If you see anything that's blatently wrong, please let me know. A FAQ update can be pushed out relatively quickly. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] MH FAQ update
Bill Wohler woh...@newt.com writes: Ken Hornstein k...@pobox.com writes: okay -- i can accept all that. but at the least the documentation needs to keep up. mts.conf.man, mh-tailor, the FAQ, should all mention that the basic client connectivity has changed. Fair enough; that's a valid criticism. The FAQ is Bill's baby; it's kind of out of date and I haven't really wanted to tackle it. But I will take on updating those man pages. Yeah, that's true, but then I haven't received any contributions to add to it :-). I'll make a quick pass now and at least update the nmh version number. If you see anything that's blatently wrong, please let me know. A FAQ update can be pushed out relatively quickly. I've updated the nmh stable update version number and a couple of other things. While not strictly FAQs, perhaps it would be good to make a few additions that point out things in other answers that are currently wrong. The original content of the FAQ came from the comp.mail.mh newsgroup. I haven't had access to that for years, which is the main reason we haven't had a FAQ update in a long time. Does it still exist? If so, is there traffic, and is there an email gateway? As I was reacquainting myself with the FAQ, my first reaction was to remove all of the obsolete text, or references to sites that were no longer available. However, I thought better of it. This document encapsulates the long history of MH. What do you think? -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] MH FAQ update
Bill Wohler woh...@newt.com writes: Bill Wohler woh...@newt.com writes: Ken Hornstein k...@pobox.com writes: okay -- i can accept all that. but at the least the documentation needs to keep up. mts.conf.man, mh-tailor, the FAQ, should all mention that the basic client connectivity has changed. Fair enough; that's a valid criticism. The FAQ is Bill's baby; it's kind of out of date and I haven't really wanted to tackle it. But I will take on updating those man pages. Yeah, that's true, but then I haven't received any contributions to add to it :-). I'll make a quick pass now and at least update the nmh version number. If you see anything that's blatently wrong, please let me know. A FAQ update can be pushed out relatively quickly. If you have time over the long Thanksgiving weekend (for those of you in the US) to send me updates, I'll incorporate them and push an update to the git repository and FAQ servers next Sunday night. Thanks. http://www.newt.com/faq/mh.html nmh/docs/FAQ I've updated the nmh stable update version number and a couple of other things. While not strictly FAQs, perhaps it would be good to make a few additions that point out things in other answers that are currently wrong. The original content of the FAQ came from the comp.mail.mh newsgroup. I haven't had access to that for years, which is the main reason we haven't had a FAQ update in a long time. Does it still exist? If so, is there traffic, and is there an email gateway? As I was reacquainting myself with the FAQ, my first reaction was to remove all of the obsolete text, or references to sites that were no longer available. However, I thought better of it. This document encapsulates the long history of MH. What do you think? -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What are and what should be the qualifications for a current nmh user
n...@dad.org wrote: Bill Wohler woh...@newt.com writes: n...@dad.org writes: Ken Hornstein k...@pobox.com writes: (Half a year ago) I've thought about the nmh target audience ... I guess my thinking is the ideal nmh user be programmers who want a flexible MUA that can make use of many of the features of the Unix command line. Way back when I was working at SRI in the 80's, our entire group, programmers, scientists, and support staff alike, used MH. Thus non-programmers could use MH, and that hasn't changed. But I bet that, like RAND, almost all, if all of your new users were within a few feet of more experienced users, probably running terminals into a time shared system -- no new users running a PC in Wichita. No, I don't think our secretaries were that close to the developers in skill. None that I knew of had ever written device drivers :-). AND, there was no MIME. So you had it a lot easier than contemporary developers. Norman Shapiro -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] directory path changes pushed
Lyndon Nerenberg lyn...@orthanc.ca writes: The directory path changes have been pushed to the git repository. The configuration files have moved from PREFIX/etc to PREFIX/etc/nmh. The support binaries have moved from PREFIX/lib to PREFIX/libexec/nmh. For a fresh source build on a machine with no existing nmh install this means configs are now in /usr/local/nmh/etc/nmh, and the back end binaries are in /usr/local/nmh/libexec/nmh. That's redundant. In this case, can PREFIX for fresh installs be /usr/local so the path is /usr/local/etc/nmh instead of /usr/local/nmh/etc/nmh? Like this? If you configure with --prefix=/usr/local, it will use /usr/local/etc/nmh and /usr/local/libexec/nmh. The one visible change is that 'mhparam libdir' has been renamed 'mhparam libexecdir'. 'libdir' remains as an alias for 'libexecdir', but is deprecated and will be removed in a future release. Portable scripts should try 'mhparam libexecdir' first, and fall back to 'mhparam libdir' if the first returns no output. OK, thanks for the heads up. Please do not be too anxious to remove it since libdir will be in Emacs for years to come. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] A --prefix friendly install
Ken Hornstein k...@pobox.com writes: This layout isn't very friendly with 'configure --prefix=/usr/local'. I would like to adopt a more Berkeley-ish layout. Specifically, moving .../etc/* to .../etc/nmh/*, and .../lib/* to .../libexec/nmh/*. This more closely follows current filesystem layouts, and for those which don't, we still avoid spamming their existing directories. And in the default case, under /usr/local/nmh, nothing is upset internally. I recently installed nmh at work in my home directory. That, along with /opt, is pretty much the only case I can think of where putting everything in a single directory is convenient. I don't like cluttering the /usr/local namespace with nmh. I think your proposal is that if prefix is /usr/local, the installation would go in /usr/local/bin/nmh, /usr/local/etc/nmh, and so on? The Debian installation puts stuff in /usr/bin/mh, /usr/share/man/man1, /usr/lib/mh, and /etc/nmh. Other than people who have paths hardcoded for /usr/local/nmh/lib into their programs. We should coordinate with exmh and MH-E people to make sure that doesn't break things. Maybe we can even get Valdis to crank out a new release of exmh? Regarding MH-E, the following variable specifies possible bin directories: (defvar mh-sys-path '(/usr/local/nmh/bin; nmh default /usr/local/bin/mh/ /usr/local/mh/ /usr/bin/mh/ ; Ultrix 4.2, Linux /usr/new/mh/ ; Ultrix 4.2 /usr/contrib/mh/bin/ ; BSDI /usr/pkg/bin/ ; NetBSD /usr/local/bin/ /usr/local/bin/mu-mh/ ; GNU mailutils MH - default /usr/bin/mu-mh/) ; GNU mailutils MH - packaged List of directories to search for variants of the MH variant. The list `exec-path' is searched in addition to this list. There's no need for users to modify this list. Instead add extra directories to the customizable variable `mh-path'.) We then use mhparam libdir and mhparam libdir to find the other directories. Please let me know if I should add /usr/local/bin/nmh per my comment above. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Getting Into My Email System
Ken Hornstein k...@pobox.com writes: A TIVO support guy, recently instructed me to get into your Email System. I did not argue with him, by saying that my Email system is nmh and it's not something that I can get into. Instead I got into a terminal emulator running bash. For, indeed, bash IS my Email system. Norm, you and are probably the only two people on the planet who have a) called into TiVo technical support and b) use nmh. When I get into those situations, I just gladly agree (just like I do when people ask me to launch Internet Explorer). Actually, it's three people :-). -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] quoted printable. make it stop.
Ken Hornstein k...@pobox.com writes: - If you've got your own format files for scan, repl, comp, etc ... consider using (or taking from) the ones included with nmh; if yours are old, they probably don't include the stuff to decode MIME headers properly. Given that my files are circa 80s, this is probably a sound tip, and I'm putting it on my todo list. Thanks! -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] quoted printable. make it stop.
Ken Hornstein k...@pobox.com writes: In the larger sense ... how come you care? Nowadays pretty much everyone can handle a quoted-printable email just fine. I can't. :) Granted, my MH / NMH set-up is probably a decade old by now, but I am using less as my default pager, and only invoke a MIME-complaint reader when I absolutely have to. Only a decade old? You're still a youngun'! :-) ... - If you've got your own format files for scan, repl, comp, etc ... consider using (or taking from) the ones included with nmh; if yours are old, they probably don't include the stuff to decode MIME headers properly. Given that my files are circa 80s, this is probably a sound tip, and I'm putting it on my todo list. Thanks! -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Attach and disposition
Paul Fox p...@foxharp.boston.ma.us writes: so it turns out that if you attach a mail message to your draft, using: Attach: /home/pgf/Mail/inbox/1982 It would be nice to automatically inline text and images. However, we should also provide a UI to override the default. One idea, from apt-get, is to add /disposition to the filename. We then get the dirname of the path. If it's a directory, then disposition refers to a file; otherwise, we use the given disposition. A couple of other Attach questions come to mind: 1. Can you put a space or comma-separated list of files in a single Attach header field? Useful for including several files from a directory (for example, in Emacs Attach: C-u M-! ls *.pdf RET). 2. What happens if the draft has already been MIME-ified? I'm thinking MH-E compatibility here. Jeff, you installed 1.6. Perhaps you can report back. p.s. Sorry for the deluge. Only 425 more messages to go. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] New mhbuild directives
Lyndon Nerenberg lyn...@orthanc.ca writes: #inline ;attribute id (comment) [description] filename This would allow inline attachments to go where they are requested. I squirm at an Inline header field since the attachments will be appended; at least with the /inline modifier I suggested earlier, it's more clearly going to be an attachment. But wait, can we not query the user when sending the message how to disposition each attachment in turn, like we do in MH-E? By default, we offer the most likely case, but the user can override. That would make both my /inline modifier and the Inline header field proposal go away, and #attach/#inline can be implemented in the future (which would suppress the send-time query). Oh darn, it's already the future. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh not using w3n or elinks
Paul Fox p...@foxharp.boston.ma.us writes:
lyndon wrote:
On May 15, 2014, at 7:09, n...@dad.org wrote:
I installed w3n and elinks but nmh is not using them:
Given all the grief people have been experiencing getting HTML
rendering tools to work, perhaps we should consider importing
Plan9's htmlfmt(1) and using it as the default renderer.
this may well be a good idea, but it feels like much of norm's problem
was that the relevant configuration is done at build time. if the
default mhshow-show-text/html entry pointed to a helper script, rather
than to a specific browser, that script could search for and run an
appropriate browser at run-time, probably using the same list we
currently look through at build time.
(how do pre-built nmh packages handle this? simply with dependencies
on the necessary text browsers? if we were to provide our own simple
renderer as lyndon suggests, those dependencies could become
suggestions.)
Debian provides scripts such as sensible-browser (attached) which can
find an appropriate program using either a user-set $BROWSER or one of
the applicable symbolic links gnome-www-browser, x-www-browser, or
www-browser, which are maintained by the package manager. In my case,
the latter points to w3m.
If sensible-browser exists, we should use it.
--
Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
#!/bin/sh
URL=$1
if test -n $BROWSER; then
OLDIFS=$IFS
IFS=:
for i in $BROWSER; do
case $i in
(*sensible-browser*)
printf 'Using sensible-browser in $BROWSER makes no sense.\n' 2
exit 1
;;
(*%s*)
:
;;
(*)
i=$i %s
;;
esac
IFS=$OLDIFS
cmd=$(printf $i\n $URL)
$cmd exit 0
done
printf 'None of the browsers in $BROWSER worked!\n' 2
exit 1
fi
if test -n $DISPLAY; then
if test -n $GNOME_DESKTOP_SESSION_ID; then
if test -x /usr/bin/gnome-www-browser; then
exec /usr/bin/gnome-www-browser ${URL:+$URL}
elif test -x /usr/bin/x-www-browser; then
exec /usr/bin/x-www-browser ${URL:+$URL}
elif test -x /usr/bin/gnome-terminal test -x /usr/bin/www-browser; then
exec /usr/bin/gnome-terminal -e /usr/bin/www-browser ${URL:+\$URL\}
fi
fi
if test -x /usr/bin/x-www-browser; then
exec /usr/bin/x-www-browser ${URL:+$URL}
elif test -x /usr/bin/x-terminal-emulator test -x /usr/bin/www-browser; then
exec /usr/bin/x-terminal-emulator -e /usr/bin/www-browser ${URL:+$URL}
fi
elif test -x /usr/bin/www-browser; then
exec /usr/bin/www-browser ${URL:+$URL}
fi
printf Couldn't find a suitable web browser!\n 2
printf Set the BROWSER environment variable to your desired browser.\n 2
exit 1;
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Message with repeated content
Ken Hornstein k...@pobox.com writes: If not, how can I tell mhshow to ignore the text/html instead of the text/html, when the two contents are identical and mhshow knows that? It's not easy. I've often thought about adding the capability to mhshow to list preferred multipart/alternative MIME types; exmh has that capability and I love it. But it would involve rototilling the whole mess that is the multipart/alternative MIME handling, and I haven't had the energy yet. Yes, that would be a nice feature. MH-E supports it with a mm-discouraged-alternatives variable. I used to use it myself, but as you've noticed, many of the text/plain parts are empty, so now I render the HTML with w3m (in Emacs). -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
Michael Richardson m...@sandelman.ca writes: I encountered a problem with forw -mime, which is used by MH-E. If mh-compose-forward-as-mime-flag is t. It seems that it ignores Draft-Folder. I got caught because I happened to have a (empty) ~/Mail/draft as a directory for reasons I never figured out. mh-e probably could give the explicit -draftfolder option, but it was a surprise. (Maybe I'm mis-diagnosing the problem, twoo) Nope, you are spot-on. And it's not because of the -mime option. And it's not MH-E that is putting the draft in draft, it is forw's handling of the -build option, which is used by MH-E. From forw(1): The -build switch is intended to be used by the Emacs mh-e interface to nmh. It implies -nowhatnowproc. It causes a file mh-dir/draft to be created, contain‐ ing the draft message that would normally be presented to the user for editing. No mail is actually sent. I'm guessing this was done so that MH-E could find the draft that forw created. I can't think of a clean way for MH-E to find the draft if DraftFolder were in use. p.s. Calling in sick again today. Only a month behind and 227 more messages to go. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Future thoughts: better MIME processing
Ken Hornstein k...@pobox.com writes: I manually put them into my Google calendar, so it would be nice to support that. Wow, you parse it out by hand? You're more dedicated than I am. No, not at all. It beats using Microsoft webmail. Speaking of which, Exchange's calendar invitations only have a URL, not an ICS attachment, and often even lack the meeting info so I'm forced to log in and check. Not sure if we can do anything about the latter, but we might be able to recognize a Microsoft invitation and parse out the salient info. Does anyone know if Exchange is capable of emitting ICS attachments and this is just a setting I can ask our calendar admins to tweak? I noticed that if I make sure the file suffix is .ics and I open(1) it on MacOS X, it gets incorporated into Calendar and makes it way into the cloud. So that works out alright; we just need to figure out a way to reply to calendar requests that let you do something sensible. So, we'd want some of way of associating the different calendar actions (add, remove, update) with commands. I recently read about googlecli program that was used to update picasaweb; given the name, I guess it can be used for accessing the calendar as well. It's actually called googlecl; I took a look at it, and it doesn't take an iCalendar file directly, unfortunately. But, we'd be able to parse and pass in the fields directly? -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What about an nmh-1.6-RC1
David Levine levin...@acm.org writes: Bill wrote: But going forward Ken might be open to putting a link on the home page called Snapshots that points to some directory somewhere where the nightly build-bot can deposit a tarball called nmh-snapshot-MMDD.tgz. I expect that wouldn't be worth the effort, both initial and ongoing. And it should be very easy for a user to do this: $ git clone git://git.savannah.nongnu.org/nmh.git $ cd nmh $ docs/contrib/build_nmh -di though on CentOS 6 and maybe others, that requires installing a newer (at least 2.68) autoconf. I don't know what version of autoconf comes with CentOS 7. Never mind, since what I was asking for was an amd64 binary snapshot, but that is probably untenable. Here's why: It took over four weeks for me to do this very easy task on our CentOS 6 system. Fortunately, they had already installed some more modern compilation tools, but not all. 1. Ask IT to install git. Go to CCB. Install. 2. Compile, notice that a library is missing. 3. Ask IT to install library. Go to CCB. Install. 4. Go to 2. At any time, IT could have said no. Game over. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Building nmh 1.6 for Ubuntu 12.04
Ken Hornstein k...@pobox.com writes: ./configure --enable-lockdir=$HOME/var/mail --with-cyrus-sasl --with-tls --prefix $HOME/lib/nmh Hm, I don't think --enable-lockdir did what you think it does. At least appears to work. Hopefully almost nobody will need it now since the default locking algorithm is runtime selectable and the default is no longer dot-locking. As of 1.6? -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
Ken Hornstein k...@pobox.com writes: I'm guessing this was done so that MH-E could find the draft that forw created. I can't think of a clean way for MH-E to find the draft if DraftFolder were in use. Um, yeah ... we added it because you guys asked for it! Well, actually, you guys asked for it in comp: http://lists.nongnu.org/archive/html/nmh-workers/2013-10/msg00013.html It was already there in forw and repl; shouldn't this be a non-problem? If it's busticated, we should fix it (just tested it and it seems to work fine for me). No, it's working perfectly. By now, Michael has run rmdir draft and has completely forgotten about the issue :-). -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhshow complaints
Ken Hornstein k...@pobox.com writes: Errors to stderr, warnings to a log file? Um, what log file would they go to? I'm not sure I like the idea of nmh logging stuff like this via syslog (I doubt anyone would read it, which might not be so bad). Syslog is a thought, but I can't read it at work, so that shouldn't be the only place. How about the content of the Log-Directory profile component, which could be Path/log by default? If there is a library like Java's log4j or logback that supports automatic rotation and compression, that would be nifty. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Building nmh 1.6 for Ubuntu 12.04
Ken Hornstein k...@pobox.com wrote: ./configure --enable-lockdir=$HOME/var/mail --with-cyrus-sasl --with-tls --prefix $HOME/lib/nmh Hm, I don't think --enable-lockdir did what you think it does. At least appears to work. Well, let me ask you ... what do you THINK it does? And does your local delivery agent use $HOME/var/mail as the spool directory? And does it actually do dot-locking? Probably not :-). Hopefully almost nobody will need it now since the default locking algorithm is runtime selectable and the default is no longer dot-locking. As of 1.6? Yes. OK, my path is clear. Thanks! -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Future thoughts: better MIME processing
Ken Hornstein k...@pobox.com writes: Does anyone know if Exchange is capable of emitting ICS attachments and this is just a setting I can ask our calendar admins to tweak? That, I do not know. I'm not part of the Exchange realm, so it may be because the Exchange server in question knows I'm an external user, so it always sends me a text/calendar part. In my Googling, I saw the term external user associated with the ICS attachments. As an internal user, I guess I'm out of luck? -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What about an nmh-1.6-RC1
Ken Hornstein k...@pobox.com writes: It took over four weeks for me to do this very easy task on our CentOS 6 system. Fortunately, they had already installed some more modern compilation tools, but not all. 1. Ask IT to install git. Go to CCB. Install. 2. Compile, notice that a library is missing. 3. Ask IT to install library. Go to CCB. Install. 4. Go to 2. We're in a tough spot here. First, I'm looking over our library dependency list ... it's should be pretty standard. Well, there is that whole Linux lossage about development libraries, but we can't really help that. I mean, if you look at the list, we should only depend on - dbm - termcap/termlib - iconv (optional) - readline (optional) ncurses and libssl (for sasl and tls) come to mind as well. That's pretty basic. I am surprised that you had to ask IT to install that much extra stuff. Keep in mind that CCBs are once a week, so it's not like it was a lot of libraries. Building 1.6 on CentOS 6... ./configure (same as before, but without --enable-lockdir) completes. Found iconv, did not find readline. make succeeds. make check passes. make install works. Smoke test: inc (via MH-E)...check comp (via MH-E)...check send (via MH-E)...check rcvstore...check Damn, good job folks! Now I can go back to not worrying about locking (although I was oblivious that I had to worry about it before). -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhshow complaints
Ken Hornstein k...@pobox.com writes: How about the content of the Log-Directory profile component, which could be Path/log by default? If there is a library like Java's log4j or logback that supports automatic rotation and compression, that would be nifty. I am aware of things like that for server-side components, but I do not see them used for client-side tools. Not sure I think it's appropriate here. You're right. It would be in the same category as the tools that remove the , files. It's easy enough to add another stanza to my logrotate.conf. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What about an nmh-1.6-RC1
heym...@bellsouth.net writes: On 22 July 2014 at 12:31, Bill Wohler woh...@newt.comwrote: Never mind, since what I was asking for was an amd64 binary snapshot, but that is probably untenable. I own an amd64 system, so I thought I'd offer Bill a completed build. Jerry, You are a gentleman, but I got lucky and nmh compiled (and David, make check passed all tests), so I'm no longer in need of a binary distribution. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What about an nmh-1.6-RC1
Ken Hornstein k...@pobox.com writes: Keep in mind that CCBs are once a week, so it's not like it was a lot of libraries. Um, CCB? Don't know what that is. Thought you worked for the government :-). CCB - Change Control Board. In our IT's case, it's a weekly meeting where a board approves (or more often the case) disapprove of requested packages. Another example is the KOSMA Translator CCB. The KOSMA Translator is the software I write that runs on SOFIA, and the CCB approves of document and software version updates. Everything I've discussed has probably become more acute after the Challenger and Columbia disasters, and the stolen unencrypted laptop with Personally Identifiable Information (PII). But we digress. http://www.darkreading.com/attacks-and-breaches/stolen-nasa-laptop-had-unencrypted-employee-data/d/d-id/1107402? -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] switching from thunderbird to nmh
Brenda J. Butler b...@credil.org writes: Ken, David, Norm, On 09/20/2013 02:02 PM, n...@dad.org wrote: Ken Hornstein k...@pobox.com writes: I'd like to switch to using nmh for email handling. I've been using thunderbird for the last few years. Great! Glad to get a new user! If you don't mind me asking ... how come you decided to switch? We get a lot of people going the other way, so I am curious why you decided to go against the tide. Not that I'm complaining! I'm a programmer. I work with plain-text files and plain-text editors on the command line. I used Thunderbird at my new job (four years ago) because it was most convenient at the time, but now I want a real mail client : -) Once I'm familiar with nmh, I will probably move to using it in emacs. I am so late to the party that the champagne is long gone and the bottles have been recycled and reused several times over. But if you're already a fan of Emacs, you'll find MH-E to your liking. Try M-x mh-rmail. See http://mh-e.sourceforge.net/, and link to The MH-E Manual in particular. Hope you are still using nmh! I understand the nmh mail format is a little different from mbox format or maildir format. Is there any conversion utility out there? I've searched but only found utilities for people going the other way. So, it's not obvious ... but the inc utility does that. It will take a mbox file (or, I belive, a Maildir dropbox if you have a new enough version) and incorporate it into a nmh folder. Great! Alternatively, a pointer to the documentation of what the nmh format actually is would be helpful. I haven't found a concise description yet. The man page mh-mail(5) should describe that. Basically, each message is in it's own file, each folder is a directory. Messages have filenames that are all numbers. Each message is pretty much straight RFC 2822 format, except using Unix newline conventions. Although looking at the man page now, I see that it's a bit out of date; for example, messages nowadays are not limited to 7-bit ASCII in the body. Similar to maildir, maybe. I'm a bit less familiar with maildir. Would I be able to read the Thunderbird files and write them out as nmh ones? No point keeping the old format around. Also, I need nmh to get email by imap. How can I configure that? Or am I supposed to use fetchmail for that? _If_ your IMAP server also supports POP, inc can incorporate messages from that. Otherwise, fetchmail is probably the best solution. Ok, fetchmail it is. For most purposes, especially to get started, you don't need to know most of what's in mh-mail(5). It might be added that if you are using a Unix like system, such as Linux, BSD, Macintosh, or Cgywin, then you can operate on nmh messages just as though they are Unix files -- which indeed they are -- and using Unix commands such mv, ls and cp. And you can inspect and modify them using your favorite text editor. Yep, looking forward to it. I'm doing this in my spare time (of which I have negative quantities) so it will take a while. Thanks again for your quick, helpful and friendly reponses. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Quoting for test commands
Ralph Corderoy ra...@inputplus.co.uk writes:
Hi Ken,
I'm having a heck of a time figuring out how to do shell quoting right
with command substitution.
As Lyndon hinted, you need the shell to do an extra level of
interpretation.
(Each word interpreted as an individual argument). I've played
around with single quotes, double quotes, backslashes, and clearly I'm
missing something.
Yes, it can't be done like that.
$ cat ken
#! /bin/sh
run_test() {
actual_output=`$1 21`
echo actual_output: $actual_output
}
run_test2() {
actual_output=`eval $1 21`
echo actual_output: $actual_output
}
fmttest() {
shift 3
printf '%s\n' $@
}
fmttest -raw -format '%(unquote)' Mr. Foo Bar
run_test 'fmttest -raw -format %(unquote) Mr. Foo Bar'
run_test 'eval fmttest -raw -format %(unquote) Mr. Foo Bar'
run_test2 'fmttest -raw -format %(unquote) Mr. Foo Bar'
$
$ ./ken
Mr. Foo Bar
actual_output: Mr. Foo Bar
Hey, I just had this very same problem in one of my scripts.
actual_output: Mr. Foo Bar
Thanks very much for showing us the way! I thought I had tried eval, but
will try again with this example.
actual_output: Mr. Foo Bar
$
In your run_test, $1 is being replaced with your whole fmttest command,
including all its arguments, but double-quote processing doesn't then
occur; it already has and you've missed the boat. You need instead to
be prepared for two levels of interpretation and request another with
eval. Altering run_test to have the eval, like run_test2, might not be
the correct fix though because some of your calls might not expect that
extra level and need additional quoting. The alternative is to add the
eval to the run_test call just when it's needed, like my third example.
Cheers, Ralph.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
--
Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Thank you
n...@dad.org writes: I will shortly have completed my 82nd trip around the sun. And I am grateful to you, along with a cast of others, that I have been able to share the MH bus with you for 30 of those trips. Recently, three people who were important to me: Tora Bickson, my esteemed and beloved colleague, my sister and Willis Ware, my friend and ex-boss all died, in rapid succession, and before I had a chance to thank them for all they had done for me and meant to me. So, before I leave, I want to thank all who have participated in MH, NMH, and their off shoots, as designers, implementers, users and critics for their part in what I regard as the signal accomplishment of my career -- a career not without other accomplishments, http://en.wikipedia.org/wiki/Norman_Shapiro. Thank you all so much. Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] tmp file cleanup
David Levine levin...@acm.org writes: I expect that there are: anything that's relative to the MH Path is susceptible. But again, there may be users out there who depend on it, and moreso than $TMP. I'm all for backwards compatibility, but in this case I'm with Lyndon: I wouldn't even hesitate chucking this over the side. I hate it when upgrades break my configuration. And I know I'm not the only one :-) I'll look into deprecating it (.. in a folder name). I don't see a big rush to yank it, given the personal extent of nmh. Isn't making a relative MHTMPDIR relative to MH Path just as much a change as disallowing relative paths? Security breaches should be fixed as soon as they are found. Document in the release notes. Exit with an error. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild changes merged to master
Ken Hornstein k...@pobox.com writes: Now the attach command inserts an Attach header, and send always runs mhbuild (with the -auto flag). If mhbuild sees an Attach header, it will attach that file to the message. You can also do a mime command at whatnow if you want to insert mhbuild directives; Attach headers will still be processed, so you can see what it has decided to do. I assume that you can run attach multiple times, or add multiple Attach header fields, and all listed attachments will be attached? -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What about an nmh-1.6-RC1
n...@dad.org writes: It looks like, when it finally comes out, nmh-1.6 will represent a revolutionary change it the way nmh deals with MIME. But, in the nearly two years since nmh-1.5, there have been many other important (at least important to me) improvements. For example, to sortm, mhbuld, mhstore, and message sequencing, that I'm itching to get ahold of. Even the Mime related stuff already there will be a big improvement. So I wonder if I could prevail upon somebody to create and release an nmh-1.6-RC1. I can't -- way about my pay grade. By now, nmh 1.6 is out and everybody is happy. But going forward Ken might be open to putting a link on the home page called Snapshots that points to some directory somewhere where the nightly build-bot can deposit a tarball called nmh-snapshot-MMDD.tgz. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.6 Release Engineering
Lyndon Nerenberg lyn...@orthanc.ca writes: On Mar 7, 2014, at 5:13 PM, Ken Hornstein k...@pobox.com wrote: Well ... we were all over the place, part of that was the limitations imposed by CVS branch naming before. I know. I have dealt with them all over the years :-P (RCS, CVS, svn, git, p4, hg, ...) I just want a bit of consistency. Something that people can look at 20 years down the road and (hopefully) immediately understand. I like consistency as much as anybody, but in this case, why make 20 years of developers suffer? On all of my projects that I switched to git, I INSTANTLY got rid of the silly CVS restriction of having - and .s in tags with no reservations whatsoever. I use git tag -n with a small enough number that keeps me from seeing the hideous old tags. I'm with Ken. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] New mh-mime(7) man page
Ken Hornstein k...@pobox.com writes: s/conjuction/conjunction/. I'm more used to the convention where the first time a command is mentioned it is by man page, e.g. mhlist(1) will display Afterwards, it's just mhlist. Then there is no need to say See the... man page as the reference, including section, has already been given. See the send(1) man page for details... Likewise, it's See send(1) for details. The (1) convention means the reader knows it's a man page. Fair enough, I went back and forth on that. There is not a lot of consistency I had to go on, but I think you're right and I'll change that. However, what do people think about the first time a command is mentioned to give a man page reference? I think I'd agree with Ralph. It is done that way in the bash man page. SEE ALSO nmh(7), mhbuild(1), comp(1), repl(1), whatnow(1), mh-format(5) Missing full stop. No, that list is not a sentence nor other form that requires a period. If you are citing a book or article, then you would use a full stop per the Chicago Manual of Style, for example. See the ssh man page that shows both forms in a single SEE ALSO section. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Future thoughts: better MIME processing
Ken Hornstein k...@pobox.com writes: Sometimes I have a hard time dealing with abstract ideas, so let's deal with the specific case I've had to do a lot lately: Calendar requests, which oddly enough I've had to respond a lot of them lately. I manually put them into my Google calendar, so it would be nice to support that. So, we'd want some of way of associating the different calendar actions (add, remove, update) with commands. I recently read about googlecli program that was used to update picasaweb; given the name, I guess it can be used for accessing the calendar as well. p.s. 800 messages down, 800 more to go. Come to think of it, the last time I caught up on nmh mail was when I was home sick from work with a cold, like today :-). You guys are awesome, keep up the great work and inspire us MH-E folks to get caught up! -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhshow display bug
Paul Fox p...@foxharp.boston.ma.us writes: i currently have this in my mh_profile: mhshow-charset-iso-8859-1: %s | /usr/bin/iconv -f ISO-8859-1 -t UTF-8 | less I've been seeing iconv a few times, and so I looked it up. Very cool. In the iconv command, you can append a //TRANSLIT to the target encoding to try to substitute some reasonable characters for characters that are not recognized there. It appears that iconv(3) returns EILSEQ in this case. Do we have another mechanism to implement //TRANSLIT? Seems useful. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Building nmh 1.6 for Ubuntu 12.04
Ken Hornstein k...@pobox.com writes: I'd like to test this out with mh-e, but am sorta busy. Can anyone recommend configure options I should use that are closest to nmh-1.3 as distributed with 12.04? Wow, 1.3? Whew. We got rid of a LOT of the configuration options along the way; that was basically a result of either including support for something, or getting rid of code no one used. For my testing, here's my configure line: % ./configure --with-cyrus-sasl --with-tls Hi Jeff, That's basically what I used to build 1.5 on my Kepler machine which is now running CentOS with no nmh in their repository, not even 1.3 :-(. I got permission from IT to compile it, fortunately. My full command was this, since I didn't have permission in the spool directory (for locking) nor /usr/local: ./configure --enable-lockdir=$HOME/var/mail --with-cyrus-sasl --with-tls --prefix $HOME/lib/nmh $HOME/var/mail is my MH Path, by the way. This seems to have served me well. David's build_mh script looks neat. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhshow complaints
Ken Hornstein k...@pobox.com writes: Sigh. I'll let you fight that one out with the greybeards here; there is a constant battle between the deal with it camp and the a single misplaced semicolon should cause a core dump and immediately execute rm -rf /. Okay, perhaps I'm exaggerating the last one. I will note that a semicolon at the end of the parameter list does violate the BNF for MIME parameters, but it strikes me as something that really doesn't harm anything (and it's not like there's really any confusion about what to do). Errors to stderr, warnings to a log file? -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Help with SASL/TLS
Ken Hornstein k...@pobox.com wrote: (tls-decrypted) = 250-AUTH GSSAPI NTLM LOGIN Do you want to use GSSAPI (really Kerberos), NTLM, or LOGIN? Presumably you'd know if you were doing Kerberos; if you are using Kerberos, you'd be running kinit and _not_ be putting a password in your .netrc. That's failing because you don't have a Kerberos credential cache. If you're trying to do NTLM, then I don't know what the client-side support for that looks like. If you're trying to do LOGIN (which I suspect is most likely), then the problem is that the cyrus-sasl library is picking out the mechanism to use based on what the server is saying it prefers, which is (in order of most preferred to least preferred) GSSAPI, then NTLM, then LOGIN. So if you want to force a particular mechanism, you need to add an appropriate -saslmech option (in this case, -saslmech LOGIN). Thank you! Adding -saslmech LOGIN worked like a charm. That description would be a welcome addition to the currently terse reference to -saslmech in the manual. --Ken -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
Ken Hornstein k...@pobox.com writes: mh_profile seems like a good place for this. There coudl also potentially be a cookbook somewhere on extending nmh, with references to this, Jerry's book, contribs, GUIs, etc. Jerry's book is open source, and can be modified. Sigh .. so much documentation to do, so little time. I'd be happy to give folks write permission to http://rand-mh.sourceforge.net/book/ if they want to improve it. I'd run it past Jerry first, of course, but I imagine he'd encourage it as well. Just drop me and Jerry Peek jp...@jpeek.com a line with your proposal. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context
Ken Hornstein k...@pobox.com writes: See, this is where we run into two competing ideas as to what MH's original innovation is. Do people think it's: 1) The message store (1 file per message), instead of one file for the whole store. 2) Individual commands to perform message operations, as opposed to traditional monolithic MUAs. Both. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Should I learn nmh or GNU mailutils?
about nmh please don't hesitate to post them here. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Front-end census
otah...@gmx.ca writes: First of all, thanks to all of you guys on this mailing list. I am learning a lot. I hope you will excuse my many questions. I was happy to find out, from Ken's last email, that there is yet another front-end for nmh whose existence I did not know of: MH-V by Steve Rader. I have just downloaded it. This new discovery raises the question: how many front-ends are there? The ones I came across so far (though I have not ried them yet) are: 1) xmh (obsolete, I assume) 2) MH-E If you're already using Emacs, MH-E is a clear winner :-). I'd like to point out that I first started using MH-E *before* I used Emacs as an editor. A big advantage of MH-E over the GUIs is that it's easier and faster to read email over the Internet. 3) exmh 4) MH-V Any other? Could you please give a brief assesment of each, based on your experience? Which one would be the best bet for a newbie? (I gather that most people nowadays use either MH-E or exmh.) Please share your views. Every bit of info will help, as I also have to decide whether to (partially) use Claws Mail or to go nmh/mailutils all the way, with the help of a front-end. Thanks Otto ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Smart enough to use nmh
n...@dad.org writes: You wrote: After all, if a person is smart enough to use nmh, they're smart enough to figure out how to fix a header line, right? I hope and believe that a person does not have to be unusually smart to to use nmh. I agree. Back when I was at SRI in the 80s, our secretaries used MH. Even though they were smart, they didn't know anything about mail headers. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Threads
Ralph Corderoy ra...@inputplus.co.uk writes: Hi Bill, 9216 -03/25 [d.henman ] unexpected error mesageMH-E Version 8.3.1 Platform: Cygwin #1 T 9217 03/25 [Zeus Panchenko ] Re: unexpected error mesage-BEGIN PGP SIGNED MESSAGE- ... I find that quite clutter-ful, with the []/ being two characters to indicate one thing, and the identical subject repeated. http://www.davep.org/mutt/screenshots/index.png is an example of mutt's presentation. (Like Ken, I liked trn's little context tree when viewing a single Usenet article.) ... How does the Mutt presentation handle the Subject: New subject (was: old subject) case? http://i.imgur.com/vK31Pml.png shows the subject changing at 2407. As might be expected, the subject is only omitted if it's the same as its parent's. Gotcha, thanks! Still prefer the MH-E way (perhaps without the []/ characters) as well as the folded gnus way. Happy to let the implementer have the last word though :-). Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Responding to calendar requests
Ken Hornstein k...@pobox.com writes: is - if you get a message with a calendar invitation in it, what would you, as a user, _like_ to happen? Sometimes you want to add text to your reply, and sometimes you don't, and sometimes you want to accept or decline without notifications at all. I'd therefore like to be able to say something like cal [-accept|-decline|-maybe] [-edit|-noedit] [-notify|-nonotify] However, MH doesn't natively handle any MIME parts, does it? If not, we don't want to start now. However, we can pass the job on to an external (contrib) program. Then create an .mh_profile alias to make use of it. At least it would be built-in, if not native. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Does maildrop work correctly with nmh?
One thing I have my todo list is to consider sieve as a replacement to procmail. It would be great to hear from anyone who is actually using sieve. Martin McCormick mar...@dc.cis.okstate.edu writes: I certainly appreciate the suggestions and discussion this question caused. I have given up for now. The real problem I was trying to solve is that when procmail is determining what to do with a particular message, all the straight-forward text-based recipes are worthless when what blows through is a spew of base64 or html unless you are looking for just one word and it is unique enough not to accidentally be part of html code. Oh well. It was an interesting exercise. Thanks to all. Martin McCormick ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Threads
Ralph Corderoy ra...@inputplus.co.uk writes: Hi Bill, 9216 -03/25 [d.henman ] unexpected error mesageMH-E Version 8.3.1 Platform: Cygwin #1 T 9217 03/25 [Zeus Panchenko ] Re: unexpected error mesage-BEGIN PGP SIGNED MESSAGE- ... I find that quite clutter-ful, with the []/ being two characters to indicate one thing, and the identical subject repeated. http://www.davep.org/mutt/screenshots/index.png is an example of mutt's presentation. (Like Ken, I liked trn's little context tree when viewing a single Usenet article.) I can't argue with you about the []/ characters. As a user, I don't really care about the subtle difference between them. I think Satyaki (who implemented it) did. Gnus also repeats the subjects, but collapses threads into a single line followed by an ellipsis until you start reading the first message. How does the Mutt presentation handle the Subject: New subject (was: old subject) case? -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Threads
Ralph Corderoy ra...@inputplus.co.uk writes: Hi Bill, 9216 -03/25 [d.henman ] unexpected error mesageMH-E Version 8.3.1 Platform: Cygwin #1 T 9217 03/25 [Zeus Panchenko ] Re: unexpected error mesage-BEGIN PGP SIGNED MESSAGE- ... I find that quite clutter-ful, with the []/ being two characters to indicate one thing, and the identical subject repeated. http://www.davep.org/mutt/screenshots/index.png is an example of mutt's presentation. (Like Ken, I liked trn's little context tree when viewing a single Usenet article.) Forgot to mention that I prefer the repeated subjects. The mutt presentation forces you to look away from your current message to see the subject. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Threads
Ken Hornstein k...@pobox.com writes: In fact, the whole concept of 'threads' is something I would like to keep outside of the base toolset. It's too complex to leave outside of nmh's knowledge. I'd like to pick the parents of these messages, all ancestors, the immediate descendants, or all descendants, or all messages in the same thread, ideally combined with pick's, or its replacement's, other options. Right, I'm kinda with you there; nmh needs to do something, but I'm not sure what yet. In my mind there are three possible things people mean when they talk about threading: - The actual implementation of building the threading information. There is some conflict here about how when it's done, how it's stored, but I think there isn't too much disagreement on what needs to be done. I hadn't seen jwz's writeup about that, but it looks pretty much exactly what we need to do. That's relatively easy (well, straightforward, at least). However, I think the issue with us isn't CPU time, it's io-ops. By the way, MH-E also implements the model described by http://www.jwz.org/doc/threading.html that Ralph mentioned. Looks like the RFC is http://tools.ietf.org/html/rfc5256. - The user interface: how do we give threading information to users? Have mhl(1) display a trn-style message tree? (which I admit that I was always partial to?). Is it only via pick? Indent subject lines in scan? (which to me throws away some of the useful information). Here's what it looks like in MH-E. I found some documentation on the difference between angle and square brackets: ;; In the presentation buffer, children messages are shown indented ;; with either [ ] or around them. Square brackets ([ ]) denote ;; that the algorithm can point out some headers which when taken ;; together implies that the unindented message is an ancestor of the ;; indented message. If no such proof exists then angles ( ) are ;; used. 9216 -03/25 [d.henman ] unexpected error mesageMH-E Version 8.3.1 Platform: Cygwin #1 T 9217 03/25 [Zeus Panchenko ] Re: unexpected error mesage-BEGIN PGP SIGNED MESSAGE- 9219 03/26 [To:d.henman ] Re: unexpected error mesaged.henman dhen...@gmail.com wrote 9222 -03/27 [Zeus Panchenko ] Re: unexpected error mesageBill Wohler woh...@newt.com wr 9220 -03/28 [d.henman ] Re: unexpected error mesageSame here the scan: bad mes 9223 03/30 [To:d.henman ] Re: unexpected error mesageI'm a little confused. Are y 9226 -03/31 [Zeus Panchenko ] Re: unexpected error mesage=2DBEGIN PGP SIGNED ME 9225 03/31 [To:Zeus Panchen] Re: unexpected error mesageIt's interesting that th 9224 03/30 [To:d.henman ] Re: unexpected error mesaged.henman dhen...@gmail.com 9228 03/31 [To:d.henman ] Re: unexpected error mesaged.henman dhen...@gmail.co 9229 04/01 [d.henman ] Re: unexpected error mesageI have just written to M 9221 03/30 [To:Zeus Panchen] Re: unexpected error mesageHmmm, how about inc from the 9227 t03/31 [d.henman ] Re: unexpected error mesage$ inc returns with $? = 0 an 9230 -03/31 Sergey Poznyako Re: unexpected error mesageHello, I'm not subscribed to the l 9231 03/31 [To:Sergey Pozny] Re: unexpected error mesageSergey Poznyakoff g...@gnu.org. 9232 -04/01 [Sergey Poznyako] Re: unexpected error mesageHi Bill! Yes. It seems you'v 9233 04/01 [To:Sergey Pozny] Re: unexpected error mesageSergey Poznyakoff gray@gnu. 9234 -04/03 [Sergey Poznyako] Re: unexpected error mesageHello, On March 31, Sergey Poz 9244 04/06 [To:Sergey Pozny] Re: unexpected error mesageSergey Poznyakoff gray@gnu. 9247 -04/07 [d.henman ] Re: unexpected error mesageBill, et al, I installe Thus, scan -thread could show something like this. - (Optional) How do users navigate or select messages across a thread? One thing I always liked about the trn display was that the messages were numbered and you could pick them via the number in the thread display. We can't really do that, but something similar would be nice. In MH-E, n (next) reads the messgaes in the order shown above. It appears to be a depth-first traversal. Thus, next -thread could show the messages in the order shown above. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
Lyndon Nerenberg lyn...@orthanc.ca writes: On 2013-04-03, at 5:25 AM, Paul Fox wrote: $ scan unseen ...notice that third-from-end message is spam... $ refile unseen_3 +spam I don't think '_' is a very good choice. It's too commonly used as a word separator in text strings. Why not use the Git convention: unseen~3 ? At first I was going to go along, but perhaps we want to reserve the git terminology in case we do threading which would be a closer analogy (parent relationship). -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
Lyndon Nerenberg lyn...@orthanc.ca wrote: On 2013-04-06, at 4:28 PM, Bill Wohler wrote: At first I was going to go along, but perhaps we want to reserve the git terminology in case we do threading which would be a closer analogy (parent relationship). Wouldn't threading be handled by external scripts? This sounds like something I would do by generating a list of message-id and references headers, then doing a tsort and feeding the whole mess back into scan/show. That's certainly what we do in MH-E. We have talked about threading on this forum in the past so I hope it's somewhere on The List. I don't think it's reasonable to expect users to have to write such scripts themselves to have threading. Actually, now that I think of it, since threading is usually a toggle, we can use ~ and ^ whether threading is enabled or not. If it's enabled, these characters operate upon the thread; if not, they operate on previous messages. I agree with you; I definitely prefer these over the underscore which seems more like a word separator than an operator. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
Lyndon Nerenberg lyn...@orthanc.ca wrote: On 2013-04-06, at 6:13 PM, Bill Wohler wrote: Actually, now that I think of it, since threading is usually a toggle, we can use ~ and ^ whether threading is enabled or not. If it's enabled, these characters operate upon the thread; if not, they operate on previous messages. But how do you set or track state on a modeless set of command-line tools? Add a profile entry to the context file? If not, I would reserve ^ and ~ to refer to the message's ancestor and use a different symbol for the relative message number. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Threads
valdis.kletni...@vt.edu writes: On Sat, 06 Apr 2013 16:38:22 -0700, Lyndon Nerenberg said: In fact, the whole concept of 'threads' is something I would like to keep outside of the base toolset. The reason being there is no single definition of what a 'thread' is, and even when you can come up with a definition, it's almost always context sensitive. I have never found an MUA that can come even close to expressing the sort of detail I want when dealing with threads. exmh apparently has at least some thread support. However, I don't use it because it has completely horrendous perfornamce characteristics, since the folder I want to use it the most has thousands of messages and hundres more each day. As a result, it has to read all the messages of interest so it can find all the In-Reply-To and References: headers. MH-E limits threading to the current view and doesn't thread the folder by default if the view is larger than a configurable amount. Threading the last couple of hundred of messages is sufficient and fast. gnus is fast too, but it limits its threading to the current view as well. This begs the question as to what the current view in MH is. You'd really want to have a cheap incremental method of adding incoming messages to a thread database, similar to how rcvstore currently updates the unseen sequence. Or a simple per-folder dot file. For example, in MH-E, a search index called .mhe_index serves as a mini-database for the search result. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
n...@dad.org writes: Ken Hornstein k...@pobox.com writes: Hm. I'm torn. So, it looks like it's okay in terms of syntax; _ is not a valid character in a sequence. But what are the semantics if 'name' refers to more than one message? Then name+n is the nth message of name; name_n is the nth to last message of name.(1 based ordinals. That is, name+1 is the first message of name and name_1 is the last message of name). Hey Norm, how is this useful? I can't see anyone manually referring to the nth item in a sequence on the command line. The point of a sequence is that you don't have to know the constituents. Maybe you have a use case. If this is for programmatic use, it seems that something like for i in $(mark -list -sequence cur | cut -f 1 -d --complement); do scan $i; done would be clearer. Saaay, it just occurred to me. Maybe we should adopt MH-E's syntax. Norm, please check out MH-E ranges [1]. While it's not identical to your specification, it sure is nifty for MH-E users. If this works for you, maybe applying the same syntax to nmh would mean that many more users would be more familiar with the syntax than with _. http://mh-e.sourceforge.net/manual/html/Ranges.html -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] --prefix=/usr/local issues
Lyndon Nerenberg lyn...@orthanc.ca writes:
On 2013-03-18, at 7:36 PM, belg4...@pthbb.org wrote:
I configured and compiled with --prefix /usr/local
and things worked fine. Unfortunately, the whatnow
prompt reports the following when I try to send:
unable to exec /usr/local/nmh/lib/post: No such file or directory
Unrelated, but this reminds me of another nit I have with --prefix.
Currently we install the etc stuff into ${prefix}/etc, which spams
/usr/local/etc pretty hard when faced with --prefix=/usr/local.
Personally, I'm not a fan of the /usr/local/nmh default prefix, and
would prefer to see it changed to /usr/local, with the configdir stuff
pushed down a level to $prefix/etc/nmh. (And libexec stuff in
$prefix/libexec/nmh, etc) I think most people expect things to install
this way, and just show up in their $PATH (which, presumably, already
has /usr/local/bin in place).
I don't like clutter in the /usr/local namespace.
If nmh is installed in the main system, we might see /etc/nmh,
/usr/bin/mh, and /usr/lib/mh, and it should be similar in /usr/local.
However, /opt is not organized like /usr/local, so setting prefix to
/opt might be an interesting alternative.
--
Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Pasing stdin to inc -file ?
valdis.kletni...@vt.edu writes: On Sat, 16 Feb 2013 15:30:55 -0700, Joel Uckelman said: The second colon tells procmail to use a lockfile for this recipe, and the path after that is the lockfile name. Messages can come in any time; the lockfile ensures that two runs of rcvstore don't step on each other's toes. And the exact gotcha involved, from 'nman rcvstore': BUGS If you use the Unseen-Sequence profile entry, rcvstore could try to update the context while another nmh process is also trying to do so. This can cause the context to become corrupted. To avoid this, do not use rcvstore if you use the Unseen-Sequence profile entry. What it doesn't mention is that the resulting train wreck can mangle other sequences in the .mh_seq file as well. Also, should we change that text to say do not use rcvstore without an external locking mechanism'? It's perfectly save to use it from procmail with unseen sequences as long as procmail does the locking for you, so there's no need to scare off users. Has anyone ever experienced this theoretical corruption? I haven't. I use procmail's locking, but then other nmh programs don't use that same locking mechanism. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] showing application/octet-stream attachments that should be text/plain
Ken Hornstein k...@pobox.com writes: I find it happens quite often that I receive an e-mail where someone has attached something that is likely to be plain text (such as a diff) but their mail program has marked it as application/octet-stream. Viewing such attachments ends up being a bit of a hassle because they need to be stored in a file first. Does anyone know a trick for quickly viewing such attachments? Hm. Nothing comes to mind offhand. But it does suggest to me that we need an extra switch or two to mhshow to override it's default idea of how to handle a particular content type (or part). Yeah, it's certainly something you don't want to hard code since the majority of my application/octet-stream attachments are either PDF files or Microsoft Office documents, not text. In MH-E, I use C-u attachment number K e RET program RET to view a particular attachment. That would indicate that you might want to be able to enter the program as you're reading the email. That might be easier than specifying the program for the particular attachment at the command line. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] RFC 6854 on Update to Internet Message Format to Allow Group Syntax in the From: and Sender: Header Fields
Lyndon Nerenberg lyn...@orthanc.ca writes: Well isn't this just special ... So, how are you supposed to reply to those messages? Especially if the recipients have been specified with group syntax as well? The RFC and IETF mailing lists should have the questions to these and other questions. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] deprecate msh(1)
David Levine levin...@acm.org writes: Hi, Unless there's objection, I'm going to deprecate msh(1). No objection. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] m_getfld branch merged
David Levine levin...@acm.org writes: Hi, The m_getfld() rewrite is finished and the branch merged to master. Reviews welcome: I've been out of the C loop for too long to review, but I can send along a big thanks! -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The function, void admonish (char *what, char *fmt, ...)
David Levine david.lev...@combinenet.com writes: Paul F. wrote: not all MH users are programmers. i like file modi[fi]cation time better than mtime. Agreed. Seconded. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The function, void admonish (char *what, char *fmt, ...)
Ralph Corderoy ra...@inputplus.co.uk writes: Hi David, sortm: can't parse date field in message 66, using file mod time, continuing... sortm: 66: resent-date not understood; will use mtime continuing... seems superfluous. Agreed. I like the more specific message as amended by Ralph. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] m_getfld branch merged
Ken Hornstein k...@pobox.com writes: I guess my larger point is that it's not always obvious to other people how we allocate our personal time; there are a lot of factors in play. But I personally feel as long as we're improving nmh, nothing is wasted. Not to mention 10s or 100s of messages in your gmane.mail.nmh.devel folder when you get to it to reassure you that nmh is still alive and kicking. Thanks all! -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] inc, slocal, procmail, ...
chad yand...@mit.edu writes: On 08 Jan 2013, at 11:30, Ken Hornstein k...@pobox.com wrote: One thing to keep in mind when thinking about that line is that inc is typically synchronous, where our use of fetchmail/procmail (or whatever) is asynchronous. By the time we step up to MH, everything is already in a folder or in the local maildrop ready for +inbox (or already in +inbox). I don't want to have to wait for inc to go to my remote server. I just timed inc ... to go to my POP server, which included Kerberos authentication (4 extra round trips), download a small test message (session was encrypted), write it out (to a network filesystem, no less), and exit, it took: 0.04 real 0.01 user 0.00 sys Are you really THAT impatient, Bill? :-) Ok, fine ... going across the global internet for all that will be a lot worse. But most of the time I never notice it unless there's a problem. Heh heh. That's pretty impressive. Bill has been known to use a satellite modem from a boat in the Pacific, so he might care about network latency more than most. :-) :-). We just spent a week on a boat in the Caribbean (diving on the Cayman Islands) and wireless Internet was expected. Not so just ten years ago. But these days my network latency isn't that bad. Is there still interest in offline IMAP support for NMH? That was eventually a killer for me. ~Chad ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Garbage collection
Note that we are discussing removing orthogonal programs from MH only to clarify the focus of the program and to simply the build environment. We are not discussing killing anything. If there is still interest, it would be easy enough to package these items separately. Mike O'Dell m...@ccr.org writes: I still use slocal because it does what I need easily and simply. procmail is hardly a poster child for great software UI design or implementation, and I would look very dimly upon the prospect of re-implementing a many-hundred-line .maildelivery file as the goo required by procmail. as for the assertion that it's OK to kill-off slocal because the capability can be supplied by some other program, that assertion applies with equal validity to the entirety of nmh. cheers, -mo On 1/4/13 2:30 PM, Bill Wohler wrote: Ken Hornstein k...@pobox.com writes: Greetings all, I'm been thinking about Markus's master's thesis, and it's motivated me to remove some old crud sitting around in nmh. I'd like to get some feedback about it. I've started reading it too, and thus far I do not have any objections to the clean-ups. - Remove ALL the traces of UUCP support. I'm assuming that the only response here will be, nmh still has UUCP support?. Well, it kinda does, but it's been bitrotting for a long time. I want to remove EVERYTHING that has uucp in the name. FWIW, I see that the UUCP Mapping project officially shut down in November of 2000 (I'm honestly surprised that it lasted that long). Also, it looks like to me that no RFC describes how UUCP addresses are supposed to be formatted, so it's not even clear to me how a correct address parser are supposed to handle those things. Agreed. - Remove dbm/ndbm dependency. The ONLY reason nmh has a dependency on a db library is for duplicate suppression in slocal; if slocal finds a duplicate Message-ID, it discards it. I didn't think getting a dbm library was so hard, but apparantly it is under Linux; the autoconf stuff for this is a giant mess. I'm wondering ... do people actually use this functionality? I'm thinking the days of using slocal in your .forward file have slowly been coming to an end. At the very least we should make this functionality optional ... that would make things easier for Paul Fox, if no one else :-) I use duplicate message suppression, but I use procmail to do that. I think Markus suggests that we remove the orthogonal slocal program entirely. I have to agree since I've been using procmail for years, and may switch to sieve in the future. We can easily create a separate slocal project for the slocal die-hards and remove an unused portion of MH (for many of us). - Remove rcvtty completely. This works in conjunction with slocal or procmail; it broadcasts new message summaries to your terminal. Because of OpenBSD unpleasantness it's challenging to get it working there, and it really occurs to me that it's the wrong thing to be doing. Agreed. It is also orthogonal to the MH UI and is provided by other methods. If there is still support out there, we can split off another project. - Content-MD5 support. I will admit that I haven't done a complete survey, but from what I've seen nmh is the only MUA still generating a Content-MD5 header in MIME messages. This means we need a MD5 implementation, and a test for it. This has caused portability problems in the past, and I'm wondering if this is useful at all; I get the feeling that we're the only ones to support it. See Markus's thesis for a more complete survey. $ grep -i content-md5 mh-e/*.el $ Agreed. - EBCDIC safe encoding. Forces quoted-printable encoding if an EBCDIC unsafe character is seen (see uip/mhbuildsbr.c:ebcdicsafe[]). We don't care about this, right? Agreed. Happy New Year, everyone! --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] inc, slocal, procmail, ...
Ken Hornstein k...@pobox.com writes: 1) Local delivery from the MTA 2) Fetch mail from the local maildrop 3) Fetch mail from POP, IMAP and all the other methods supported by fetchmail 4) Accept mail from a third party program (i.e. be an mda for fetchmail) I think this is all great; we just need someone to write the code :-/ At the other extreme, what's wrong with inc(1) handling nothing but 2 above? The other things are others' problems that they can concentrate on and do well. So I don't quite know where the line should be drawn. One thing to keep in mind when thinking about that line is that inc is typically synchronous, where our use of fetchmail/procmail (or whatever) is asynchronous. By the time we step up to MH, everything is already in a folder or in the local maildrop ready for +inbox (or already in +inbox). I don't want to have to wait for inc to go to my remote server. But here's my feelings on the topic. - nmh should offer basic funtionality out of the box; adding other packages can add functionality, but you should be able to do the basic job of sending and receiving email without them. - The first two ways of receiving email are fast becoming extremely rare. - Saying, Hey, we're an MUA that you should try out, except that we can't actually RECEIVE email, you have to use this third-party program, seems kinda wrong to me. - We don't have to do everything that fetchmail does; I'm happy with a basic subset that most other MUAs support. Obviously this a issue on which reasonable people can disagree. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Garbage collection
Ken Hornstein k...@pobox.com writes: Greetings all, I'm been thinking about Markus's master's thesis, and it's motivated me to remove some old crud sitting around in nmh. I'd like to get some feedback about it. I've started reading it too, and thus far I do not have any objections to the clean-ups. - Remove ALL the traces of UUCP support. I'm assuming that the only response here will be, nmh still has UUCP support?. Well, it kinda does, but it's been bitrotting for a long time. I want to remove EVERYTHING that has uucp in the name. FWIW, I see that the UUCP Mapping project officially shut down in November of 2000 (I'm honestly surprised that it lasted that long). Also, it looks like to me that no RFC describes how UUCP addresses are supposed to be formatted, so it's not even clear to me how a correct address parser are supposed to handle those things. Agreed. - Remove dbm/ndbm dependency. The ONLY reason nmh has a dependency on a db library is for duplicate suppression in slocal; if slocal finds a duplicate Message-ID, it discards it. I didn't think getting a dbm library was so hard, but apparantly it is under Linux; the autoconf stuff for this is a giant mess. I'm wondering ... do people actually use this functionality? I'm thinking the days of using slocal in your .forward file have slowly been coming to an end. At the very least we should make this functionality optional ... that would make things easier for Paul Fox, if no one else :-) I use duplicate message suppression, but I use procmail to do that. I think Markus suggests that we remove the orthogonal slocal program entirely. I have to agree since I've been using procmail for years, and may switch to sieve in the future. We can easily create a separate slocal project for the slocal die-hards and remove an unused portion of MH (for many of us). - Remove rcvtty completely. This works in conjunction with slocal or procmail; it broadcasts new message summaries to your terminal. Because of OpenBSD unpleasantness it's challenging to get it working there, and it really occurs to me that it's the wrong thing to be doing. Agreed. It is also orthogonal to the MH UI and is provided by other methods. If there is still support out there, we can split off another project. - Content-MD5 support. I will admit that I haven't done a complete survey, but from what I've seen nmh is the only MUA still generating a Content-MD5 header in MIME messages. This means we need a MD5 implementation, and a test for it. This has caused portability problems in the past, and I'm wondering if this is useful at all; I get the feeling that we're the only ones to support it. See Markus's thesis for a more complete survey. $ grep -i content-md5 mh-e/*.el $ Agreed. - EBCDIC safe encoding. Forces quoted-printable encoding if an EBCDIC unsafe character is seen (see uip/mhbuildsbr.c:ebcdicsafe[]). We don't care about this, right? Agreed. Happy New Year, everyone! --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Content-MD5 header field (was: Garbage collection)
Lyndon Nerenberg lyn...@orthanc.ca writes: I have used it in the past, and plan to again on an upcoming project. It is a fast and simple way to identify identical content when scanning large message archives. Interesting. You reminded me of an MH-E implementation that uses MD5 checksums to create an X-MHE-Checksum header field to perform quick lookups of current messages. Note that we would use this header field even if the message was signed. I guess we didn't know about Content-MD5 (RFC 1864). I can't find its documentation. I suppose from the RFC, it's primary use would be to add it to outgoing messages (perhaps via a send argument). In MH-E's case, we need to add the header field to a received message, so we'd probably use anno. p.s. Please continue to cc mh-e-de...@lists.sourceforge.net on this discussion. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] pick -nosequence ?
Paul Fox p...@foxharp.boston.ma.us writes: ralph wrote: Hi Bill, How about $ MH= pick -sequence foo My mh_profile(5) doesn't explain the significance of a defined but empty $MH. A quick test here suggests the same .mh_profile is opened with no $MH defined or an empty one. that's what i found too. also: $ MH=/dev/null pick -sequence foo pick: `/dev/null' specified by your MH environment variable is not a normal file $ cp /dev/null /tmp/null $ MH=/tmp/null pick -sequence foo pick: Your /tmp/null file does not contain a path entry. i pushed the -nosequence change last night. Thanks, the MH= was worth a try since it works with MHCONTEXT (I think :-\). Maybe that's a bug? -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] A Call For Pre-nmh MH Documentation
Lyndon Nerenberg lyn...@orthanc.ca writes: Folks, I'm looking to put together a consolidation of MH documentation from the dark ages. I know there are papers that have been lost along the way (e.g. from the pre-version-6 tapes), release notes, etc. Even better would be a record of source code commits/comments from the MH development era. If you have anything even remotely related to the development of MH, please send me a note describing what you have. I am especially interested in mag tape archives. If we can collect enough of these, it might be possible to piece together the basics of a hierarchical SCM repository. Please forward this message along to anyone you think might have material worth saving. The archive will be publicly accessible from orthanc.ca. Hi Lyndon, Jerry and I spent a lot of time archiving everything we had onto rand-mh.sourceforge.net. It goes back to MH 5. I think it would be better to keep it all together and put anything you find there. We don't have the CVS record, so that would be a valuable addition. The SourceForge project is at: https://sourceforge.net/projects/rand-mh/ and the files are kept here: https://sourceforge.net/projects/rand-mh/files/?source=navbar Depending on what you find, one of the existing folders might be appropriate or we can create a new one. I'd be happy to give you write access. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] A Call For Pre-nmh MH Documentation
Lyndon Nerenberg lyn...@orthanc.ca wrote: On 2012-12-05, at 8:33 PM, Bill Wohler wrote: Jerry and I spent a lot of time archiving everything we had onto rand-mh.sourceforge.net. It goes back to MH 5. I think it would be better to keep it all together and put anything you find there. That's cool – as long as we can keep it in one place. OK, great! When you're ready, send me your SourceForge ID and I'll add you as a developer. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.5RC3 no longer honors mts.conf localname setting for Message-ID?
Ken Hornstein k...@pobox.com writes: I must have missed that conversation. I use -msgid for the same reason Tom does. Well, you're only ... 5 months out of date? :-) Only thing you have to really pay attention to is your components files, if you aren't using the defaults. 6 months, actually. I took a vacation day yesterday so I could get caught up :-). [Desperately trying to catch up on old mail before installing 1.5 and adapting MH-E this long weekend and wondering what's going to become of the -msgid flag when I do that...] It's still there and works fine. Great, thanks! The next release of nmh will have a -messageid flag to send to let you change how Message-IDs are generated. But -msgid will still be around, and I don't think that's going to change ever. I am letting you know up front that if you ask a question about 1.5 that is in the release notes I will make fun of you on the list :-) Agreed! This brings up a question I always had back when we had this discussion ... what are people keeping those Message-IDs for, anyway? I remember Ralph Corderoy saying that he likes to tell people I said that in message message-id ... I know if I tried that with the people I exchange email with, they wouldn't have any idea what I'm talking about. In general, it makes it easier to find a sent message or a reply to that message. A specific use case is that sometimes I'll refer to the Message-ID of a message (sent or received) as a source for additional information for a task I create in Remember the Milk. It also turns out to be incredibly handy when replying to a message in your +outbox since the reply can create a useful In-Reply-To header field (see below), highlighted in one of two MH-E bug reports involving -msgid: Add Message-ID to outgoing messages http://sourceforge.net/tracker/index.php?func=detailaid=725425group_id=13357atid=113357 spost doesn't have -msgid or -mime flags http://sourceforge.net/tracker/?func=detailatid=313357aid=1486726group_id=13357 As a result of the first item, MH-E now calls send -msgid since if you reply to a message in your outbox that doesn't have a Message-ID, an In-Reply-To header field is created that breaks threading at the recipient's end. Given the demise of spost, I chuckled when I spotted the second item. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] pick(1) decode RFC-2047 headers?
Ken Hornstein k...@pobox.com writes: Ralph pointed out earlier that with the proliferation of RFC 2047-encoded headers, pick is much less useful. I'm wondering ... would it make sense to simply have pick run the RFC 2047 decoder on headers before matching them? As far as I can tell we can decode all headers except for Received: headers. Thoughts? Header fields should be RFC 2047-decoded before any MH operation that considers the content of the message, including pick, shouldn't they? -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.5RC3 no longer honors mts.conf localname setting for Message-ID?
Ken Hornstein k...@pobox.com writes: (BTW, after some experimentation I realized that there is a good reason to have post assign Message-IDs rather than let the MTA do it: if post does it then the Message-ID gets included in the Fcc-filed copy, which at least for me is a significant advantage. So I don't plan to take Ken's advice of dropping the -msgid switch, and will persist with hacking the source code to make the message IDs be generated the way I want.) To be fair ... I wasn't suggesting that's what you do; my point only was that the last time people talked about that, the majority of responses (actually, all of them) indicated that they didn't use -msgid. I must have missed that conversation. I use -msgid for the same reason Tom does. [Desperately trying to catch up on old mail before installing 1.5 and adapting MH-E this long weekend and wondering what's going to become of the -msgid flag when I do that...] -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] does dist work?
Jeffrey Honig j...@honig.net writes: I use dist (via mh-e) all the time to add people who were not Cc'd. Confuses the hell out of Outlook and Thunderbird users. That's part of the charm. I use dist in MH-E all the time too. Most times the recipient doesn't even notice. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] somewhat OT: re procmail or ??
ra...@hep.wisc.edu writes: Am I dinosaur for still using procmail?? Yes, but you're not the only dinosaur here :-). I mean, is there something better? I had noticed that procmail hasn't been updated in years, so I added a task to investigate sieve as a possible replacement. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] sortm's Default of all is Brain-Damaged.
Kevin Cosgrove kev...@cosgroves.us writes: On 11 October 2012 at 10:35, Joel Uckelman uckel...@nomic.net wrote: Speaking for myself only: I can't recall a single time in 15 years of using nmh that I've wanted to use sortm to sort less than a complete folder. I have two use cases for sortm 1. sortm +folder 2. sortm -textfield subject -limit 0 +folder Me too. I don't think I've ever used sortm with a sequence. Glad -all became the default. Throwing an error if explicit messages were not specified would have broken MH-E. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
Jerrad Pierce belg4...@pthbb.org writes: Perhaps Jerrad was referring to `@' being used instead of `+' for relative folders. You are correct sir. If it's not in the man pages, it must have been something I picked up from the Jerry's MH book. Yep. http://rand-mh.sourceforge.net/book/mh/fol.html#RelNam -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Email access while traveling?
Kevin Cosgrove kev...@cosgroves.us writes: What do you all do to access your email while traveling? Hi Kevin. I have three options: 1. If I have my laptop with me, then the normal thing happens (fetchmail gets the mail from my IMAP server). 2. Otherwise, I use K9 on my phone to read the mail from my IMAP server. I've set the preferences to always send a cc of all outgoing messages to myself so that I can manually file them in +outbox when I'm back on my laptop. 3. I installed squirrelmail on my IMAP server, so alternatively I can use that to read mail in a web browser. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] comp.mail.mh gateway?
Thanks, Jerry! My FAQ posts are on auto-pilot. I actually don't read Usenet any more either, but I do use Gnus to read gmane mailing lists (including gmane.mail.nmh.devel). JerryHeyman heym...@bellsouth.net writes: On Sun, 22 Apr 2012 14:56:22 -0500, Ken Hornstein k...@pobox.com wrote: I've got you covered. jerry In sending out the announcement for 1.5-RC1, I sent mail to the mh-users list at UCI (README.developers said to do that, and I guess I didn't do that for 1.4). Like I figured it would, it bounced. The developer documentation said that this was a bidirectional gateway to comp.mail.mh. So this leads me to another question ... should I bother sending this to the comp.mail.mh newsgroup? I admit that I gave up on Usenet a long time ago as a spam haven, and the last message I see on there that was relevant was ... October. Which I guess isn't that long ago. Is it worth it? Would someone be willing to send an announcement there? Bill Wohler, I see you still post there :-) --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Feature Request: Comments in $HOME/.mh_profile
Me too: #: Variable Settings ... Maybe we should simply reserve # as a profile component and document #: as the .mh_profile comment character(s) rather than leave it as a puzzle. Earl Hood e...@earlhood.com writes: On Tue, Apr 24, 2012 at 11:23 AM, norm wrote: I and at least one other user -- and probably many others, have .mh_profile entries that we added years ago, for reasons now obscure and not remembered. There ought to be an easy way to incorporate comments in that file. As I read the man page, there is none provided. Yes, I could use a bogus component like: foobarNoSuch: The line below prevents scurvy. I use the following in my .mh_profile: #: This is a comment line #: This is another comment --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ 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 lyn...@orthanc.ca writes: On 2012-03-26, at 15:05 PM, Ken Hornstein wrote: Weren't you and Paul Vixie supposed to be working on that? Not me. I have other things I'm not working on! This is one of the funnier lines I've read in a while :-). -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] forw -digest ?
Jon Fairbairn jon.fairba...@cl.cam.ac.uk writes: Bill Wohler woh...@newt.com writes: Ken Hornstein k...@pobox.com writes: When looking over forw today, I came across the code that handles digests (which I guess is the companion code to burst). So, I was wondering ... do people use this? I'm not really suggesting it be removed, I'm just trying to understand the use cases. Wow, I remember using this command a lot back in the day when it was real handy to string together a thread of messages in a digest for my own consumption or to pass along to a friend. Mail and news readers were a lot more digest-friendly in the Golden Days of Usenet. I'd be hard-pressed to remember the last time I used it, or to articulate a use case. Still, it would be good to keep, as you say. I’d probably use it (or something like it) if there were a convenient way to select several messages in mh-e and forward them ;-) Hi Jon, just select several messages and forward them :-). The mark and point are used, so the messages do have to be contiguous. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
David Levine levin...@acm.org writes: - Just a guess, but I expect that most people who use prepackaged nmh don't use @. (Again assuming no use by mh-e and xmh.) That's probably a good assumption for MH-E. The message that you are replying to is available in a buffer; all message buffers are named according to the messages folder and message number. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh User's Manual?
David Levine levin...@acm.org writes: Ken wrote: I've seen a number of nmh man pages which say things like this: Consult the Advanced Features section of the nmh User's Manual for more information on making digests. Which leads to to ask ... which manual are they talking about, exactly? Looks like the MH User's Manual. I found a copy here: ftp://ftp.vim.org/pub/mail/mh/doc/MH.ps.gz The Historical Documentation page on Sourceforge has links to the ftp site at UCI, but it's gone. I think that we should archive those old documents before all of the mirrors disappear. Is there a place to store them on Savannah? Or should I just throw them into the git repo? About 3.5 MB. Were you aware of https://sourceforge.net/projects/rand-mh/files/Documentation/? We archived all of the old MH stuff at SourceForge (project rand-mh). Here are the release notes for the Documentation package, which shows that the tarball includes MH.ps: Release Name: 1.0 Notes: mh/doc/README These are formatted versions of the major MH documents (written using the troff -ms and -me macro packages). The .doc files are formatted for 66 lines/page: ADMIN.doc - The MH Administrator's Manual - how to configure MH MH.doc- The MH User's Manual changes.doc - Changes from MH 6.6 to MH 6.8 mh-gen.doc- The READ-ME file - how to generate MH (aka mh-gen(8)) Postscript versions are also available: ADMIN.ps - The MH Administrator's Manual - how to configure MH MH.ps - The MH User's Manual changes.ps- Changes from MH 6.6 to MH 6.8 mh-gen.ps - The READ-ME file - how to generate MH (aka mh-gen(8)) These are postscript conversions of the MH papers which were written using the TeX typesetting language: bboards.ps- The UCI BBoards Facility beginners.ps - UCI MH for Beginners mh4mm.ps - MH for MM users mh6.ps- Changes from MH 6.0 to MH 6.5 for 4.3BSD multifarious.ps - MH: A Multifarious User Agen mznet.ps - MZnet - Mail Service for Personal Micro Comp. Sys. realwork.ps - MH.5 - How to process 200 messages... trusted.ps- Design of the TTI Prototype Trusted Mail Agent tutorial.ps - The MH Tutorial These conversions have been provided because they may be of use to some sites who retrieved MH using FTP, and who do not have TeX to typeset the papers themselves. Of course, all recipients of an MH distribution tape receive a complete set of laser-printed manuals. These conversions were generated with the dvips program. I have printed them on an Imagen 5320 w/ Turboscript, and the output is identical to the original dvi versions of these papers. As yet, I have had no success downloading the postscript files to a Mac- intosh, and printing them on a Laserwriter. If you are able to generate copies of these papers which will print (identically to the originals or otherwise) on a Laserwriter, please contact bug...@ics.uci.edu. These files are tty-readable conversions of the MH papers which were written using the TeX typesetting language: bboards.tty - The UCI BBoards Facility beginners.tty - UCI MH for Beginners mh4mm.tty - MH for MM users mh6.tty - Changes from MH 6.0 to MH 6.5 for 4.3BSD multifarious.tty - MH: A Multifarious User Agen mznet.tty - MZnet - Mail Service for Personal Micro Comp. Sys. realwork.tty - MH.5 - How to process 200 messages... trusted.tty - Design of the TTI Prototype Trusted Mail Agent tutorial.tty - The MH Tutorial These conversions have been provided because they may be of use to some sites who retrieved MH using FTP, and who do not have TeX or a laser printer on which to print the papers. If you have a Postscript printer, you may want to retrieve the Postscript conversion of these papers, available in a different tar archive. Of course, all recipients of an MH distribution tape receive a complete set of laser-printed manuals, and these conversions are not a substitute for properly-formatted copies of the originals. The conversion was generated by the dvi2tty program. As full use of TeX's rich typesetting environment was used in writing many of these papers, and since the output is intended for a line printer, it is necessarily quite primitive. Font changes and special character representations are lost entirely. White-space between words may be deleted or expanded, especially near punctuation characters. Blank lines may be added or deleted. Since typeset lines are typically longer than 80 tty characters, the output has been generated for 132-colunm output devices. A typical page has about 76 lines. Pages are separated by a formfeed character. /JLR Changes: -- Bill
Re: [Nmh-workers] Updating the nmh front-end programs for multiple identities
Ken Hornstein k...@pobox.com writes: One of the bugs submitted on savannah by Bill Wohler mentions that MH-E added support for identities (although he doesn't really go into what that means). But it occurs to me that with the changes I've made, well, that's pretty close to identity support. For people that use a nmh front-end, it would need relatively small changes to make it work. So I'm thinking ... Bill (MH-E) and Valdis (the current exmh guy) ... would you guys be interested in adding/integrating identity support to your respective front-end interfaces? Would you need anything else on the MH side to make this happen? At least on the exmh side you could get rid of a lot of the post-processing that is done on drafts. Unfortunately, I won't have time to play with this. I'll go ahead and create a feature request so we don't forget to look into it. In the meantime, see if this helps: http://mh-e.sourceforge.net/manual/html/Identities.html -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh User's Manual?
David Levine levin...@acm.org writes: I found a goldmine: the MH 6.8.5 tar ball contains RCS files for all of the source code. And it contains the sources for all of the documentation. I currently have it staged for addition at docs/historical/mh-6.8.5/ Before committing, is there a way to not include the contents of each file in the nmh-commits message? It's about 20 MB. Or even better, is there a reasonable way to shove the old histories into the beginning of the git history? My guess is not, but that would be really neat. Yes, it would be awesome to prepend git's history with the original RCS files. That could probably be done by exporting the git repository, started anew, importing the RCS files, and then importing the exported git repository. Otherwise, rather than incorporating these files into nmh proper, perhaps http://sourceforge.net/projects/rand-mh/files/MH/6.8.5/ would remain as the best place for this history. If someone has some time (maybe me, someday), the RCS files could be pulled out and put into a CVS or Subversion repository at SourceForge where they could be more easily browsed. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] forw -digest ?
Ken Hornstein k...@pobox.com writes: When looking over forw today, I came across the code that handles digests (which I guess is the companion code to burst). So, I was wondering ... do people use this? I'm not really suggesting it be removed, I'm just trying to understand the use cases. Wow, I remember using this command a lot back in the day when it was real handy to string together a thread of messages in a digest for my own consumption or to pass along to a friend. Mail and news readers were a lot more digest-friendly in the Golden Days of Usenet. I'd be hard-pressed to remember the last time I used it, or to articulate a use case. Still, it would be good to keep, as you say. On a related note, I use burst on forwarded messages a lot to either promote the forwarded message to the scan line, or to reply to a forwarded message. -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
