exmh inc failure (was: Should I be concerned about /etc/nmh/maildelivery?)
The reason I am even thinking about it is that the presort Inc method of my exmh sometimes get stucked. To be more specific, It seems that there are so me messages, which I can't fully characterize, that cause Inc to terminate its action. Where this termination does not seem to be normal since some of the email is getting copied to the desired directories, but not removed from my mail box (/var/spool/mail/shaul). When I am trying to invoke mail afterwards to see what is going on and delete the messages that were copied, it seems that someone, probably the Inc method, also left out /var/spool/mail/shaul.lock. Now all of this could be caused by my .maildelivery file because I am far from understanding what exactly is written in it. Which led me to trying to read the slocal man page, which led me to /etc/nmh/maildelivery. There are quite a few people who saw EXACTLY this problem (including myself). I saw a few emails on EXMH mailing list too. I think it's some corrupted email you get. Lock file is set by EXMH, once inc is done, it's supposed t o be removed. You can incorporate email by running nmh inc from xterminal (not from EXMH). It'll work, but there will be no filtering, everything will end up in inbox. It happended to me in libc6 problems period in slink, did not see that again. So far I did not see reasonable explanation for that phenomena, on EXMH list too. This is a reply to an old email. I just thought I would tell you that the problem has now been fixed. It was a bug in nmh. If you get nmh version 1.0-3 or higher, then the problem should be fixed. Cheers, Mark. _/\___/~~\ /~~\_/~~\__/~~\__Mark_Phillips /~~\_/[EMAIL PROTECTED] /~~\HE___/~~\__/~~\APTAIN_ /~~\__/~~\ __ They told me I was gullible ... and I believed them!
Re: inc in exmh misbehaving (was: Should I be concerned about /etc/nmh/maildelivery?)
It seems that there are some messages, which I can't fully characterize, that cause Inc to terminate its action. [etc etc...] There are quite a few people who saw EXACTLY this problem (including myself). I saw a few emails on EXMH mailing list too. I think it's some corrupted email you get. Lock file is set by EXMH, once inc is done, it's supposed to be removed. You can incorporate email by running nmh inc from xterminal (not from EXMH). It'll work, but there will be no filtering, everything will end up in inbox. It happended to me in libc6 problems period in slink, did not see that again. So far I did not see reasonable explanation for that phenomena, on EXMH list too. I've been experiencing this problem too (under Hamm). I don't believe however that it is a problem with corrupted email for two reasons: 1. the commandline inc, followed by a commandline slocal sort, works fine. How exactly are you doing this ? [21:09:37 shaul]$ inc bash: inc: command not found [21:12:10 shaul]$ /usr/bin/mh/inc inc: no mail to incorporate [21:12:18 shaul]$ slocal bash: slocal: command not found [21:12:23 shaul]$ /usr/lib/mh/slocal Nothing (Is it waiting for input ?) 2. Once when this happened, I made a copy of my mail file before I manually incorporated the mail. Then I copied back the mail file, and tried to incorporate it using the inc button on exmh. This time it incorporated fine! Ie it seems to have nothing to do with the contents of the mail file. According to you it does seems an exmh problem. It would be nice if exmh could be configured to put debug information in a file somewhere - does anyone know if it can or does?
Re: inc in exmh misbehaving (was: Should I be concerned about /etc/nmh/maildelivery?)
How exactly are you doing this ? I did /usr/bin/mh/inc +tmp Followed by the script (executed within ~/Mail/tmp): #!/bin/bash # # A little script I wrote which will go through every email in the current # directory and process it using slocal to distribute the email into the # appropriate locations. for i in [123456789]*; do /usr/lib/mh/slocal -verbose $i done 2. Once when this happened, I made a copy of my mail file before I manually incorporated the mail. Then I copied back the mail file, and tried to incorporate it using the inc button on exmh. This time it incorporated fine! Ie it seems to have nothing to do with the contents of the mail file. According to you it does seems an exmh problem. But now I am having second thoughts. I tried this again and this time copying back the file didn't help. The other thing I noticed is that although inc from the commandline worked, there was a long pause before it did. I noticed the same thing sometimes happens from exmh - except that at the end of the pause, nothing was incorporated. It's all very strange. I wish there was an option or two to provide debug information for either nmh or exmh! Cheers, Mark. P.S. I'm about to go on holidays for a week so I won't be able to continue this thread till I get back. _/\___/~~\ /~~\_/~~\__/~~\__Mark_Phillips /~~\_/[EMAIL PROTECTED] /~~\HE___/~~\__/~~\APTAIN_ /~~\__/~~\ __ They told me I was gullible ... and I believed them!
Re: Should I be concerned about /etc/nmh/maildelivery ?
The reason I am even thinking about it is that the presort Inc method of my exmh sometimes get stucked. To be more specific, It seems that there are some messages, which I can't fully characterize, that cause Inc to terminate its action. Where this termination does not seem to be normal since some of the email is getting copied to the desired directories, but not removed from my mail box (/var/spool/mail/shaul). When I am trying to invoke mail afterwards to see what is going on and delete the messages that were copied, it seems that someone, probably the Inc method, also left out /var/spool/mail/shaul.lock. Now all of this could be caused by my .maildelivery file because I am far from understanding what exactly is written in it. Which led me to trying to read the slocal man page, which led me to /etc/nmh/maildelivery. Are you doing all this through exmh? I am experiencing exactly the same problems every now and then when I incorporate mail using exmh. But when I use inc from the commandline, and use slocal from the commandline, it works fine. Cheers, Mark. _/\___/~~\ /~~\_/~~\__/~~\__Mark_Phillips /~~\_/[EMAIL PROTECTED] /~~\HE___/~~\__/~~\APTAIN_ /~~\__/~~\ __ They told me I was gullible ... and I believed them!
inc in exmh misbehaving (was: Should I be concerned about /etc/nmh/maildelivery?)
It seems that there are some messages, which I can't fully characterize, that cause Inc to terminate its action. [etc etc...] There are quite a few people who saw EXACTLY this problem (including myself). I saw a few emails on EXMH mailing list too. I think it's some corrupted email you get. Lock file is set by EXMH, once inc is done, it's supposed to be removed. You can incorporate email by running nmh inc from xterminal (not from EXMH). It'll work, but there will be no filtering, everything will end up in inbox. It happended to me in libc6 problems period in slink, did not see that again. So far I did not see reasonable explanation for that phenomena, on EXMH list too. I've been experiencing this problem too (under Hamm). I don't believe however that it is a problem with corrupted email for two reasons: 1. the commandline inc, followed by a commandline slocal sort, works fine. 2. Once when this happened, I made a copy of my mail file before I manually incorporated the mail. Then I copied back the mail file, and tried to incorporate it using the inc button on exmh. This time it incorporated fine! Ie it seems to have nothing to do with the contents of the mail file. It would be nice if exmh could be configured to put debug information in a file somewhere - does anyone know if it can or does? Cheers, Mark. _/\___/~~\ /~~\_/~~\__/~~\__Mark_Phillips /~~\_/[EMAIL PROTECTED] /~~\HE___/~~\__/~~\APTAIN_ /~~\__/~~\ __ They told me I was gullible ... and I believed them!
Should I be concerned about /etc/nmh/maildelivery ?
I don't seem to have /etc/nmh/maildelivery. Should I be concerned about it ? [09:15:11 shaul]$ man slocal | grep -A 5 -B 5 /etc/nmh/maildelivery root, and must be writable only by the owner. If the .maildelivery file cannot be found, or does not perform an action which delivers the message, then the file /etc/nmh/maildelivery is read according to the same rules. This file must be owned by the root and must be writable only by the root. If this file cannot be found or does not perform an action which delivers the message, then standard delivery to the user's maildrop is performed. -- approach can lead to quicker delivery into your maildrop. FILES /etc/nmh/mts.confnmh mts configuration file $HOME/.maildelivery The file controlling local delivery /etc/nmh/maildeliveryRather than the standard file /var/spool/mail/$USERThe default maildrop SEE ALSO rcvdist(1), rcvpack(1), rcvstore(1), rcvtty(1), mh-for mat(5) [09:15:15 shaul]$ The reason I am even thinking about it is that the presort Inc method of my exmh sometimes get stucked. To be more specific, It seems that there are some messages, which I can't fully characterize, that cause Inc to terminate its action. Where this termination does not seem to be normal since some of the email is getting copied to the desired directories, but not removed from my mail box (/var/spool/mail/shaul). When I am trying to invoke mail afterwards to see what is going on and delete the messages that were copied, it seems that someone, probably the Inc method, also left out /var/spool/mail/shaul.lock. Now all of this could be caused by my .maildelivery file because I am far from understanding what exactly is written in it. Which led me to trying to read the slocal man page, which led me to /etc/nmh/maildelivery.
Re: Should I be concerned about /etc/nmh/maildelivery ?
Hi, Shaul! I don't seem to have /etc/nmh/maildelivery. Should I be concerned about it ? I don't think so. I don't have it eather. But everything works fine. The reason I am even thinking about it is that the presort Inc method of my exmh sometimes get stucked. To be more specific, It seems that there are some messages, which I can't fully characterize, that cause Inc to terminate its action. Where this termination does not seem to be normal since some of the email is getting copied to the desired directories, but not removed from my mail box (/var/spool/mail/shaul). When I am trying to invoke mail afterwards to see what is going on and delete the messages that were copied, it seems that someone, probably the Inc method, also left out /var/spool/mail/shaul.lock. Now all of this could be caused by my .maildelivery file because I am far from understanding what exactly is written in it. Which led me to trying to read the slocal man page, which led me to /etc/nmh/maildelivery. There are quite a few people who saw EXACTLY this problem (including myself). I saw a few emails on EXMH mailing list too. I think it's some corrupted email you get. Lock file is set by EXMH, once inc is done, it's supposed to be removed. You can incorporate email by running nmh inc from xterminal (not from EXMH). It'll work, but there will be no filtering, everything will end up in inbox. It happended to me in libc6 problems period in slink, did not see that again. So far I did not see reasonable explanation for that phenomena, on EXMH list too. Sasha.
