Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context
Hi Jon, Many years ago I added the hooks interface to nmh. Hasn't been as controversial as my attachment handling stuff, which makes me think that it isn't widely used. I might vaguely recall it being mentioned. I found http://git.savannah.gnu.org/cgit/nmh.git/tree/docs/README-HOOKS. Perhaps the lack of man-page coverage has hindered its uptake? Cheers, Ralph. ___ 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
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 your mailbox is US-ASCII text/plain only. Can't speak for anyone else, but that's slowly becoming less and less true for me. Since MH tools only pay attention to files matching /^\d+/, it seems like breaking messages out into \d+.attachments would make things easier to grep, etc. I suggested this before, but having recently learned about hooks, this should be easy for me to mock-up sometime this week https://github.com/mcr/nmh/blob/master/docs/README-HOOKS inc (add hook) will mhstore to \d.attachment refile will rename and move as necessary rmm will remove everything else is transparent, although aliases could be made for mhlist/mhshow, which use the pre-dumled attachments. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] hooks interface issues
I cannot get the hooks to work: inc: external hook ((null)) did not work properly. refile: external hook ((null)) did not work properly. Configured via .mh_profile: add-hook: /usr/local/bin/hook-test ref-hook: /usr/local/bin/hook-test /usr/local/bin/hook-test: #!/bin/sh echo Hooked($1) $* Some other thoughts on the interface: * The requirement that the hook handler be specified by an absolute path is rather odd. * It seems a more flexible arrangement would be if the path and message number/file were given as separate arguments. Concatenation is simple/cheap in a script, but separating the two for more complex operations is less so; especially when repeated for many messages. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
Some other thoughts on the interface: * The requirement that the hook handler be specified by an absolute path is rather odd. The post-1.5 hook code has been converted over to the argsplit interface. So that shouldn't be necessary anymore. If you are using post-1.5 code ... well, I'll be honest that I didn't test it, and as far as I know there are no tests in the test suite that exercise it. So maybe it's broken. You know, looking at the code ... it was calling execvp(), so it shouldn't require an absolute path. I know the documentation says that, but that should be updated. * It seems a more flexible arrangement would be if the path and message number/file were given as separate arguments. Concatenation is simple/cheap in a script, but separating the two for more complex operations is less so; especially when repeated for many messages. That should be simple, but it would be an interface change. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
I am using 1.3, and the triggers only invoke with absolute paths. I have a master branch checkout of 1.5 from last March I've been trying, I did not check this particular issue but will take your word about it now accepting bare command names. The bigger problem of course is that nmh reports a failure to invoke the hook. It does not function in either version I have, and so it would not seem to be a recent breakage, unless my simple test is not doing something the hooks expect e.g; a specific return value, although there don't seem to be any such checks. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
I cannot get the hooks to work: inc: external hook ((null)) did not work properly. refile: external hook ((null)) did not work properly. Although add-hook does not work for inc, nor does ref-hook for refile, I just noticed that add-hook successfully fires on Fcc*. I've also found add-hook works with refile -link (nmh1.3). It looks like slocal was overlooked when hooks were implemented; although there are hooks in rcvstore. This could potentially be useful in my case, but may not be ideal in general. In my case, because I do not want to handle SPAM with hooks, and only ham is pulled from my spool folder after being stored there by slocal. Therefore, another idea for enhancing hooks is a means of determining which command was originally invoked. Perhaps this, and the source/destination folder would be better exposed through environment variables rather than changing the current command arguments? *whatnow/send/post is missing from the list of affected commands in the README ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
The bigger problem of course is that nmh reports a failure to
invoke the hook. It does not function in either version I have,
and so it would not seem to be a recent breakage, unless my
simple test is not doing something the hooks expect e.g; a
specific return value, although there don't seem to be any such
checks.
I see two issues:
- The fact that it thinks hook is NULL. That seems like a bug, and I'll
be honest; I don't know what's happening there.
Ah, okay, THAT is being caused by this code:
if (status != OK) {
if (did_message == 0) {
if ((hook = context_find(msg-hook)) != (char *)0)
advise(NULL, hook);
else
advise(NULL, external hook (%s) did not work properly., hook);
Calling context_find() AGAIN is resetting hook to NULL. Looks like that bug
has been in there since day 1. I verified that hook is being set to the
correct thing.
- So ... it looks like the child is failing with ... SIGTRAP? No, maybe that's
because I'm running it under the debugger. The hooks interface doesn't
use pidstatus(), so this needs a closer look to see what's going wrong.
And, I have to ask ... 1.3? You're not the only person still using that,
so I'm wondering if I did something wrong, or you just haven't seen a reason
to upgrade yet.
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
And, I have to ask ... 1.3? You're not the only person still using that, so I'm wondering if I did something wrong, or you just haven't seen a reason to upgrade yet. I'm running CentOS 5.9, so no package support. I downloaded master for mhfixmsg this past spring, one of the more compelling features that I can think of*, but ended up just installing it alone. I meant to get around to doing the rest, but got sidetracked before I could make the necessary backups and tests of things. Although checking the docs/pending-release-notes, there were some other small features/fixes that are nice; I remember not being able to give args to rmmproc being an annoyance, as well as rmmproc's 1k limit... but I've been trained to just do `rmm first:998` by now ;-) ___ 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] hooks interface issues
Yes, executability was one of the first things I checked ;-) Note the most recent message where it does work correctly for Fcc and refile -link though... very odd ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
