[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
> >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. Could the requirement be due to the chdir(maildir) in many programs? David ___ 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] 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. Alright, stupid question time. Did you not make hook-test executable? Because I did the exact same thing, and once I made the script executable it worked fine. Yes, those error messages suck; I'm fixing that. --Ken ___ 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
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 If you're willing to pull from master, I committed a change that will give you a useful error message. I will note that there is something a bit odd about the hooks invocation, but I lack the energy to look more closely at it. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
Sorry to take so long to respond to stuff; had some important skiing to do. This code is 12 or 13 years old now so my memory probably has some holes. 1. I had thought that I had added the hook stuff to the documentation for mh_profile but I don't see it there. I'd be happy to add it. I have a general question which is on the correct place to add documentation for new features that don't warrant their own manual page. Similar thing happened with attachments. 2. As far as I know, this code works properly. I use it dozens of times per day, and have been doing so for more than a decade. That doesn't mean that there aren't bugs in it; I'm sure that some will be found with wider use. 3. I might have missed slocal, probably because I don't use it and I'm guessing that it doesn't use the common sbr code that everything else uses. 4. I'm not sure why whatnow/send/post should be in the list of affected commands. Those don't invoke the hooks. That's all that I can sort of remember at the moment as I'm still on the first cup of coffee. Be happy to try to find a few moments to fix things as necessary unless Ken has already gotten to it. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
>1. I had thought that I had added the hook stuff to the documentation for >mh_profile but I don't see it there. I'd be happy to add it. I have 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. >2. As far as I know, this code works properly. I use it dozens of times >per day, and have been doing so for more than a decade. That doesn't I figured as much, and yet, kablooey. With Ken's new diagnostics: refile: Unable to execute /usr/local/bin/hook-add: No such file or directory external hook "/usr/local/bin/hook-add": exit 255 There's a non-printable character before the second colon. The file was not new-line terminated, and so the code was trying to invoke a bogus command >-/ After adding a new line, all hooks are firing. Ought one not be permissive of input though? >3. I might have missed slocal, probably because I don't use it and I'm >guessing that it doesn't use the common sbr code that everything else It would be worth adding, Perhaps also the environment variables? MHCMD MHSRCFOL, MHSRCDIR, MHSRCMSG MHDSTFOL, MHDSTDIR, MHDSTMSG >4. I'm not sure why whatnow/send/post should be in the list of affected >commands. Those don't invoke the hooks. One of these seems the best match for documenting that add-hook is tripped for Fcc: in drafts under "These changes affect the following commands:" ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
>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. >There's a non-printable character before the second colon. The file was >not new-line terminated, and so the code was trying to invoke a bogus >command >-/ After adding a new line, all hooks are firing. Ought one not >be permissive of input though? When you say "the file was not new-line terminated", which file? If it was your .mh_profile ... I guess that's the fault of m_getfld(). Sigh. How did you even do that? I mean, that takes some effort. I suppose thats why no one has never noticed before. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
>>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. Indeed. >Sigh .. so much documentation to do, so little time. I more meant that rather than worry about the perfect place to document hooks, etc. Have multiple ways for peolpe to find it. e.g; put the main documentation in mh_profile, then have a man page or readme that lists resources for more info on (power) customization. >When you say "the file was not new-line terminated", which file? If it >was your .mh_profile ... I guess that's the fault of m_getfld(). Sigh. >How did you even do that? I mean, that takes some effort. I suppose >thats why no one has never noticed before Yes, .mh_profile was not new line terminated. I did not do anything in particular, I simply opened the file in emacs and ammended it, and I do not even have a .emacs, which suggests it's stock behavior. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
Date:Mon, 24 Feb 2014 11:07:24 -0500 From:Jerrad Pierce Message-ID: <20140224160724.b25344c...@db.pthbb.org> | I did not do anything in particular, I simply opened the file in emacs | and ammended it emacs is a sack of horse sh*t from another universe... There are two models for what a text file looks like (given variable length lines with embedded line delimiters, not fixed length card images or explicitly counted objects). One has lines being a sequence of characters terminated by a line end character (or character sequence). The other has lines being sequences of characters separated by a line divider character (or sequence). Unix has (from the start, and still) always adopted the former definition. Lines terminate with an end of line character (\n), if that isn't there, it isn't a line (and a file that doesn't end in \n isn't a text file). Other systems (including from where emacs originates) use the second definition. There's no point arguing which is correct - either can be - nor which is better (each has advantages and disadvantages). There is also no point attempting to justify emacs extremely user unfriendly behaviour in a unix environment - it is unjustifiable. But there is also certainly no reason at all to go modifying any code to handle emacs brokenness - if you make a corrupted .mh_profile (or any other file) then you should expect bizarre behaviour (just as you would if you allowed emacs to stick a \0 in the middle of a line, which I think it is also capable of doing, but which also has no place in unix test file lines.) You could try submitting a bug report to the emacs people, but they won't take any notice - they're one another of their evangailcal crusades attempting to convert the whole world to their view of what the universe should be like (as seen from the universe from which they came - long since imploded...) kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
del-hook is not called if rmmproc is set. This prevents the user from doing a number of useful things e.g; restoration of original message in MIME-hooks (see forthcoming message to list) I would expect the hook to be called before rmmproc is invoked, and not wrapped into the non-rmmproc fallback code. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
FYI, it runs out slocal is handled (the + action uses rcsvstore). I missed this in preliminary testing because slocal is headless :-P ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
> When you say "the file was not new-line terminated", which file? If > it was your .mh_profile ... I guess that's the fault of m_getfld(). Good catch. Fixed. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
Ken Hornstein 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 a line with your proposal. -- Bill Wohler aka 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
Hi David, > > When you say "the file was not new-line terminated", which file? If > > it was your .mh_profile ... I guess that's the fault of m_getfld(). > > Good catch. Fixed. My quick skim of http://git.savannah.gnu.org/cgit/nmh.git/commit/?id=a0514c9a6f41ea1b0d60553ca578312a9f3bd9ab&context=12 with the whole source at http://git.savannah.gnu.org/cgit/nmh.git/tree/sbr/m_getfld.c?id=a0514c9a6f41ea1b0d60553ca578312a9f3bd9ab#n620 suggests that buf will have a \n at the end of it for Unix-text-file lines but not for the last line of an ITS text file. Whether that may cause problems for any of the users of buf, I've no idea. Some fix was clearly needed to avoid storing EOF in buf but kre's right, we shouldn't be supporting Emacs's brain-damaged insistence of putting ITS text files on Unix. Too many things break with them, despite GNU's efforts, and at best we should just complain about an unterminated line and stop. POSIX says a text file is zero or more lines, each line terminated by a newline. Emacs and Stallman lost. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 Any Emacs user that doesn't use `(setq require-final-newline t)' in their .emacs or similar and has to suffer because of it has made their bed... :-) The number of wasted hours I've seen over the years due to Emacs's stupidity in this respect and how each user has to discover it, sometimes more than once. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
In message <20140225120259.d11791f...@orac.inputplus.co.uk>, Ralph Corderoy wri tes: >Any Emacs user that doesn't use `(setq require-final-newline t)' in >their .emacs or similar and has to suffer because of it has made their >bed... :-) The number of wasted hours I've seen over the years due to >Emacs's stupidity in this respect and how each user has to discover it, >sometimes more than once. A better choice in my opinion, at least if you sometimes edit non-text-files, is `(setq require-final-newline 'ask)'. Missing the last newline is about as common as editing a file that will break if you add a newline, for me (both are pretty rare occasions). //Christer -- | Hagåkersgatan 18C | Phone: Home +46 31 435203 CTH: +46 31 772 5431 | | S-431 41 Mölndal |Cell: +46 707 535757 | | Sweden| Mail: m...@chalmers.se | "An NT server can be run by an idiot, and usually is." -- Tom Holub ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] hooks interface issues
Ralph wrote: > My quick skim of > http://git.savannah.gnu.org/cgit/nmh.git/commit/?id=a0514c9a6f41ea1b0d60553ca > 578312a9f3bd9ab&context=12 > with the whole source at > http://git.savannah.gnu.org/cgit/nmh.git/tree/sbr/m_getfld.c?id=a0514c9a6f41e > a1b0d60553ca578312a9f3bd9ab#n620 > suggests that buf will have a \n at the end of it for Unix-text-file > lines but not for the last line of an ITS text file. Whether that may > cause problems for any of the users of buf, I've no idea. I just reviewed a few and they're fine. They've been this way for a long, long time. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
