[nmh-workers] vixie out

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. i've helped find and fix bugs in the MH library, i regularly tested and patched the MH (and

Re: [nmh-workers] FSF is changing Mailman list settings unless you opt out (fwd)

hymie! wrote on 2019-09-27 07:21:> Unfortunately, Yahoo isn't the only culrpit. More and more servers are honoring DMARC. yes, i know. I, for example, keep my email on my own server at home, but because my ISP blocks port 25, I have to hire a third party to receive and re-send my email

Re: [nmh-workers] FSF is changing Mailman list settings unless you opt out (fwd)

Ken Hornstein wrote on 2019-09-26 09:36: Everyone, I received this email, and I wanted to pass it along. The executive summary is: in the near future subject lines to nmh-workers will no longer be prefixed with "[nmh-workers]" and there won't be a footer at the end of the message anyone

Re: [nmh-workers] Superhuman MUA.

On Monday, 10 June 2019 22:41:18 UTC Ken Hornstein wrote: > >$ cd `mhpath +future` > >$ find -type f > >./2019-06-10T18:13/1 > >$ > > Maybe it's the rocket engines, but it sure doesn't seem like that's how > it works. It implies you can "Undo Send" anything. you seem to be

Re: [nmh-workers] #ifdef UK

we should remove all feature or behaviour ifdef's. those things should be configured at runtime, in config files or command line options. code size is not the menace it once was. only things that won't compile everywhere need ifdef, and only for the non-portable bits. -- nmh-workers

Re: [nmh-workers] closefds() _before_ fork?

Ralph Corderoy wrote on 2019-04-23 05:10: ... I agree with the general principle that if we open it, we track it, and then close it so it doesn't reach the child, typically with O_CLOEXEC or FD_CLOEXEC. ... to that end, i propose that we treat any open descriptor N>2 at the time of an

Re: [nmh-workers] nmh 1.7.1: both bcc and dcc broken for mts sendmail/pipe

valdis.kletni...@vt.edu wrote on 2019-02-14 14:16: ... Am I the only guy who's been bitten by documentation that has single and double quotes that look cut-n-paste-able but actually aren't? nope. -- P Vixie -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] Reproducible build patch

Ken Hornstein wrote: It determines the style of date(1) to invoke without relying on user input, then when that's known it invokes it again with the desired number of seconds but without discarding stderr in case of problems, and the existing `set -e' would exit on an error. It occurs to me

Re: [nmh-workers] Unnecessary dependency on vi???

Paul Fox wrote: ... i love this mailing list. i keep trying to leave, but, i can't! -- P Vixie -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] Unnecessary dependency on vi???

Andy Bradford wrote: Thus said Ralph Corderoy on Tue, 20 Mar 2018 12:56:09 -: For evermore, programs that only offer one means of invoking an editor have had to checking first $VISUAL, falling back to $EDITOR. :-) You mean like the following chunk of code: :-)

Re: [nmh-workers] Unnecessary dependency on vi???

Ken Hornstein wrote: ... it turns out the default editor back in the day (if you didn't configure one with mhconfig) was "prompter", which would give you a kind of very simple message input interface (but not exactly like you describe). prompter is what i was thinking of. repl and forw also

Re: [nmh-workers] Unnecessary dependency on vi???

Ralph Corderoy wrote: why would our build or install dependency list include any editor? Fedora's is changing from an install dependency on /usr/bin/vi to a Suggests one. I haven't checked what the other distributions do. AIUI the idea is a user won't see $ comp unable to exec

Re: [nmh-workers] Unnecessary dependency on vi???

rewind, please. i set VISUAL to /usr/local/bin/jove, and never have used any version of vi with any version of mh, ever. why would our build or install dependency list include any editor? -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] [Nmh-workers] nmh on Maildir.

by the way, this is how i move my wife's inbox into annual subdirectories now. when we used MH, it was simpler by far. http://www.redbarn.org/node/29 -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ken Hornstein wrote: from there, implementing Maildir might be easier than from here. even IMAP isn't impossible, if we're willing to return a socket descriptor instead of a file descriptor, or maybe a pipe from a fork, or (gag me) a temporary file. Wlll ... I think, sadly, that to

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ken Hornstein wrote: Here is my $0.02 on that topic. ... strong +1 to ken's analysis here, and below where he questioned the utility of developing our own IMAP server. in more detail, this topic: Now I am not suggesting that we replace the MH mailstore with Maildir; that doesn't seem

Re: [Nmh-workers] nmh on Maildir.

Ralph Corderoy wrote: ... Could an optional level of indirection help; mail/inbox/42 having content that states it's not the email, but here's details that allow the email to be found in a Maildir, including a fast method, and a slower one for if things have got out of sync. It would mean

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ralph Corderoy wrote: ... Right, like http://man.cat-v.org/plan_9/4/upasfs ... Would it be presenting a read-only view of the master storage, and that storage can still be diddled with by any Unix command? read-only would be a successful MVP, but eventually, read-write is nec'y. -- P

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ken Hornstein wrote: ... So it would be helpful if we supported Maildir as a mailbox format, because then we could use nmh directly on the backend store without going through IMAP (to me that suggests that really you want IMAP support in nmh, but, whatever). ... if MH could speak IMAP and

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ken Hornstein wrote: ... In my mind a mail DROP is where an MTA drops off email for some later program to pick up, not necessarily where mail is stored for manipulation by a MUA, and a lot of the Maildir documentation is talking about how there's a special delivery directory ("new"). But

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ken Hornstein wrote: the imap service's relationship to its backing store is none of my business as an imap client. as long as invariants are preserved, the precise form of magic, or even what upstream rules might be getting broken, are "all fine by me". Well, I didn't care that much about

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Andy Bradford wrote: Thus said Ken Hornstein on Tue, 13 Feb 2018 11:30:38 -0500: We've talked a lot about the subtle change to move MH to Maildir, and we never quite work out all the wrinkles, and I'd sure like to that. I hear people say this, and I have to wonder ... what's the goal here?

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ken Hornstein wrote: You know, it might be interesting to see the output from inotifywait when you do a drag and drop across folders. I am presuming that Thunderbird doesn't know about the Cyrus-IMAPd index and Cyrus IMAPd just figures it out. If that's the case then that is fine. the imap

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ken Hornstein wrote: ... Well, good question! I believe the answer to that is "no". You can read the base specification here: https://cr.yp.to/proto/maildir.html The idea is when you are delivering a new message into a Maildir, you first write it to the "tmp" directory, then rename

Re: [Nmh-workers] C++

as promised, i asked bert hubert how he uses C++ in PowerDNS without damaging himself: On Mon, Feb 12, 2018 at 12:43:16PM -0800, Paul Vixie wrote: you seem to have made peace with C++. i predict that you did this by declaring some subset of its features that you'd be willing to use

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Michael Richardson wrote: ... I tried to build the other one (uw-imap?) that had MH support, but it was too much effort because the "libmh" library was pretty much impossible to build/configure. sorry about that. (i was the maintainer in the years up until mark's death.) the ruinously bad

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Bakul Shah wrote: On Mon, 12 Feb 2018 10:33:51 -0800 Paul Vixie<p...@redbarn.org> wrote: if we wanted the effort of an actual rewrite, we would need to justify the time expenditure with a potentially larger user population, which means reconsideration of features that younger people ac

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

David Levine wrote: Ralph wrote: The aim would be for the existing users to have a code base that allowed more rapid, stable development of new features, deprecating old warts, and improving consistency. +1 I'd rather see more of all the above, even if it means giving up some current

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ken Hornstein wrote: Some smart-ass on this list recently gave me a flippant response when I made a similar lament regarding valgrind on MacOS X. Who was that again? :-) i normally hate people like that, but did he say, here kid, here's a nickel, get yourself a better C library for

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ken Hornstein wrote: ... you said: And the programs I tried worked fine. Running best scan time for 200K messages, scan+gc takes 13.5 seconds while the regular scan 7.4 seconds. To me a performance penalty of 50% is not worth it, but I'd be willing to hear from others. the various design

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ralph Corderoy wrote: Hi Paul, that's a knee-jerk reaction. Very true. A regurgitation of a long-held view. bert hubert at powerdns found a subset he can live with, and ways to enforce it. basically there are no operators overloaded and no subclassing. I've struggled to find something

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

Ken Hornstein wrote: ... But ... one nasty problem raises it's head. That is the lack of _time_. We have plenty of great ideas, but those of us who want to implement them all suffer from a lack of time to work on them. Rewriting nmh in Go seems like it would take a long time. Slowly

Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

i do all new work in Go. i just don't know whether MH can attract new users through a rewrite. -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] GCC 8 pre-releases have escaped...

Ken Hornstein wrote: ... When I wrote that comment, nothing in the format engine would ever call free() on component names, so it wasn't a problem. scan() isn't expecting anyone to free those buffers that it is malloc()ing. i think that there's no way to be selectively uncaring. if we don't

Re: [Nmh-workers] GCC 8 pre-releases have escaped...

Ken Hornstein wrote: ... I am wondering if the buffer reuse in scansbr.c is still warranted; should we just accept the price of a bunch of malloc/free calls? it's 2018 and my smart phone has more cpu power than all the pdp-11's in the world had when MH was designed. so, yes. -- P Vixie

Re: [Nmh-workers] GCC 8 pre-releases have escaped...

Ken Hornstein wrote: Six is ABRT. Have you tried `make check' with valgrind? Sigh, there are a ton of exclusions I have to put in valgrind to make it useful on MacOS X. I'm chipping away at them slowly. my first thought was "here kid, here's a nickel, get yourself a real computer."

Re: [Nmh-workers] GCC 8 pre-releases have escaped...

Ralph Corderoy wrote: ... A lot of it is duplicate dribble pasted over the decades and it could probably be halved in size. Along the way, I'm sure many bugs, lack of error checking, and inconsistencies would be found, and fixed. sounds like a great beer-and-pizza expedition. ... I

Re: [Nmh-workers] GCC 8 pre-releases have escaped...

oops. Ken Hornstein wrote: ... - Messages in IMAP are immutable, so if you overwrite ~/mail/inbox/42, in theory you should get a new UID for that message. But maybe our "internal" IMAP implementation wouldn't care. I do wonder how UW-IMAP deals with that, since it claims to be able

Re: [Nmh-workers] GCC 8 pre-releases have escaped...

Ken Hornstein wrote: ...> - Messages in IMAP are immutable, so if you overwrite ~/mail/inbox/42, in theory you should get a new UID for that message. But maybe our "internal" IMAP implementation wouldn't care. I do wonder how UW-IMAP deals with that, since it claims to be able to

Re: [Nmh-workers] GCC 8 pre-releases have escaped...

Bakul Shah wrote: On Tue, 06 Feb 2018 16:15:38 -0800 Paul Vixie<p...@redbarn.org> wrote: Paul Vixie writes: in the broader context of our work, we might ask, do we want the size of the MH user community to ever again grow, How likely is that? unless we reinvent in a way

Re: [Nmh-workers] GCC 8 pre-releases have escaped...

Ken Hornstein wrote: ... First off .. normally MH memory management has been terrible, because the programs are all short-lived. This makes it hard to do some interesting long-term things, like create a set of library routines for other programs to use. This is all part of cleaning that up

Re: [Nmh-workers] GCC 8 pre-releases have escaped...

Ralph Corderoy wrote: ...> There was a long `strncpy(3), die, die, die.' thread back in 2016 about this, including that strncpy() pads to the full 8 KiB with NULs. My to-do list summarises what I think was the conclusion. - Add trunccpy() for when truncation is correct, e.g. the start of

Re: [Nmh-workers] switches and smatch

if we're doing global search/destroy on nmh command line processing, please consider: http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Nmh-commits Digest, Vol 108, Issue 11

Bakul Shah wrote: fmttest.c: Avoid `++' with bools, silencing compiler warnings. i hate that perfectly reasonable, traditional idioms have to be avoided for this reason. No strong reason to use type bool in the first place. It didn’t show up till c99. pointers aren't booleans.

Re: [Nmh-workers] proposed patch for shell metacharacter failure in nmh-1.7

Steven Winikoff wrote: ...>> My proposal is to simply edit out shell metacharacters (add # and ! like David suggested) in those strings. That seems simple and reasonable to me. Well, maybe replace them with an _ or something. For what it's worth I'd prefer the "replace them with _"

Re: [Nmh-workers] proposed patch for shell metacharacter failure in nmh-1.7

Ken Hornstein wrote: for MH we should allow only metacharacters we handle explicitly, and we should use strsep() rather than /bin/sh to make our argument vectors, and we should call execve() rather than popen(). Geez, Paul, we HAD this food fight already! :-)

Re: [Nmh-workers] proposed patch for shell metacharacter failure in nmh-1.7

i do not think that we can ask for the shell's help with metacharacter expansion, because even on unix, the syntax it understands may not be what the user expects. because i call sendmail from popen() in cron, i had this problem with MAILTO= values. i first decided to accept only @, %, ::,

Re: [Nmh-workers] proposed patch for shell metacharacter failure in nmh-1.7

Ken Hornstein wrote: That's not right, it should be: while ((pp = strchr (pp, '\''))&& buflen> 3) { pointers aren't booleans. in BSD style as used in BIND, this would be: while ((pp = strchr(pp, '\'')) != NULL&& buflen> 3) { Forgive my stupidity ... but this is just a matter

Re: [Nmh-workers] proposed patch for shell metacharacter failure in nmh-1.7

must we call /bin/sh -c "$foo", or can we call execve on the command itself, after cracking it into an argv[] ? -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] proposed patch for shell metacharacter failure in nmh-1.7

David Levine wrote: Steven wrote: I see that the first hunk is trying to match on while ((pp = strchr (pp, '''))&& buflen> 3) { That's not right, it should be: while ((pp = strchr (pp, '\''))&& buflen> 3) { pointers aren't booleans. in BSD style as used in BIND, this would

Re: [Nmh-workers] Announcing the release of nmh-1.7

Ken Hornstein wrote: ... I just double-checked RFC 5322, and as far as I know this is valid. Specifically, "To:" is defined as having an address-list: address-list = (address *("," address)) / obs-addr-list And the other relevant bits are: address = mailbox / group

Re: [Nmh-workers] IMAP/nmh, again

Ken Hornstein wrote: connect to the imap service and authenticate open a unix domain socket and listen() to it on each connection: So, alright, I admit that you're more experienced than I especially at the "big picture", so I want to understand exactly what you're proposing. Is this,

Re: [Nmh-workers] IMAP/nmh, again

Ken Hornstein wrote: the top of thread shows a prediction of likely performance impact from opening and closing an imap session every time an mh command starts or stops. i'm arguing against that, because state is necessary in order to receive push notifications, and so to me, the reason to

Re: [Nmh-workers] IMAP/nmh, again

Bakul Shah wrote: On Fri, 27 Oct 2017 00:41:58 +0200 Paul Vixie<p...@redbarn.org> wrote: Paul Vixie writes: there's a think in imap called "push", which is part of why i keep Not sure what you mean. Perhaps you mean having to push locally created messages to the imap ser

Re: [Nmh-workers] IMAP/nmh, again

Bakul Shah wrote: On Thu, 26 Oct 2017 17:26:37 -0400 valdis.kletni...@vt.edu wrote: valdis.kletni...@vt.edu writes: AIUI, the big issue has always been that nmh has expected message numbers to remain static until explicitly changed (i.e. message 35 *stays* message 35 until 'folder -pack' or

Re: [Nmh-workers] MH + IMAP? (was Large MH directories

Bakul Shah wrote: ... The local socket part is easy. Connect to /tmp/mhd/$USER. [Calling this daemon mhd for short] If the socket doesn't exist or a write to it fails, kick off mhd. indeed, yes, that's how to do it. see also "prayer", an imap server: Prayer is yet another Webmail

Re: [Nmh-workers] [patch] filtering support for inc

Jon Steinhart wrote: Ken Hornstein writes: The hooks cover everything so that one can keep track of what message exist and where they are. The work for me, but I don't use all of the gritty nmh features so there might be bugs for some complex cases. ... Well, yes, buuuttt ... we never

Re: [Nmh-workers] post ignores extra commas

Ken Hornstein wrote: this is MH, after all. we should borrow sendmail's config format and address parser, to make it more user-configurable, no? Geez Paul, I can never tell if you're kidding or not. You really want to put all of the sendmail.cf functionality into nmh? :-) :-). i think it

Re: [Nmh-workers] post ignores extra commas

this is MH, after all. we should borrow sendmail's config format and address parser, to make it more user-configurable, no? ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Segfault in post from mime quoted names in aliases

valdis.kletni...@vt.edu wrote: > On Thu, 13 Apr 2017 09:55:19 -0400, Ken Hornstein said: > >> Normally I would suggest deprecating this feature and then removing it >> after the next release, but it's impacting reasonable behavior NOW, and >> fixing the core dump issue here just means trying to

Re: [Nmh-workers] Large MH directories

Ken Hornstein wrote: > ... > > Right, I think that people forget Maildir was not designed as a mail > _folder_ but instead as a mail _drop_ (a place where you store mail to > retrieve it). Yes, Dovecot uses it as a mail store, but I believe it does > a lot of caching. One of my plans for

Re: [Nmh-workers] Large MH directories

i think that rcvstore would also become very slow, unless we're caching the next message number rather than discovering it every time. huge mboxes are one of the reasons i eventually expect to have to abandon Maildir. what i wish i had is a set of MH-like utilities that hid the backend storage

Re: [Nmh-workers] Domain Leakage Despite -messageid random.

On Sunday, 8 January 2017 09:34:35 PST David Levine wrote: > ..., nmh doesn't have a way to generate a globally unique message > or content ID. The default form is (and has been in MH), by way of > example: > > Message-ID: <3325.1483884629@localhost.localdomain> > > where the number portion

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

On Wednesday, 4 January 2017 00:08:43 PST Ken Hornstein wrote: > ... > > If we had everyone who used m_draft use the same protocol, that might > solve that problem. We'd need to make sure everyone who adds messages > to a folder calls folder_addmsg(), though. It ends up being a huge > pain to

Re: [Nmh-workers] nmh should be more careful about when it unlinks draft files

On Tuesday, 3 January 2017 10:50:11 PST Ken Hornstein wrote: > >> - The file is created with creat(), which as you know does get called > >> with O_CREAT, but does not include O_EXCL. > ... > At least in the case of comp(1), by the time creat() is called it is > writing a new draft into that

Re: [Nmh-workers] I did something wrong with replcomps

Ken Hornstein wrote: >> That kind of dependency should be removed. ... > > Since it's been around forever, I'm not sure we can easily change it > without breaking a lot of existing format files. ... do you have a sense of the actual magnitude of the MH user base? that is, how many format

Re: [Nmh-workers] strncpy(3), die, die, die.

Ralph Corderoy wrote: > They don't need to be checked because they're only used in those cases > where truncation, but still NUL-terminated, is valid. Kind of like when > `%.42s' is used in a lexer error message in case the token is runaway, > or 'cut -c 42'. Ken's saying that some of them are

Re: [Nmh-workers] strncpy(3), die, die, die.

Ralph Corderoy wrote: > Hi Ken, > >>> If this is what I think it is ... you know, I think this truncation >>> is benign. > > What if benign truncations were trunccpy(), instead of the strncpy dance > where the reader is unsure if it's benign or not, and then abortcpy() > could be the strncpy()

Re: [Nmh-workers] strncpy(3), die, die, die.

Steffen Nurpmeso wrote: > Paul Vixie <p...@redbarn.org> wrote: > |... > > I think the former and latter of the above have the problem that > they return useless information: the size that would be necessary > to store the result in a non-truncated form. If

Re: [Nmh-workers] strncpy(3), die, die, die.

Ralph Corderoy wrote: > Perhaps a complainant could be told of the secret $NMHNOBARF to stop > TRUNCCPY from aborting? Though it would still complain for the first N > goes? i think the moment that the state of the program becomes undefined, you should abort. malloc and asprintf helpfully

Re: [Nmh-workers] strncpy(3), die, die, die.

Todd C. Miller wrote: > On Mon, 24 Oct 2016 16:40:36 -0400, valdis.kletni...@vt.edu wrote: > >> In other words - if the source string doesn't fit, it will create >> a non-NULL-terminated destination string for you. Repeat that, >> slowly, until it sinks in. > > It says nothing of the sort,

Re: [Nmh-workers] forw

Ken Hornstein wrote: MIME broke all that. a lot of UI's can't cope with attachment trees where one rfc822 includes another which has attachments. the way modern graphical MIME UI's work is by iterating down through the forwarded message's MIME tree and attaching each attachment to the top

Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters

Ken Hornstein wrote: That's what I implemented in mhfixmsg: just Content-Type name and Content-Disposition filename. I think we're all fine with that; I'm wondering if we should see if it's an RFC 2047-encoded filename and just decode it automatically. that would follow the principle of

Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters

Ken Hornstein wrote: That's what I implemented in mhfixmsg: just Content-Type name and Content-Disposition filename. I think we're all fine with that; I'm wondering if we should see if it's an RFC 2047-encoded filename and just decode it automatically. that would follow the principle of

Re: [Nmh-workers] Starting the final call for features for 1.7

Lyndon Nerenberg wrote: Call me Grumpy[2], but any system with a packaged install of nmh that doesn't include the man pages[1] is broken. So yes, that's a non-starter in my books. It's not a scenario to cater to, because the fix is to not break the packages in the first place. you are not

Re: [Nmh-workers] Future directions for nmh

Lyndon Nerenberg wrote: On Mar 16, 2016, at 6:04 PM, Paul Vixie<p...@redbarn.org> wrote: prayer is the simplest and faster webmail system i ever found for my family's use while traveling. But. How. Does webmail have anything to do with this? webmail and mh both have a fork+exec

Re: [Nmh-workers] Future directions for nmh

Lyndon Nerenberg wrote: On Mar 16, 2016, at 4:56 PM, Ken Hornstein wrote: And I believe it makes it WORSE; each nmh command starts with a brand-new scan of a folder, so messages added or removed between commands work out fine. But a FUSE interface would have no idea when an

Re: [Nmh-workers] Future directions for nmh

Conrad Hughes wrote: Ken> it makes it WORSE; each nmh command starts with a brand-new scan of a Ken> folder, so messages added or removed between commands work out fine. Ken> But a FUSE interface would have no idea when an nmh command is starting Ken> or stopping, so you'd have to do a lot

Re: [Nmh-workers] Future directions for nmh

Ken Hornstein wrote: i don't know exactly how to match mime to the simplicity of show(1), and i've been violently repulsed any time i tried to use mhshow(1), but i I can't really blame you on that one. But really, mhshow(1) is really just the old mhn, slightly rewritten. And mhn was a

Re: [Nmh-workers] Future directions for nmh

Ken Hornstein wrote: Well, it depends on the message. Sometimes I get a message with 20 photos attached. I just want to be able to easily go from one to the next without having to type their part number. But ... what's wrong with doing something like: mhstore -type image Then you can

Re: [Nmh-workers] Future directions for nmh

Ken Hornstein wrote: i believe that the gnu team has an MH-like tool set that's designed this way. if so then we might just tell people like me to go use that. If you're talking about GNU mailutils, then yes. I mean, it does include a MH-compatibility layer and works with IMAP; I do not

Re: [Nmh-workers] Future directions for nmh

Jon Steinhart wrote: OK. That's a really cool idea. One could even contemplate using gmail as a mail store to make it easier for the NSA to read your mail. Maybe the hooks should be replaced by one of the DLLs. This sounds like a huge change in the codebase, so hopefully someone is up for

Re: [Nmh-workers] Future directions for nmh

Jon Steinhart wrote: ... Are you saying that you'd like to see the nmh cli abstracted to the point where it could work on different flavors of mail store? If so, that seems like a big change. Sort of like the hooks, but with a DLL interface instead of the shell? yes. -- P Vixie

Re: [Nmh-workers] Future directions for nmh

Jon Steinhart wrote: ... I think that we should keep the mail store as is. I agree that the MIME and character set stuff has made it less grep-able than it used to be, but it's still useful. useful for what? i have no remaining use cases of my own. I am emboldened by David's posting

Re: [Nmh-workers] Future directions for nmh

Andy Bradford wrote: What's wrong with the way nmh does it today? Maildir is certainly superior for some of the reasons detailed below, but nmh's Mail store isn't very far off: http://cr.yp.to/proto/maildir.html some of us have converted to Maildir, but we miss MH's CLI

Re: [Nmh-workers] Maybe time for a new release?

Ken Hornstein wrote: My reading of the maildir specification (such that it is) says that the filename before the colon should be unique. Although ... despite what people say, it seems like Maildir is not really designed to be a mail _store_ (someplace where you keep your mail long-term) but

Re: [Nmh-workers] Maybe time for a new release?

Michael Richardson wrote: Lyndon Nerenberg wrote: >> So, each message has a (U?)UID? Are the integers a subset of that? > UIDs increase monotonically within a folder. Sequence numbers are just > the index number into the dynamic array that represents

Re: [Nmh-workers] Maybe time for a new release?

On Tuesday, March 8, 2016 9:19:57 PM PST Ken Hornstein wrote: > ... I hate > to be the the one who has to explain this ... that hasn't been a realistic > goal since the advent of MIME. The model that "email is text" just > isn't valid anymore. i know. which is why i don't see much value in the

Re: [Nmh-workers] Maybe time for a new release?

Ken Hornstein wrote: > ... Is the real goal to search a Maildir store, or an IMAP store? The latter is something I've been thinking about on and off for a while noe. That should be relatively straigtforward to implement. i'd like something close to the full command line power of MH, when

Re: [Nmh-workers] Maybe time for a new release?

where did we end on reformatting the mhdir to accommodate MIME? in the past, a simple line oriented UNIX utility such as "grep -r" could be used on the mhdir, with good results. with MIME that's no longer true, either because of quoted-printable, base64, or nested objects. one solution

Re: [Nmh-workers] nmh architecture discussion: format engine character set

, and every other non-ansi non-posix system. so, i may be insane. -- Paul Vixie ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] date math

were going to re-tune MH's interface for the mass market, we wouldn't start here. -- Paul Vixie ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] PGP support

, but not quite as clearly, in the comments). thinking out loud here, what if the file name has embedded quotes? seems like we need a %Q(%F) construct that means, quote if nec'y, add interior backslashes if nec'y. (this is how $dbh-quote() works in perl code that accesses an SQL database.) -- Paul

Re: [Nmh-workers] What are and what should be the qualifications for a current nmh user

without shells or terminals can use to exchange data with us. if we want MH to be used by a declining population of neck-beards, then we're perfectly on track for that. -- Paul Vixie ___ Nmh-workers mailing list Nmh-workers@nongnu.org https

Re: [Nmh-workers] What are and what should be the qualifications for a current nmh user

even be able to let ~/Mail remain in pure MH format even while ~/Maildir has all the attachments broken out into separate files/subdirectories in pure 8-bit format. (this would be a ~/Maildir extension, which others could then teach dovecot to look for.) -- Paul Vixie

Re: [Nmh-workers] What are and what should be the qualifications for a current nmh user

linux in a virtual machine, just to run fuse, nfs, and dovecot, i would. -- Paul Vixie ___ 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 wrote: In git, a tag is just a label on the hash for a particular commit. A branch, OTOH, creates a cut point that becomes an anchor for diverted development. and in those ways, git is no different from cvs, and need not be feared. git is actually fairly simple once you

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

Ken Hornstein wrote: if mail commands can't trivially be part of shell scripts then having one message in a file is a lot less interesting I'm not sure I follow. From where I'm sitting MH mailboxes are only useful with traditional Unix tools true if the vast majority of email you have in

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

Lyndon Nerenberg wrote: If we undid the transport encodings for text/* and converted everything to utf8, you could then, e.g., alias mhgrep='env LC_ALL=en_CA.UTF-8 grep'. all true. but there's a strong feeling among MH zealots, of whom i am one and which feeling i do share, that what gets

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

Lyndon Nerenberg wrote: On Feb 19, 2014, at 8:22 AM, n...@dad.org wrote: Suppose, you weren't designing a system to run on a time shared PDF 1145, but on a single user, multi-core system. Suppose that you had multi gigabyte disks available. MH is not resource constrained by CPU, or

  1   2   3   >