Re: [Nmh-workers] using maildir as mh mailstore
Why? What difference does it make if MH's mail store format is "non-standard"? If you ever need to export things there's packf (although some scripting may be necessary to handle nested folders) to get an mbox. You wouldn't just be sacrificing "esoteric features" of MH, but also much of ability to easily work with messages via standard tools, and the ability to intuit things about a message based upon its number. OTOH, a FUSE layer that did maildir to MH translation would be an easy way of getting IMAP support via the aforementioned Offline IMAP, and a layer going the other way to make MH look like maildir oughn't be too difficult. Maildir's all about integrity, and pulling all of that into nmh would be non-trivial. Or do you mean perhaps something that can read Maildir, but doesn't adhere to the specs? I'm still unclear as to what is gained. -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Setting Orange, the 30th of Chaos, in the YOLD 3176: How did it get so late so soon? It's night before it's afternoon. December is here before it's June. My goodness how the time has flewn. How did it get so late so soon? -Dr. Seuss ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] using maildir as mh mailstore
Sorry, a little more... Apparently somebody also thought it was a good idea though, and one of the top results from Google for nmh maildir is: http://www.jeenyus.net/linux/mdmh.html Where someone created some reimplementations of MH comamnds for use with maildir; the author seems to have drunk the Kool-Aid as to just how bulletproof maildir is though. Re: Past discussion http://www.mail-archive.com/nmh-work...@mhost.com/msg01224.html -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Setting Orange, the 30th of Chaos, in the YOLD 3176: How did it get so late so soon? It's night before it's afternoon. December is here before it's June. My goodness how the time has flewn. How did it get so late so soon? -Dr. Seuss ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Re: should nmh be an MTA or an MUA?
Specifically see the masquerade option and draft_from ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] set from
See the man page of mts.conf aka mh-tailor(5) nmh only permits fakefrom in certain configurations. If you have a configuration which permits it, you can simply include a From: line in your components files, otherwise such lines are ignored. -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Setting Orange, the 50th of Chaos, in the YOLD 3176. Celebrate Chaoflux!: Too la roo la roo la roo la r! ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] set from
> you can either: > - add your new From: header manually, when you > edit your draft (perhaps you can define an editor > macro to help with this), but this will become tiring. This repetition is not necessary. >A related approach uses shell aliases and the -form option: Also not necessary. See the FILES sections of the respective commands. comp automagically uses components, repl replcomps et cetera et cetera Even if it were necessary to define things with -form, you could do it in mh_profile rather than with aliases. -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Sweetmorn, the 51st of Chaos, in the YOLD 3176: When awful things happen to me, I try to imagine how Douglas Adams would be writing it if I were a character in one of his books. --chaoticset ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Pretty printing
RTFM... mhl + mhshow to display whatever portions of messages you want. Post-process for printing as necessary if |lpr ain't good enough :-P -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Prickle-Prickle, the 59th of Chaos, in the YOLD 3176: 1:37 is an excellent time. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Please proof-read chapter about MH/nmh
Section 4.4 Re: filters `pick` is a mail-aware grep-like filter I use it in a chain-like way via: alias pscan 'scan `pick !:*`' #tcsh One could argue that `mark` is also a filter. Section 4.5 Re: IMAP You should probably revisit the list discussion and include some of the points? For instance, most of those who spoke up seem to support falling back on the Unix Way and farming out IMAP support to some other tool, be that a FUSE layer or something else. Some IMAP features would not be readily available, but the general mailstore would be, at no cost to us... Re: habits exmh is not pretty, but mh-e has its followers, and is no worse (and indeed better for not tying up a terminal, just a buffer) than elm/pine/mutt. -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Boomtime, the 29th of Discord, in the YOLD 3176: ...and let me make this perfectly clear I AM NOT superman. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Unseen-Sequence not set with rcvstore
>I found the problem: for whatever reason I am not allowed >to choose `new' as a sequence name. >From mh-sequence(5): There is also a special "reserved" message name "new" which is used by the mhpath command. -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Pungenday, the 55th of Discord, in the YOLD 3176: Go away or I will replace you with a perl one-liner ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] vmh and other unused files
I do not think msh should be discarded. At worst, a build time option, but you never know when you might want/need it, so why not build it? It's a single, documented useful utility that provides a useful complement to packf. I've not had *much* call for it, but it's nice to know it's there if I do want to interact with a mail archive in a familiar way. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] vmh and other unused files
...although msh should SEE ALSO packf instead of bbc, and packf should point to msh; unless that's already been done in 1.4 ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] repl and mime handling
>If both text/plain and text/html is available drop text/html >(maybe configurable ?) You'd have to do this interactively, showing a snippet of each, with the option to specify it on the command line. Too many mismanaged mailing lists have nothing as their text/plain content other than "Your mail read is misconfigured, follow this link with tracking info" ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Line wrapping in mhl
>Thoughts? > >--Ken I don't see a license for par anywhere. Would it be feasible to include it as an optional but default part of the build? ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Line wrapping in mhl
Quoth Lyndon: >Par isn't part of nmh any more than 'less' is. My point was that if there's an existing tool we recommend deferring the heavy lifting to, particularly something that is not part of a standard *nx kit, maybe it should be included in the distro. Quoth Valdis: >given lproc and moreproc, isn't the MH way to do this something like >parproc? Probably fmtproc (formatproc) if fmt is standard , and then we can simply recommend par over fmt without actually bundling it... Might be worth mirroring though? ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.5 release, minor nits, and an open call to Jerry Peek
>I was under the vague impression that ORA gave Jerry back the book and Indeed, its now GPL: http://rand-mh.sourceforge.net/book/ ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.5 release, minor nits, and an open call to Jerry Peek
>- If there is a draft without a From that is fed to post, it will error erp? What sort from From is it going to require? I currently use From: me And it DWIM, while giving me the ability to quickly change it in a draft to another of my identities ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Changes to post
I agree with Tet, and considered saying the same thing (though less eloquently) last night... ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
This behavior is documented in the repl man page, from context it appears to be to support for custom editors (or the imaginary replproc) to do things w/o having to grok the MH message filesystem See comp(1) for a description of the -editor and -noedit switches. Note that while in the editor, the message being replied to is avail- able through a link named "@" (assuming the default whatnowproc). In addition, the actual pathname of the message is stored in the environ- ment variable $editalt, and the pathname of the folder containing the message is stored in the environment variable $mhfolder. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
An edge-case issue with @ be it in . ~/ or `mhpath +` is that it does not allow for multiple concurrent replies. Scripts should use the not-so-unintuitively named $editalt to inherit the correct context. Humans will have to live with @ pointing to the most recent message being replied to; assuming repl unlinks the first @, and unless editors have some way of the user accessing environment variables to determine which file to load**. Both of these points might be worth documenting? ** M-x getenv^Jeditalt^J ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
>I guess that I avoid multiple concurrent compositions of all
>sorts because it's painful because of the shared draft file
>unless one uses long options.
That's what .mh_profile defaults are for, and Jerry Peek's recomp ;-)
http://rand-mh.sourceforge.net/book/examples/mh/bin/recomp
The patch inlined below is for a slightly modified version with some
added conveniences.
--- recomp 2006-05-07 19:31:15.0 -0400
+++ mycomp 2012-03-15 18:51:00.0 -0400
@@ -1,18 +1,21 @@
-#! /bin/sh
-# $Id: recomp,v 1.9 1993/04/22 08:33:46 jerry book3 $
-### recomp - re-compose a draft mesage in MH draft folder
-### Usage: recomp [msgnum]
+#!/bin/sh
+# $Id: mycomp,v 1.3 2005-07-24 belg4mit$
+# Based on Id: recomp,v 1.9 1993/04/22 08:33:46 jerry book3
+### mycomp - optionally re-compose a draft mesage in MH draft folder
+### Usage: mycomp [msg]
+## mycomp -new
+## mycomp [comp options]
##
## WHEN YOU TYPE q AT A What now? PROMPT, IT LEAVES THE DRAFT MESSAGE
## WITHOUT SENDING IT. IF YOU HAVE A DRAFT FOLDER, THE COMMAND LINE
## YOU'D TYPE TO RE-COMPOSE THE DRAFT IS LONG, LIKE:
-## comp -use -draftm 3 -draftf +drafts -editor vi.
+## comp -use -draftm 3 -draftf +drafts
## ALSO, IT CAN BE HARD TO REMEMBER THE DRAFT NUMBER--SO YOU HAVE TO
## scan THE DRAFT FOLDER, THEN REMEMBER TO CHANGE YOUR FOLDER BACK.
##
## THIS SCRIPT HELPS WITH THAT. IF YOU GIVE IT A MESSAGE NUMBER IN THE
## DRAFT FOLDER, IT STARTS comp -use ON THAT MESSAGE WITH YOUR FAVORITE
-## EDITOR PROGRAM. WITHOUT A MESSAGE NUMBER, recomp scanS THE DRAFT
+## EDITOR PROGRAM. WITHOUT A MESSAGE NUMBER, mycomp scanS THE DRAFT
## FOLDER, THEN LETS YOU ENTER THE NUMBER OF THE MESSAGE YOU WANT TO
## RE-COMPOSE AND STARTS comp -use.
##
@@ -40,10 +43,11 @@
# PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGES.
+# NOTE TO HACKERS: TABSTOPS ARE SET AT 4 IN THIS CODE
draftf=+drafts # NAME OF DRAFT FOLDER
folopts="-fast -norecurse -nolist -nototal -nopack"
-mh=/usr/local/mh# WHERE MH PROGRAMS LIVE
+mh=/usr/local/bin# WHERE MH PROGRAMS LIVE
# THIS SCRIPT CHANGES CURRENT FOLDER TO THE $draftf FOLDER.
# SET TEMPORARY CONTEXT FILE SO OTHER MH PROCESSES WON'T NOTICE CHANGE:
@@ -51,7 +55,7 @@
MHCONTEXT=$tempctx; export MHCONTEXT
stat=1 # DEFAULT EXIT STATUS; RESET TO 0 FOR NORMAL EXITS
trap '/bin/rm -f $tempctx; exit $stat' 0
-trap 'echo "`basename $0`: Interrupt! Cleaning up..." 1>&2' 1 2 15
+#trap 'echo "`basename $0`: Interrupt! Cleaning up..." 1>&2' 1 2 15
$mh/folder $folopts $draftf >/dev/null || {
echo "`basename $0`: quitting: problem with draft folder '$draftf'." 1>&2
exit 1
@@ -61,20 +65,37 @@
0) # THEY DIDN'T GIVE MESSAGE NUMBER; SHOW THEM FOLDER:
if $mh/scan
then
-echo -n "Which draft message number do you want to re-edit? "
+printf "Which draft message to re-edit or cur [Enter] or (n)ew or
(q)uit? "
read msgnum
else
-echo "`basename $0`: quitting: no messages in your $draftf folder?"
1>&2
-exit
+msgnum="new"
fi
;;
1) msgnum="$1" ;;
-*) echo "I don't understand '$*'.
-I need the draft message number, if you know it... otherwise, nothing.
-Usage: `basename $0` [msgnum]" 1>&2
-exit
+*)
+$mh/comp $@
+exit $?;
;;
esac
-$mh/comp -use -e ${VISUAL-${EDITOR-${EDIT-vi}}} -draftm $msgnum -draftf $draftf
+case "$msgnum" in
+0) echo "comp: no messages match specification" ;;
+q) exit;;
+n|ne|new|-n|-ne|-new)
+$mh/comp -draftf $draftf -nouse ;;
+*[0-9]*|cur|last)
+$mh/comp -draftf $draftf -use $msgnum;;
+?*)
+$mh/comp $@ ;;
+*)
+# Blank entry selects current message, or last
+if [ -z $msgnum ]; then
+ msgnum=`pick cur`
+ if [ $msgnum -eq 0 ]; then
+ msgnum=`pick last`
+ fi
+fi
+$mh/comp -draftf $draftf -use -draftm $msgnum ;;
+esac
+
stat=$? # SAVE comp'S STATUS (IT'S USUALLY 0) FOR OUR exit
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] temporary files
>forever (and like Valdis said, exmh might use it). AFAICT, this has Then it should be updated to use $EDITALT, n'est-ce pas? (The dox use lowercase, but isn't convention for environment vars all-caps? Rather than proliferate switches, why not begin deprecating it, by first making it something that must be explicitly enabled in build? ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.5 release and better repl/MIME handling
Shouldn't take much more than #after opening for reading binmode(IFH, ':utf8'); #before writing binmode(OFH, ':utf8'); to fix your formatting script. If adding perl dependency, you'll need to require at least 5.6.1 for utf8, although 5.8 or better yet 5.10 would be preferable; perl may be up to 5.14 but plenty of systems are still running older versions, particularly as the default perl from the OS. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.5 release and better repl/MIME handling
>Yes, I think it does that. Bit annoying. Would be nice if it picked >the one that shipped the least bytes. Bytes schmytes, pick the one that's maximally human readable. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Anyone know of an UTF-8-compatible text formatter?
There's probably a perl module you could integrate into the script, rather than relying on par? Text::Autoformat for instance. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Feature Request: Comments in $HOME/.mh_profile
My long standing work around for this, is to use the profile entry # As in #:# #: System wide variables Aliasfile: aliases Draft-Folder: drafts editor: emacs #:# #: Program defaults ... Works like a charm ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Feature Request: Comments in $HOME/.mh_profile
>Maybe we should simply reserve # as a profile component and document "#:"
>as the .mh_profile comment character(s) rather than leave it as a puzzle.
Makes sense to me. If documenting, point out that you cannot have blank lines,
hence my use of "#:#" To separate blocks, although if someone were so inclined
they could also do "#:{" ... "#:}" :-P
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Feature Request: Comments in $HOME/.mh_profile
>I wouldn't document a separator as #:#. I mean, does the sh man page say I wonder if allowing empty values is something new? I suspect there must have been a reason I put that there, but then again I started out with MH 6.8 I never bothered to go back and check if I could save those odd bytes :-P ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Locking In Scripts and nmh Locking
>I'm willing to add an option to mark to suppress the >sequence name in the output of list. The DWIMmy thing would be to only output the name if *multiple* sequences are listed, but who knows what relies upon the current behavior? If not going the DWIM route, maybe -barelist? ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] misdocumented mark?
DEFAULTS '+folder' defaults to the current folder '-add' if -sequence is specified, -list otherwise The first default is true The second implies `mark -seq cur` should list the current sequence, which it does not (tested 1.3 & 1.5RC1) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] misdocumented mark?
>'mark -seq cur' defaults to -add, not list, because -seq is specifed. Doh, yeah... switch shortening, did not match in visual grep. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] [exmh-workers] Second release candidate for nmh 1.5 is now available
My $_ is bad, no lexicalization of $boundary is bad. If you must do it all in one fell swoop w/o pre-declaring $boundary use: local($_, $boundary) = ... ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] [exmh-workers] Second release candidate for nmh 1.5 is now available
$_ is a special global, you lexicalize these with local not my, especially if you want to be backwards compatible ;-) Although 5.8 is a bit old, it's still common and has good Unicode support, therefore as long as the changes to support are minimal I suggest it is well worth doing. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] [exmh-workers] Second release candidate for nmh 1.5 is now available
Sorry, by lexicalize I mean limit scope, since lexical specifically refers to my and our. FYI my($_) was introduced in 5.10 http://perldoc.perl.org/5.10.0/perldelta.html#Lexical-$_ ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] More than one parameters in .mh_profile
>Sure, it COULD do that. Sounds like you're volunteering to write >the code; great! :-) I hack perl, not C. I did quickly grep the perl code base for it though, but being on a tablet at the moment could not dive too deeply. nmh is non-GNU, but perl is dual-licensed under the Artistic License. >know ... that's actually not that much code to write and we already >have a space-splitting function (brkstring). What do people think >of that as a solution? Ahh, problem almost solved ;-) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] More than one parameters in .mh_profile
>In which case, couldn't they just do "sh -c whatever" as the thing that >would get passed to their login shell (i.e., csh)? It's a bit clumsy, >but it should work for the few people that are in that situation. Why do you want to use the user shell exactly? Yes, the user might be more familiar with its syntax, but it seems rather common in situations like this to go with the LCD and leave it at /bin/sh. This could also make support easier since it ought to narrow the options for surprises e.g; someone forgets to mention that their shell is actually zoidberg or some other esoteric thing. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] The third release candidate of nmh is now available
mts.conf is fairly important but rarely touched, so people may not recall what options they had set to get things working. I think clobbering it is bad. If not preserving the original, can we make the clobber happen late in the install and cat the current file to STDOUT for anyone who overlooks the "we don't do the normal thing with config files on upgrade" warning? ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] does dist work?
That's as designed, you're resending, as is, not forwarding. Did you enter the info and send? A more useful way to use dist is: dist -editor prompter ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhmail is now stable
A hyphenated switch (without long-opt beginning) seems awkard, can we add -H (a la curl) as a synonym? I might also suggest calling the header content a value rather than a body, for unambiguity's sake. Cheers! ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhmail is now stable
>nmh doesn't have any other - switches, either. ... >The switch can be abbreviated to -hea(derfield) Fair enough >> I might also suggest calling the header content a value >> rather than a body, for unambiguity's sake. >We have the RFCs to blame for that. I'll update the I suspected as much, I guess they were expecting more recursive use, or simply did not think of the confusion that could occasionally result :-P ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mime-aware filtering?
nmh tools ignore non-numeric filenames, doesn't it? A possible way to solve the access to MIME parts problem might be to store the parts as messageNumber.partNumber* Creation of these parts would be optional, and eat space, but it would make indexing/grepping easy. It seems you'd just need a demultiplexer (we have one already, it just names things a bit differently), and for rmm plus refile to handle parts if present. That would be sufficient for things to function I think, but optional features might be for (mh)show, to use the pre-decoded parts if present, etc. Would this not be a workable solution for some of our common woes? *Maybe msg.part=filename if supplied ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] More than one parameters in .mh_profile
Could nmh not do with such parameters what perl does for system()/exec(), auto-splitting the string? In the off chance that someone's installed binaries in a path with a space they can escape the space, same as they would in a shell... ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mime-aware filtering?
You seem to have misunderstood my proposql. Paul, Message 76 would still be what came over the wire, however something like mhstore could optionally make 76.* as the split out compoents Tet, nothing in what I wrote implied you couldn't have 76.1.1.4 grep's, not going to care. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mime-aware filtering?
Sorry for the premature reply. I see now that Paul did understand my idea. I can underatd that some might not want duplicate content, but that's what I proposed it be optional. A temporary cache does not allow for indexing. Keeping it in Mail means you have whichever decoded messages you want greppable/indexable; be it done to all on inc, or manually for a select few. Then, when you remove them message, the parts get automagically wiped out by rmm. refile & rmm are the only things that need to be aware of this AFAICT. It could probably all be done with scripts if there was a refileproc profile component (presumaably passed source folder, dest folder, msgnum[s]), although it may take some effort to bend mhstore to these ends. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mime-aware filtering?
>as an unfortunate and unnecessary burden on code whose assumptions have >been valid for a long time. But it's still an assumption, and we know what those mean. More seriously though, is there an actual spec for MH declaring what valid folder and filenames are? What's the worst-case for those using older software with assumptions? They see sub-folders, all ending in .mime, with no valid messages within them. Annoying perhaps, but not fatal. It could actually be useful, because parts that are valid messages could be linked to a valid filename for them to access. Making MIME directories dotted is a work-around, but that's a bit of an annoyance for things/users wishing to access to them, depending upon the languages available to you e.g; having to be sure to exclude . and .. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] new nmh broken?
It's not broken, read the diagnostics and follow the directions provided. You have to supply a From now ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] new nmh broken?
>I would have expected the upgrade to install the appropriate components >to not break things. In which case it would likely break things in other ways, or not do the right thing for some individuals. Making specific changes to a template of unknown content is fraught with peril. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh-1.5 rcvdist fails
I use rcvtty actually. It was the closest I could come, with minimal effort, to replicating the mail zephyr class used at MIT :-P .maildelivery X-Spam-Flag NO qpipe R "/usr/local/lib/rcvtty -form rcvtty.format" ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Help extracting mime parts from a message
You want mhstore, mentioned in the See Also of mhshow mhstore (1) - store contents of MIME messages into files ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] NMH Work-arounds for Exchange server mangling (OT???)
Sending files as ".exe" is probably not the wisest way to work around things either, as you wil fall afoul of virus heuristics. ".bin" seems to be the more conventional way to approach this. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Clearing `cur' Message.
I would have thought `mark -seq cur -del` would work, but it does not. That would seem to be the logical command to use? nor does `mark -seq cur -del cur` nor `mark -seq cur -del #` ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
>I'd probably use it. Though I've been trying to rely more on pick >and less on message numbers. You might vpick useful for certain use cases http://pthbb.org/manual/software/MH/vpick.html I find the following incantation especially useful: vpick -seq unseen -cull -new That only shows you unseen messages, defaults to having messages selected, and creates a sequence named vpick with the marked messages on exit. Thus you can skim your unread messages, unmark those you want to save for later, and then `rmm vpick` ;-) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
>Apparently it is, but what is it supposed to do? It's a bad list because your cur was > 9. Try: pick 1; pick cur-9 ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
I don't really understand how relative numbers are useful, but if they are to be introduced why not use the same signifier as for folders? i.e; @ cur@2 = cur+2 cur@-4 = cur-4 This could also prevent some confusion as to why we are using something with a clear meaning (+) for such an odd purpose... ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
>Perhaps Jerrad was referring to `@' being used instead of `+' for >relative folders. You are correct sir. If it's not in the man pages, it must have been something I picked up from the Jerry's MH book. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
>>> folder +inbox >>> refile @example last# Means +inbox/example. >>> huh. i believe you, but you might have just found a bug in >> the man pages. :-) i can find no mention of such a feature. > volunteers? I can try to tackle this tomorrow evening. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] relative message numbers?
Documenting @folder is a little tricky since nmh man pages are written as prose. rather than bulleted lists explaining each of the options like many other packages. My best whack at it would be to: 1) Insert into nmh.1 near: Commands which take a message number as an argument ( scan, show, repl, ... Commands which take a range of message numbers ( rmm, scan, show, ...) something like the following: Commands which take a folder name (inc, refile, scan, sortm, ...) will accept the folder name in two formats: '+folder' and '@folder'. '+folder' specifies a folder underneath the Path defined in your nmh profile e.g; with the default '''Path: Mail''', '+folder' tells nmh to use ''~/Mail/folder''. '@folder' specifies a path relative to the current folder specified in your ''context'' file e.g; with '''Current-Folder: inbox''', and the same profile, '@folder' tells nmh to use ''~/Mail/inbox/folder''. It might also be worth insertng into the CONTEXT heading of the relevant commands (inc, refile. scan, sortm, etc.) a blurb along the lines of: The current context is used to expand relative folders supplied with the prefix @ instead of +, by prepending it to the specified folders. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Documenting @folder WAS Re: relative message numbers?
>Is `scan +/tmp/foo' documented anywhere, i.e. the ability to treat any >directory as a folder, not just one under Path? And `@..' after that.. Doh. Was planned but slipped my mind. Here are revised versions. 1) Insert into nmh.1 near: Commands which take a message number as an argument ( scan, show, repl, ... Commands which take a range of message numbers ( rmm, scan, show, ...) something like the following: Commands which take a folder name (inc, refile, scan, sortm, ...) will accept the folder name in two formats: '+folder' and '@folder'. '+folder' specifies a folder underneath the Path defined in your nmh profile e.g; with the default '''Path: Mail''', '+folder' tells nmh to use ''~/Mail/folder''. '@folder' specifies a path relative to the current folder specified in your ''context'' file e.g; with '''Current-Folder: inbox''', and the same profile, '@folder' tells nmh to use ''~/Mail/inbox/folder''. If folder begins with ''.'' or ''/'' when using ''@folder', the folder is interpeted as a specific path to a directory on the filesystem rather than a relative folder location e.g; scan @.` scans the current directory, and `refile @/tmp` refiles into the temp directory. 2) It might also be worth insertng into the CONTEXT heading of the relevant commands (inc, refile. scan, sortm, etc.) a blurb along the lines of: The current context is used to expand relative folders supplied with the prefix ''@'' instead of ''+'', by prepending it to the specified folders; unless folder begins with ''.'' or ''/'' in which case the argument is interpreated as a specific path to a directory. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] [PATCH] nmh.man: reorganize the command listing
For what it's worth, it make sense to me. The only draw back is that you cannot get an overview of it all in one screen. I might also suggest adding sub-headings for each action group. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Email access while traveling?
It's definitely practical on a tablet, Hacker's Keyboard + ConnectBot is very usable. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] colorized/highlighted scan output?
>Will do. Any suggestions on what to call the escape function? It sounds like a zero-width operator, though that's rather long. What about "hide"? ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] rmmproc Not Used for Lots of Messages; refile Copies.
My rmm is an alias: refile -normmproc !* +Trash Thus I can search back throug deletd mail. Whenever I notice such searching is slow, or the message numbers in the results are approaching 2000 I `empty first:800` or so. Empty is an alias: /usr/local/bin/rmm +Trash !*; folder -pack With rmmproc: rm It does not seem a particularly big problem, not being able to rmm/empty all or first:999+ The conventional way to indicate you want to accept input on STDIN is with an argument of '-', although grep uses -f and du --from0-file= to specify a generic file and recognizes - as STDIN. -file is available One would have to set the argument in one's profile, and rmm would have to open a pipe to rmmproc. NL terminated lines would cover the standard use case, but NUL (scripts can leverage xargs) would allow for some of the more exotic ideas of mixed-storage of MIME attachments that have been kicked around for future enhancements. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Garbage collection
>- Remove rcvtty completely. This works in conjunction with slocal or I would not be happy with that, I use slocal and rcvtty for (user-configurable) new message notification. My .maildelivery is: #Field Pattern Action Result String X-Spam-Flag NO qpipe R "/usr/local/lib/rcvtty -form rcvtty.format" default - + ? SPAM That gives me notifications iff a message is not flagged as SPAM, which is very nice. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Garbage collection
>Wow, ok ... I didn't think anyone used that, but I stand corrected. It >looks like what we did for OpenBSD was simply make rcvtty not work. Are >you fine with that? I'm not really interested in dealing with OpenBSD's >brokenness here. Fine with me, I usually run some flavor of Linux. Although it does seem odd that only a particular variant of BSD is having issues, in which case I suppose it might be fair to chalk it up to the system, document it, and forget about it until somebody cares enough to fix it... ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Message with non-existent Fcc directory
Failing out would be nice, as would be an option to edit. I often mistype an Fcc, and then hqve go trolling through drafts for the message to mv ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Pasing stdin to "inc -file" ?
The normal way to handle your second problem is to set $MHCONTEXT for the scope of your script. Admittedly, this is not listed prominently in an ENVIRONMENT section of most nmh man pages (not even nmh itself). As for the first, you might also look at slocal. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] message rewrite/fix up
Sounds great, where is it? :-P ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] message rewrite/fix up
Woohoo! Just downloaded and compiled master branch so that I could grab this. Incidentally, although attempts to autogen.sh will warn you about the minimum autoconf version (though it's not in INSTALL), there is no similar warning about automake version requirements. Instead, one receives a random warning about color-tests. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] message rewrite/fix up
CentOS 5 is on Automake 1.7, but I upgraded to build mhfixmsg once I figured out what the problem was... ___ 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
Ahh, yes, probably a dirty tree/funky dependencies. I extracted this evening's tarball over yesterday's build, but I would have expected a reinvocation of configure to force any necessary updates... however make has its own way with things :-P As for Lyndon's comment, yes, having things be in a normal path is why I was setting prefix, if I wanted everything about the package to be in its own filesystem branch I'd shove it in /opt ;-) YMMV ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Limit of 27 messages sequences per folder
>And I also think that nmh shouldn't have such a low limit on >the number of sequences. Even 59 is, or will soon be, too >low for someone. It'd be nice if we wouldn't have to Really? This might be a bit of armchqir quarterbacking... but it seems to me if you have 5 dozen sequences in one folder you're doing it wrong e.g; keep hundreds of messages in your inbox and using sequences like gmail labels rather than using folders, or have many temporary things can be handled with refile -link and rmf a la relative numbering. It might offend one's engineer sensibilities that sequences are limited, but on the flip-side there's something to be said for simplicity and the fact that the system works, no? Arbitrary and low limits from older system constraints should be updated of course, but why rejigger everything for a use case that nobody currently has? Nobody can have more than 27 labels, and it does not seem to have been an issue. If the ceiling can be doubled without effort that makes sense though. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
> $ scan unseen > ...notice that third-from-end message is spam... >$ refile unseen_3 +spam Seems delightfully error-prone and inefficient. Scan includes message numbers, rmm the specific message and there's no need to count lines of output. vpick might also be useful here? http://www.pthbb.org/manual/software/MH/vpick.html ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Relative Message Numbers
>digit message numbers. believe me, "p last_4" is much less error >prone than "p 365530". Sorry, I wasn't clear. The error-proneness wasn't due to typing, but in gauging which line of the displayed sequence was the message you cared about. Although I suppose those who love this mode of specifying messages might develop a scan format file that includes sequence indices in the output... ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Setup help???
See the man page for mh-tailor which describes the mts.conf options for the address masquerading you wish to do. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Date syntax
FTM
In addition to 822-style dates, pick will also recognize any of the
days of the week ("sunday", "monday", and so on), and the special dates
"today", "yesterday" (24 hours ago), and "tomorrow" (24 hours from
now). All days of the week are judged to refer to a day in the past
(e.g., telling pick "saturday" on a "tuesday" means "last saturday" not
"this saturday").
http://www.ietf.org/rfc/rfc0822.txt
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] IMAP, again
Wouldn't a FUSE IMAP layer largely solve the problem of conflicts by working on the live data store? Perhaps a customization of something like: http://imapfs.sourceforge.net/ http://www.sr71.net/projects/gmailfs/ ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] IMAP, again
>have to manage the mapping between MH message numbers and IMAP messages, >which involves a synchronization process. Also, it just seems like to Yeah, if I were doing it I'd probably not support all of MH's numbering and sequence goodness... for simplicity/sanity's sake. Just allow basic sortm to specify what field to sort on, and message numbers are auto- incremented as you enumerate through the box/folder; stored in a cache each listing for translation back to IMAP msg when issuing an nmh command. >me a filesystem is the _wrong_ idiom to access a remote IMAP mail store; >a whole lot of complexity when compared to something relatively simple >like OfflineIMAP. But people are free to prove me wrong! I don't see how having FUSE transliterate IMAP to MH folders is so different from having OfflineIMAP transliterate them to Maildir, they're both files and directories for local tools to work on? Anyways, it was just an idea, and if working on the live data doesn't solve some of the simpler conflicts it's a moot point; for the complex ones that remain uncracked by others, it sounds like a case of "Doctor, it hurts when I move my arm like this..." ;-) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] why " at "?
My guess is uucp, whichhad a ! delimited path, but there was still an intended recipient at a machine, but not @. ___ 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 feel about that like I do about Paul's rearchitecturing of the nmh >library: I think that's a great idea, my only concern is who, exactly, is >going to write that code? I don't have enough time on my plate to finish >the relatively straightforward things like RFC 2231 support; that's a huge >rearchitecturing. I don't want to discourage anyone from tackling a tough >problem; please, if you've got the time, go for it! Might one use mailutils as a starting point? Didn't it come up in a recent discussion that it was effectively a MH library with interface utilities? Not necessarily the same ones we're looking for, but the core is possibly a better starting point than scratch if one has no moral objections to the GPL. Purely speculation on my part... Although it looks like they've got an incomplete project to rearchitect things themselves http://mailutils.org/wiki/Mailutils-3 (The download server actually has 2.99.98 from March 2013, vs. the 2011 date of the wiki, and git shows recent activity by Sergey) ___ 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
>>Might one use mailutils as a starting point? Didn't it come up in a recent >>discussion that it was effectively a MH library with interface utilities? >>Not necessarily the same ones we're looking for, but the core is possibly a >>better starting point than scratch if one has no moral objections to the GPL. >You (or anyone else) are free to do that. Me? I lack the energy (I have >looked at it). I understand, was just tossing the idea out there for someone who was considering pitching in, to make the project seem more achievable. ___ 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
jp>> ... if one has no moral objections to the GPL. pv>i have a moral objection to the GPL. I should perhaps clarify, if *the one undertaking the effort* has no objection to the GPL. ___ 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
>maybe just using URIs and having the data accessed "on demand" would solve >this and also re duce message size. MIME already has this. It's nice in theory, but it doesn't get used. Among other things, it requires people to treat URIs as they're "meant to" (permanent identifiers), and also to maintain a publicly accessible resource server. Not to mention issues of the sender redacting a resource they "sent" after the fact. GMail's image cacheing is to protect users from tracking by spammers/phishers, while probably allowing them to do a bit more of their own info collection X-P As for your Universal Messaging Protocol, that is way beyon the scope of this list I think, although Jabber's probably a good place to start with it. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhisto
I've added some documentation (perldoc mhisto) and filtering features: You may specify a comma or pipe-delimited list of address (substrings) to be used in a regular expression to limit the set of per-sender graphs to be printed. The switch may also be given as a negated form --notfrom. If you wish to only produce the summary graph, supply a -from switch with a substring that will not match any address such as @@ http://pthbb.org/manual/software/MH/mhisto ___ 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
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
>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
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
>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. 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
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] MIME-hooks
Fresh updates: Switch to .mh_profile component for backup suffix Convert mime-del-hook to shell script; no more dependencies on multiple perl modules Add cur as default and sequence support for mymhlist UPGRADING Be sure to add a mimehook-bak component to your .mh_profile, this is the suffix used for the original received file before it's mhfixmsg-ed. If there is interest, it would not be difficult to support storing components in sub-directories, although doing so will make grepping, etc. more complicated for yourself. ___ 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] problem with mark zeroing out sequences
The only difference is ctxpath, which is to be expected since MHCONTEXT is set in one instance. I've also unsuccessfully tried a workaround of copying the sequence to another, then using mark -seq unseen tmpseq $MSGNUM ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
I suppose I could try, but I've not used a C debugger
Hmm, on a hunch I just discovered that somehow the call to mhstore
in mime-add-hook's for loop is the trigger... of course that's the
raison d'etre of the script :-/
Hopefully it's not too hard to follow:
#!/bin/sh
VERSION=0.05
#Diagnostic messages
DEBUG=0
#Backup message suffix
BAK=`mhparam mimehook-bak`
SLOCAL=`mhparam mimehook-slocal`
[ $DEBUG = 1 ] && echo -n "Processing message $1";
if grep -q -E '^MIME' $1 ; then
[ $DEBUG = 1 ] && echo " ...is MIME"
SRCDIR=`dirname $1`
MSG=`basename $1`
#Don't clobber main context
if [ -n $SLOCAL ]; then
export MHCONTEXT=`$SLOCAL`
[ $DEBUG = 1 ] && echo "slocal context $MHCONTEXT"
folder -fast +$SRCDIR >/dev/null
fi
for PART in `mhstore $MSG 2>&1 | awk 'match($0,/as file .+/){print
substr($0,RSTART+8,RLENGTH)}'`; do
[ $DEBUG = 1 ] && echo "Processing part $PART";
#Tweak -auto name to match message number
PARTDIR=`dirname $PART`
PARTFILE=`basename $PART`
if `echo $PARTFILE | awk "/^$MSG\./ { exit 1 }"` ; then
NEWPART="$PARTDIR/$MSG.$PARTFILE"
[ $DEBUG = 1 ] && echo "Renaming -auto part $PART to $NEWPART";
mv $PART $NEWPART
PART=$NEWPART
fi
mv -i $PART $SRCDIR
done
#DEFANG plain text
if [ ! -e "$1.$BAK" ]; then
[ $DEBUG = 1 ] && echo "Defanging MIME with mhfixmsg: backup in
$1.$BAK";
cp -i $1 $1.$BAK
mhfixmsg $1
fi
#Remark as unread
UNSEEN=`mhparam Unseen-Sequence`
if [ -n $UNSEEN ]; then
mark $MSG -nozero -add -seq $UNSEEN
fi
else
[ $DEBUG = 1 ] && echo " ...is NOT MIME"
fi
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
>Try feeding mhstore from a file instead of a message, something like: Alas, mhstore -file did not solve the problem; mhfixmsg already was using implicit -file, $1 is an absolute path Okay, some more odd evidence "WORKING" state w/o mhstore >From within mime-add-hook mark reports this, both before and after the -add cur: But cat .mh_sequences gives the following, before and after cur: 29 unseen: 23-28 pseq: 23-28 mark from the command line gives the following after, but matches cat before cur: 29 unseen: 23-29 pseq: 23-29 BROKEN with mhstore >From within mime-add-hook mark reports this, both before -add cur: ...and after cur: unseen: 30 But cat .mh_sequences gives the following, before cur: 30 unseen: 23-29 pseq: 23-29 ...and after unseen: 30 I seem to have found a workaround that works, even with the call to mhstore, although it still gives inconsistent ouput like above; with "pseq: 30" instead of "cur:" The workaround is including the sequence itself in the messages to add to the sequence i.e; mark unseen $MSG -add -seq unseen -nozero ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
kh>Are you using 1.3 (ewww), 1.5, or post-1.5 for your nmh implementation? 1.5+dev pulled from master on Monday (2/24) morning kh>Well, think about what's going on. You're changing sequences in the kh>middle of an operation which is changing sequences. At a minimum you're kh>going to be on the fringe of supported behavior. But other than the explicit calls to mark and Previous-Sequence, sequences oughn't be being touched...? And I thought commands were meant to open, close, reread sequences as needed rather than keep a long lock? This is add-hook from rcvstore, via slocal. Might rcvstore be keeping a lock on the sequence file for too long? It just occurred to me that what I previously thought was mime-add-hook running slow is probably the script waiting for filelocks; although `mhparam lockmethod` reports "none" (David says the last bit is a bug he's looking into) dl>> with "pseq: 30" instead of "cur:" The workaround is including the dl>> sequence itself in the messages to add to the sequence i.e; dl>> mark unseen $MSG -add -seq unseen -nozero dl>I don't see why that would be necessary. Don't I know it, but it works... ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
>My *intent* when adding the hook code was to allow external, non-nmh programs >to access the message store keeping track of changes. I added this code for >a specific purpose, and never thought about anyone executing nmh commands >inside of hook code. So I support Ken's conclusion that doing so is madness. I understand, and yet it's such a powerful way to extend the features of nmh without requiring core changes e.g; the supplemental MIME storage I'm using. Maddening as the sequence clash is, there's a workaround (though who knows when it might break, since it's not clear why I should work... my guess is it's akin to funky scoping like local $foo = $foo in perl). The thing that makes the least sense to me is that mark gives different results than cat, despite being run from the same environment/situation. P.S. It would still be useful to have environment variables exposed, and del-hook ought to let the child know if -unlink was used e.g; by setting the CMD to rmm-unlink instead of rmm ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
>Of course, if you want to CALL mark inside of a hook, then all bets are
>off :-) I'm unclear how we can make that better. I will note that rcvstore
>can add messages to specific sequences, and there was a deprecated feature
Nice! If that happens after add-hook we're 90% there.
The only problem is in this use case rcvstore is being called by slocal,
so how do you tell rcvstore what -sequence is?
Actually, from a cursory review of folder_addmsg, it looks like moving
if (unseen) {
set_unseen (mp, msgnum);
}
to after the hook invocation should clear things right up...
thus nmh commands can act on the being-added message without altering
its sequence status. I might have to make that tweak and see.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
>I can save you the trouble; that's not going to change anything. All
>set_unseen does is modify the sequence status bit vector in the folder
>structure. The locks don't get released until seq_save() is called.
Actually it did solve the problem.
Sorry if I was not clear, the idea of moving it was not lock related.
The overall problem is that calling nmh commands inside the hook script
was removing the message from the Unseen-Sequence*. Delaying that call
until after the hook invocation is complete ensures that whatever operations
are done in the hook, the message ends up in Unseen-Sequence after the
program exits :-)
* "zeroing out" was a misnomer, the sequence was not being clobbered,
rather each individual message was being added by nmh then removed by
the hooked script
Current situation:
slocal -> rcvstore -> folder_addmsg
set_unseen
add-hook
mhstore # Touches Unseen-Sequence despite being given -file
Patched:
slocal -> rcvstore -> folder_addmsg
add-hook
set_unseen (whatever happens in mhstore does not affect this)
Patch:
--- folder_addmsg.bak 2014-02-26 12:59:47.0 -0500
+++ folder_addmsg.c 2014-02-26 13:00:26.0 -0500
@@ -77,11 +77,6 @@
clear_msg_flags (mp, msgnum);
set_exists (mp, msgnum);
- /* should we set the SELECT_UNSEEN bit? */
- if (unseen) {
- set_unseen (mp, msgnum);
- }
-
/* should we set the SELECTED bit? */
if (selected) {
set_selected (mp, msgnum);
@@ -136,8 +131,19 @@
else
(void)ext_hook("add-hook", newmsg, (char *)0);
+ /* should we set the SELECT_UNSEEN bit? */
+ if (unseen) {
+ set_unseen (mp, msgnum);
+ }
+
return msgnum;
} else {
+
+ /* should we set the SELECT_UNSEEN bit? */
+ if (unseen) {
+ set_unseen (mp, msgnum);
+ }
+
linkerr = errno;
#ifdef EISREMOTE
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem with mark zeroing out sequences
Nope, not mixed versions, but your guess is as good as mine as to what's up. I can poke around some more in the next few days/keep my eyes peeled. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] General question - unsupported charset conversion
am>>In my personal opinion a very good choice is conversion into am>>html-entities, like ą or ł . It remains quite readable and am>>is still unique enough to convert it back in case of need. kr>Um, ouch. Unless there's a common library that already implements kr>that behavior, that's not on the table at all. Supposedly Recode does: http://recode.progiciels-bpi.ca/index.html ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
