[Nmh-workers] Patch: backup prefix assumption corrections
Attached is a patch to fix the previously reported test errors that
had hardcoded , en lieu of `mhparam sbackup` I commented out the
existing test in test-mhparam, but could not figure out what environment
variable might contain the configured value to incorporate it into
the same heredoc test as everything else. However, since it is used
in so many other test via the backtick execution, it's arguably redundant.
Also, although I did not encounter this when building from the RC1
tarball, I started getting this error using my local clone:
*** /home/belg4mit/nmh/test/testdir/7912.expected Thu Apr 17 14:44:30 2014
--- /home/belg4mit/nmh/test/testdir/7912.actual Thu Apr 17 14:44:31 2014
***
*** 1
! /home/belg4mit/nmh/test/testdir/foo's bar
--- 1
! ~/nmh/test/testdir/foo's bar ~/nmh
./test/whatnow/test-cd: test failed, outputs are in
/home/belg4mit/nmh/test/testdir/7912.expected and
/home/belg4mit/nmh/test/testdir/7912.actual.
FAIL: test/whatnow/test-cd
It seems to be using the user's shell somehow, and I have cd aliased to pushd.
diff --git a/configure.ac b/configure.ac
index 932809a..487abec 100644
--- a/configure.ac
+++ b/configure.ac
@@ -47,12 +47,13 @@ AS_IF([test x$with_tls != x -a x$with_tls != xno],[
tls_support=yes],[tls_support=no])
dnl Set the backup prefix
-AC_ARG_WITH([hash-backup],
- AS_HELP_STRING([--with-hash-backup],[use # as the backup prefix (default:
,)]))
-AS_IF([test x$with_hash_backup != x -a x$with_hash_backup != xno],
- [backup_prefix=#], [backup_prefix=,])
+AC_ARG_WITH([backup-prefix],
+ AS_HELP_STRING([--with-backup-prefix=ARG],[use alternate backup prefix
(default w/o switch: ,)]))
+AS_IF([test x$with_backup_prefix != x -a x$with_backup_prefix != xno],
+ [backup_prefix=$with_backup_prefix],
+ [backup_prefix=,])
AC_DEFINE_UNQUOTED([BACKUP_PREFIX], $backup_prefix,
-[The prefix that is prepended to the name of message files when they are
removed by rmm. This should typically be `,' or `#'.])dnl
+[The prefix that is prepended to the name of message files when they are
removed by rmm. This will typically be `,' or `#'.])dnl
dnl What method of posting should post use?
AC_ARG_WITH([mts],
diff --git a/test/mhbuild/test-forw b/test/mhbuild/test-forw
index 771bec0..9829abe 100755
--- a/test/mhbuild/test-forw
+++ b/test/mhbuild/test-forw
@@ -27,7 +27,7 @@ EOF
}
draft=$MH_TEST_DIR/$$.draft
-draftorig=$MH_TEST_DIR/,$$.draft.orig
+draftorig=$MH_TEST_DIR/`mhparam sbackup`$$.draft.orig
expected=$MH_TEST_DIR/$$.expected
actual=$MH_TEST_DIR/$$.actual
diff --git a/test/mhfixmsg/test-mhfixmsg b/test/mhfixmsg/test-mhfixmsg
index d60b9d7..f39d63e 100755
--- a/test/mhfixmsg/test-mhfixmsg
+++ b/test/mhfixmsg/test-mhfixmsg
@@ -172,7 +172,7 @@ folder last /dev/null
run_test 'mhfixmsg' ''
check $expected $MH_TEST_DIR/Mail/inbox/11 'keep first'
cp $MH_TEST_DIR/Mail/inbox/11.original $MH_TEST_DIR/Mail/inbox/11
-check $MH_TEST_DIR/Mail/inbox/,11 $MH_TEST_DIR/Mail/inbox/11.original
+check $MH_TEST_DIR/Mail/inbox/`mhparam sbackup`11
$MH_TEST_DIR/Mail/inbox/11.original
# check backup with -file
@@ -180,7 +180,7 @@ cp $MH_TEST_DIR/Mail/inbox/11
$MH_TEST_DIR/Mail/inbox/11.original
folder last /dev/null
run_test 'mhfixmsg -file '$MH_TEST_DIR/Mail/inbox/11 ''
check $MH_TEST_DIR/Mail/inbox/11 $expected 'keep first'
-check $MH_TEST_DIR/Mail/inbox/,11 $MH_TEST_DIR/Mail/inbox/11.original
+check $MH_TEST_DIR/Mail/inbox/`mhparam sbackup`11
$MH_TEST_DIR/Mail/inbox/11.original
# check -reformat (enabled by default): addition of text/plain part
@@ -1082,7 +1082,7 @@ cp ${MH_TEST_DIR}/Mail/inbox/19
${MH_TEST_DIR}/Mail/inbox/20
run_test 'mhfixmsg 19 -normmproc'
check ${MH_TEST_DIR}/Mail/inbox/20 \
- ${MH_TEST_DIR}/Mail/inbox/,19 'keep first'
+ ${MH_TEST_DIR}/Mail/inbox/`mhparam sbackup`19 'keep first'
# check -rmmproc
diff --git a/test/mhparam/test-mhparam b/test/mhparam/test-mhparam
index 89bcb5d..845c86f 100755
--- a/test/mhparam/test-mhparam
+++ b/test/mhparam/test-mhparam
@@ -137,11 +137,11 @@ check $expected $actual
run_test 'mhparam formatproc rmmproc' ''
Test sbackup separately because it's only passed as a -D compile option.
-case `mhparam sbackup` in
- ,|\#) ;;
- * ) echo mhparam sbackup failed
-failed=`expr ${failed:-0} + 1` ;;
-esac
+#case `mhparam sbackup` in
+# ,|\#) ;;
+# * ) echo mhparam sbackup failed
+#failed=`expr ${failed:-0} + 1` ;;
+#esac
# check -component
run_test 'mhparam -component Path' Path: $MH_TEST_DIR/Mail
diff --git a/test/refile/test-refile b/test/refile/test-refile
index 645f4f1..5763f30 100755
--- a/test/refile/test-refile
+++ b/test/refile/test-refile
@@ -172,7 +172,7 @@ run_test 'folders -noheader' \
other has 6 messages (1-12).
TOTAL = 12 messages in 2 folders.'
-if test -f $MH_TEST_DIR/Mail/inbox/,3; then
+if test -f $MH_TEST_DIR/Mail/inbox/`mhparam sbackup`3; then
echo $0: refile -unlink failed 12
failed=`expr ${failed
[Nmh-workers] MIME-hooks
I've cobbled together some scripts to try to do some of what people have been wishing for Re: MIME handling. These hooks should automagically extract MIME parts to files in the same folder as the message, with the message number as a prefix that is updated across nmh operations. Note, however that the parts are not currently cleaned up if you have an rmmproc, since del-hook is not currently called in this case :-/ If you decide you like the expanded format, you could do something like: find Mail/inbox -type | xargs -n 1 mime-add-hook to expand old messages The initial release is here: http://pthbb.org/manual/software/MH/MIME-hooks.tgz P.S. I'm not sure why, but mime-add-hook is rather slow. This is annoying when sending messages, since it is triggered for drafts with Fcc; I have not tested this using a draft with 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
[Nmh-workers] mhisto
Nothing too fancy, but possibly of interest/use for some: http://pthbb.org/manual/software/MH/mhisto.pl Generates text-based histograms of folder contents by sender using perl's Text::BarGraph e.g; FOLDER SPAM Thu, 20 Feb 2014 11:44:15 -0500 173 TOTAL 2014-02-13 ( 7) ## 2014-02-14 (17) ## 2014-02-15 (21) ## 2014-02-16 (18) 2014-02-17 (32) 2014-02-18 (25) ## 2014-02-19 (22) 2014-02-20 (30) 2014-02-21 ( 1) ## 3 belg4...@ono.com 2014-02-13 ( 2) 2014-02-18 ( 1) ## 2 auto-invo...@quickbooks.com 2014-02-14 ( 2) [truncated] The per-sender graphs are scaled the same as the folder summary graph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] mhfixmsg suggestion
Would it be very difficult for mhfixmsg to have an option (maybe -reformat -reformat ?) to update the text/plain version in a message? Constant Contact only updates the text version of a newsletter when an administrator explicitly does so by hand. Consequently I often see out of date information unless I explicitly check the text/html part. Alternatively, if there were a tool in nmh that could strip out a part, I could have mhfixmsg build a new one. Thoughts? ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] rmpproc
Would it be possible to expose rmmproc as an option for rmm? I currently have my profile rmmproc set to rm, since in my shell rm is aliased to 'refile -normmproc !* +Trash' and empty is '/usr/local/bin/rmm +Trash !*; folder -pack' However this makes it difficult to have backups for mhfixmsg, and leads to some minor race conditions with my current mail config. I can work around these with loops or a dummy profiles, but the ability to specify rmmproc on the commandline could simplify things. (Maybe I should make empty 'rm `mhpath +Trash !*`; folder-pack' but there may be another reason rmmproc is rm I'm forgetting) Just a thought, though I understand if it seems like Yet Another Switch ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] configure --prefix problem with whatnow/post
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 post is installed in /usr/local/lib/ as per my configure... ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] configure --prefix problem with whatnow/post
Hmm, after remaking and installing (because I notced my attempt to change the hash backup to the delete-compatible .# in configure did not carry over, and manually tweaked config.h instead) the problem seems to have gone away?? * delete, a friendlier version of rm http://debathena.mit.edu/packages/athena/debathena-delete/ ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Installing NMH on Os X lion
And google says: http://www.mathworks.fr/matlabcentral/newsreader/view_thread/308154 Although apparently there can be other esoteric reasons: https://bugzilla.mozilla.org/show_bug.cgi?id=652364 But if this were Linux my first hunch would be you have the library installed without the dev headers, not sure if Macs separate the two. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] amusing bug in folder
if someone actually wants this behaviour let them type folder -recurse +/. He has effectively typed folder -recurse already, the only differnce is the implicit /, which is non-intuitive, but I imagine meant to allow root to read his mail on machines where his home is / ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] indexing
(As an aside, I really dislike grep and friends no longer coping well under ~/mail because of base 64 encoding, etc.) I usually use scan `pick -search` for that sort of functionality, but if that's not to your liking you might look at hacking on transparent base64 decoding to http://search.cpan.org/~petdance/ack-1.94/ ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Pick getting all addressees/senders
Don't forget that nmh commands use $0 to check .mh_profile for default parameters. To get a robust version of what you want (and allow for many other nifty things) nmh profiles/pick really only needs a syntax to reference arguments. You could: ln /usr/bin/pick /usr/local/bin/addressee and then add something like the following to your profile: #bcc search of locally composed messages addressee: -to %1 -or -from %1 -or -cc %1 -or -bcc %1 You could probably even provide such support with a generic shell script wrapper. e.g; script replaces positional notation with corresponding arguments. Hardlink this argument expansion script to the command name of choice, and have it invoke $0.bin, which is itself hardlinked to the original nmh command workhorse. Your profile line would just have to be named addressee.bin instead of addressee ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Hesiod
Yes, MIT still uses Hesiod. I do have access to an Athena account if there is no other platform available for testing. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] [patch] undo of install-mh (Debian bug #551704)
What's the point really? Two plain text files, documented in the FILES section of install-mh. Don't like'em, remove them yourself? Don't know what/where they are? Oh well, leave them alone. This isn't really a bug, and I'm not sure why nmh should bother with this for the pickiness of debian? ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
out the answers to all of these questions by themselves. Almost no-one downloads nmh.tar.gz and starts from that to install MH any more, and those who do, almost certainly know what they're doing and whether of not their system has statfs() or statvfs() or whatever today's remaining questionable portability issues are. False. I wouldn't know anything about stat*, but I have in the not-too distant past had to build my own nmh from scratch. For instance, MIT has historically been slow to update the default version on workstations, so I had a local copy installed in my home directory. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
Well, yeah, that is what I'm thinking about. Seems silly to have m_getfld call something that sort of looks like m_getfld but is different. Making it work down to all of the body parts would in my mind be architecturally better for nmh. But, as you say, more work. So why not create a new and improved but robust and backwards-compatible m_getfld by a different name to implement the new behavior? It can then be tested for awhile with the new features and once it proves reliable, replace the existing calls? (perhaps with an experimental build option for early adopters to do so now). It's a few more steps, but you otherwise seem to get the best of both worlds? Modern code for the future without discarding stable spaghetti of the present. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] cleaning out the cobwebs
(Could you explain ``having the tuits'', please.) Alas, this seems to be a glaring omission from the Jargon File. Whilst proscrastinating and/or busy, one might respond to the expected completion date of a new task When I get a round to it. Thus there are round tuits: http://www.google.com/products?q=round+tuit et cetera, and this case, a general lack of available tuits: a mythical unit of ability to do work ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Sent draft filenames
Hello all, What's responsible for the production of files named ,X? I get them in my regular folders, and posted drafts are renamed to this style as well. My system used to instead name sent messages .#X, which is compatible wth Athena delete, but has recently reverted to clogging my folders with the comma files. I've read through whatnow, send, post and mh-draft but no joy... My rmmproc is rm; but rmm is aliased to 'refile +Trash' Thanks in advance, Jerrad -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Sweetmorn, the 63rd of Discord, in the YOLD 3175: Economics is a disease --Hazel Henderson ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problems with slocal
I tried building nmh with both fcntl and flock (what Postfix uses for internal locking), but was not even able to inc until I went back to dot locks (what Postfix claims to want for external apps), and do have debian's liblockfile 1.08-3 installed Even when running slocal --debug -verbose from the command line with an even barerer maildelivery there is no joy: ~/ cat .maildelivery #FieldPattern Action Result String X-Spam-Flag NO qpipe R /usr/local/lib/rcvtty ~/ /usr/local/lib/slocal Mail/inbox/22 ... (delivering to standard mail spool) delivering to file /var/mail/belg4mit (mbox style), unable to open:\ Permission denied ~/ ls -l /var/mail/ -rw-rw 1 belg4mit mail 0 Feb 17 21:15 belg4mit I know Pete's don't do that, use a random spool is still an option. But it seems like a cop out from both what should work, and understanding why it doesn't... -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Setting Orange, the 45th of Chaos, in the YOLD 3175: D'ec'ed'e, mort, fichu. C'est un ex-perroquet. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problems with slocal
Thank you, that was it. There is a note about this in INSTALL that I did not see, but I think it could be more explicit. Whether or not liblockfile is available, configure only reports locking as dot, dot+liblockfile and dot only! possibly problematic would be more helpful. Alternatively, the package is LGPL, so why not include it with nmh? It's not obvious where people should acquire liblockfile, as there is no official site for it, and distro's often add weird deps. Luckily debian's 1.08-3 works. Incidentally, I noticed another place where configure isn't as a robust as it could be: it fails to accurately/detect report the presence of termcap. I configured nmh on this Centos 5 with termcap, but no termcap-devel and it went fine, but of course the make failed until the latter package was added. Thanks! -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Setting Orange, the 45th of Chaos, in the YOLD 3175: D'ec'ed'e, mort, fichu. C'est un ex-perroquet. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problems with slocal
Hmm, it still fails under postfix (though CLI is fine) with liblockfile drwxrwxr-x 2 root mail 4096 Feb 16 09:30 /var/spool/mail/ and I'd, of course, prefer to use the system mail spool... -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Setting Orange, the 45th of Chaos, in the YOLD 3175: D'ec'ed'e, mort, fichu. C'est un ex-perroquet. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] problems with slocal
Hey all, I'm trying to setup a really simple .maildelivery: #FieldPattern Action Result String X-Spam-Flag NO qpipe R /usr/local/lib/rcvtty default - file? /var/spool/mail/belg4mit for use with nmh 1.3 under postfix, but something's wrong: Command died with status 1: /usr/local/lib/slocal rcvtty is called, and the message is added to the spool, but it remains in the queue with the above error. If I execute slocal manually the file is processed, but the process hangs... -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Setting Orange, the 45th of Chaos, in the YOLD 3175: D'ec'ed'e, mort, fichu. C'est un ex-perroquet. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problems with slocal
I've discovered that slocal eventually times out (when run manually), and that it only hangs if the maildrop it would deliver to exists. If invoked with something like -maildrop /tmp/$USER, it exits immediately after processing .maildelivery -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Setting Orange, the 45th of Chaos, in the YOLD 3175: D'ec'ed'e, mort, fichu. C'est un ex-perroquet. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] bcc+fcc (again)
but I do think that the default should continue the current behavior. Why? It's clearly undesirable. What's bad about adding a new feature if the system forwcomp/distcomp strip bcc's, and a prominent notice is included in upgrade documentation. -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Prickle-Prickle, the 34th of Chaos, in the YOLD 3175: The more it stays the same, the less it changes. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] bcc+fcc (again)
Hello all, There've been several previous discussions about the matter of not destroying bcc in Fcc copies e.g; mail-archive.com/nmh-workers@nongnu.org/msg00843.html But nothing seems to have ever come of it. Having been recently been bitten by this, I thought I'd raise the issue again. Fcc is a personal copy of a message, and should contain at least as much information as the original draft (it should be a copy of a draft with date appended IMHO). If one blindly forwards without consideration of content, so be it. However, ought it not be possible to modify forwcomps to exclude any included bcc headers? -Jerrad -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Pungenday, the 28th of Chaos, in the YOLD 3175: Kick the baby. Don' kick tha baby... Kick the baby! ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: big thanks
I've wondered a few times if/how long mh/exmh will continue to live... how they'll do after the post-babyboomers pass. I think the cut-off is more likely to be gen-Xers than baby-boomers. MH used to be the default MUA at MIT until ~2000, which is where I picked it up. To this day, nmh is one of the first things I install on any new box. -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Prickle-Prickle, the 24th of Chaos, in the YOLD 3175: Think of it as evolution in action --Oath of Fealty ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
