Re: pick question
Scott Lipcon wrote: Sorry to interrupt the good work thats going on with a user question, but I can't seem to figure this one out. How do I use pick to get messages that are in one sequence but not another, ie: sequence a is a subset of sequence b. I want to get the messages that are not in sequence a, something like: pick b -and -not a but that doens't work. I'm not on a system with MH right now, so I can't play around to check it... but I think you want to use sequence-negation. See the online MH book at http://www.ics.uci.edu/~mh/book/mh/morseq.htm#PreSeq . Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Why not document dcc:?
Robert Elz wrote: ... I would include a sentence or two about the risks of using dcc when really sending a bcc (as opposed to a cc to myself). Perhaps something like Note that the users listed in the dcc field receive no explicit indication that others who received the message are not aware that a copy was sent to them. This can cause blind recipients to inadvertently reply to all of the sighted recipients of the original message, revealing that they received a blind copy. On the other hand, a normal reply to a message sent via a bcc field will generate a reply only to the sender of the original message, it takes extra effort in most mailers to reply to the included message, and so would usually only be done deliberately, rather than by accident. Or perhaps an abbreviated version of that... Hmmm... we wouldn't want to actually *explain* anything in a manpage, would we? ;-) Seriously, that extra info looks good to me. We might be able to do without the last sentence, though; I think people will figure it out pretty quickly. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: default components file
On 1 July 2003 at 13:51, Bill Wohler [EMAIL PROTECTED] wrote:
Note that in replcomps, the Fcc only appears if you specify repl -fcc
+outbox. But then it does appear in the header.
...
Here's another idea that I sent to Glenn in a private message.
I'm not saying that it's better than any of Bill's suggestions;
it's just another idea. BTW, I tested it now (my Linux box is
back up) and it seems to work:
On Mon, 30 Jun 2003 10:19:58 -0700, Jerry Peek [EMAIL PROTECTED] wrote:
Glenn Burkhardt wrote:
Ok. replcomps already includes the line %{fcc}Fcc: %{fcc}\n%, so
I'll check the others if there's agreement for the change.
But, by default, that doesn't make an Fcc: copy, I think -- unless the
user puts something like -fcc +sent-mail on the command line. (I'm not
on Unix now so I can't check; sorry.) You could add that switch to the
default MH profile file, but I'm not sure people would like that?
Another possibility (though it might mean changing the explanation of
replcomps in the mh-format man page you just committed...) is to change
replcomps to have something like
Fcc: %{fcc}%{fcc}%|+sent-mail%
which (if I got the syntax right, which I can't check...) would output
any -fcc switch argument, else +sent-mail. Since the Fcc: would be
output regardless, I don't think the \n should be embedded in the string.
Jerry
Re: Solaris 'vim' configure bug
On 5 June 2003 at 15:40, Glenn Burkhardt [EMAIL PROTECTED] wrote: Advice? I feel our momentum slowing here; thanks for waking us up, Glenn. Let's avoid waiting six more months until Jon has to nag us again! There are a few problems, like the Mandrake ndbm.h file location, that don't sound too tough to fix. The longer we wait to release, the more little problems like this will come up. Maybe we should make a fix or two, release 1.1, and then post patches (or start pushing for nmh 1.11) as new OS versions dribble out. Should nmh be 100% perfect before it's released? (Am I a heretic or what? :) About the vi test: How about a compromise? Does it gain users a lot to have nmh test the editor's exit status and discard the draft on a nonzero exit? If the user or the editor has some kind of error, won't that be obvious to the user -- so she can type q d at the What now? prompt to throw away the bogus draft? (Does exmh or MH-E depend on this error-exit facility?) A half-baked proposal: Make the default to *ignore* the editor status and rip out the config code that tries to set ATTVIBUG. Add a note to the documentation or the configure script to say that, if you want this enabled, you should test your own editor and enable the test if you should. Is this too big a change to make on a dot-release? Or can we get 1.1 out the door soon? [I'm not an expert on software releases. Maybe we *do* need to wait. I'm just trying another angle, trying to stir things up.] Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Solaris 'vim' configure bug
On 2 June 2003 at 22:13, Glenn Burkhardt [EMAIL PROTECTED] wrote: if echo 'r /nonexist-file q' | ex /dev/null 21 It seems wrong to me to include a newline in the string this way. It could be re-written as: echo 'r /nonexist-file\nq' | ex /dev/null 21 Unless I'm missing something, both make exactly the same output: $ echo 'r /nonexist-file q' | od -c 000 r / n o n e x i s t - f i l e 020 \n q \n 023 $ echo 'r /nonexist-file\nq' | od -c 000 r / n o n e x i s t - f i l e 020 \n q \n 023 And the first one has the advantage that it should work on *all* Bourne shells and all systems, whether the particular version of echo will translate \n to a newline or not. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Scan of folders with 10k+ messages?
On 02/18/03 04:14 PM, Harlan Stenn wrote: I have a folder with more than 10k messages in it. Scan now displays these messages as ?nnn, where nnn is really digits. What do I need to hack to allow for a wider field? You need to modify your scan format file -- or, if you don't have one of your own, make a copy of the system file and hack yours. There's info in the online MH book; one place to start is http://www.ics.uci.edu/~mh/book/mh/morsca.htm#index2 . Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Scanning an Empty Folder Doesn't Change Current Folder.
Earl Hood wrote: On November 23, 2002 at 14:13, Jerry Peek wrote: About rmf warning you before removing a folder that isn't empty: you could write a little front-end script named rmf (put it in your personal bin, etc.). Have it run folder on the named folder (or, if there's no argument, on the current folder); if the answer isn't has no messages then prompt before actually running rmf. You could add the following to your .mh_profile to have it always ask: rmf: -interactive But I think that only asks whether you want to remove the folder. It doesn't warn you if there are messages in the folder. --Jerry
Re: The continuing install-mh saga
On 19 November 2002 at 16:35, Jon Steinhart [EMAIL PROTECTED] wrote: I'd like to see an indented scan that shows something like 5785+ 11/19 Eric Gillespie Re: The continuing install-mh sagaJon Steinhar .1 image/jpeg .2 image/jpeg ant then be able to do show/next/prev on stuff. This is only part of what Jon wants, but it might be useful to some people: use sort -m to merge the outputs of scan and mhlist. The way this works by default (with no tweaking from a little script) isn't perfect, but it's pretty good. Here's an example: $ scan last:4 scan.out $ cat scan.out 7767 U11/10 To:jpeek NYTimes.com Article: A New Platform for the New 7768 U11/10 To:jpeek NYTimes.com Article: Generic Version of Acne Dru 7769 U11/10 new_articles@info Stuart McClure Shares Web Security Tips for Syst 7770+U11/10 To:jpeek NYTimes.com Article: Bill Gates to Tour India Am $ mhlist last:4 mhlist.out $ cat mhlist.out msg part type/subtype size description 7767 text/plain2066 7768 text/plain1101 7769 multipart/alternative 29K 1 text/html 28K 2 text/plain 366 7770 text/plain6825 $ sort -nm +0.0 -0.4 scan.out mhlist.out msg part type/subtype size description 7767 text/plain2066 7767 U11/10 To:jpeek NYTimes.com Article: A New Platform for the New 7768 text/plain1101 7768 U11/10 To:jpeek NYTimes.com Article: Generic Version of Acne Dru 7769 multipart/alternative 29K 1 text/html 28K 2 text/plain 366 7769 U11/10 new_articles@info Stuart McClure Shares Web Security Tips for Syst 7770 text/plain6825 7770+U11/10 To:jpeek NYTimes.com Article: Bill Gates to Tour India Am Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Improving attachment viewing
Jon Steinhart wrote: If I get a message with 20 photos attached, I hate having to hit Ctrl-C 20 times just to get to the next message. I'm not disagreeing with you ;-), Jon... the interface *is* klunky. But, FWIW, Ctrl-\ will abort showing the current message. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Appropriateness of new program/feature
Jon Steinhart wrote: There's no good way to test whether or not nmh is installed. When I set up my program, I want to fail with an error message if the user hasn't set up a mail directory, etc. ... So, I'd like to add something to nmh to allow for installation testing. I think that the best way to do this would be to add a report-only option to install-mh. It's always bugged me that MH/nmh starts to install a new user setup if it can't find something it's looking for -- like the MH (.mh_profile) file. IMHO, it should simply fail and print an error message that gives the pathname of the MH file that it's looking for (that's either the setting of the MH envariable, or $HOME/.mh_profile). It could also tell the user how to install MH/nmh. The error could say something like: progname: aborting: can't read pathname-of-MH-file. Check your MH environment variable (if any) or run install-mh to install nmh. I haven't given a lot of thought to the implications, or to all the possible permutations (which problems cause install-mh to be invoked). Still, this method (telling the user to run install-mh if MH isn't installed) seems like a more sane way to handle the problem. Comments, anyone? Would this change break any front-end programs (mh-e, etc.) that somehow depend on the prompts that install-mh now prints by default? Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: refile changes cur
Moshe Kaminsky [EMAIL PROTECTED] wrote: I discovered that refile changes the cur message in the source directory to be the last refiled message. This means that cur will point to a message that no longer exists after refile is done. What is the idea? After rmm removes a message, cur also doesn't change. That makes command sequences like this possible: % show % rmm % next (or: show next) Maybe your question is more about the fact that, when refile removes *multiple* messages, it sets cur to the *last* message refiled, instead of the first? AFAIK, this is true of most nmh programs -- for instance, show 1 3 18 sets cur to 18. I think I remember some debate, years ago, about this behavior. The only conclusion I can remember, though, is if not the last message, then *which* message?. Comments, anyone else? Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: sorting messages by thread
Michael Richardson wrote: I hadn't thought of just refiling in the order like that. I rather like it, and I think I'll adopt your script. thanks. There were a couple of weaknesses in my simple script. You may know this already, Michael... but, partly for the record (and maybe for people who haven't seen much nmh scripting before) here's the script again, then a couple of tricks: for sequence in `mark -list | sed 's/:.*//'` do refile -link $sequence +inbox/sorted done PROBLEM #1: The script doesn't re-define the sequences in the destination folder. That's pretty easy to fix by adding an entry like this to the .mh_profile: Previous-sequence: pseq And use commands like this after the refile to copy the pseq sequence into a sequence with the original name, from $sequence: mark -add -seq $sequence pseq +inbox/sorted folder -fast +inbox The Previous-sequence entry can slow down nmh because it writes the pseq sequence after every change to any folder. So it might be better to have your script make a temporary .mh_profile file that's built from your default .mh_profile with a Previous-sequence: entry added. Point the MH environment variable to that temporary MH profile while the script is running: mhp=/tmp/MHP$$ cat $HOME/.mh_profile $mhp echo Previous-sequence: pseq $mhp MH=$mhp; export MH ...run nmh commands... rm $mhp PROBLEM #2: The script includes the cur sequence in the list of sequences it copies. You can fix that by telling sed not to print that sequence: for sequence in `mark | sed -n '/^cur:/!s/:.*//p'` or pipe mark's output through 'grep -v cur:', or something. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: sorting messages by thread
Michael Richardson wrote: Sorting by subject almost accomplishes what you want. I'd like to sort by sequence actually :-) Just a reminder to everyone: MH/nmh messages are stored in files, one message per file... so it's reasonably simple to write programs that rearrange the messages in whatever order you want. You also can use refile -link to create a temporary folder, or subfolder, with *links* to the messages in the order you want to see them. Using links means that the original folder isn't disturbed; also, the new temporary folder takes basically no disk space. For instance, Michael's sorting by sequence might look something like this in a Bourne shell script: for sequence in `mark -list | sed 's/:.*//'` do refile -link $sequence +inbox/sorted done then the +inbox/sorted subfolder would have links to (if I got that right; I haven't tested it!) all the messages from the first sequence followed by all messages from the second sequence, and so on. This beats sorting in traditional mail agents because they have to parse and rearrange a big file full of all the messages in a folder. Maybe this is obvious to most people on this list, but I thought I should point it out in case it helps. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: embedding whitespace in program name
Moshe Kaminsky wrote: How can I embed whitespace in a program name for nmh? for example, I tried setting Editor in .mh_profile to 'gvim -f' but when I run comp I get: unable to exec gvim -f: No such file or directory Maybe there's another way, but I think the answer I found was to make a little front-end script and use it. For instance, make a script file named mymheditor with these two lines in it: #!/bin/sh exec gvim -f $@ then set Editor to mymheditor. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Markup problems on the MH man pages.
On 25 July 2002 at 13:51, Eric S. Raymond [EMAIL PROTECTED] wrote: If you are not already considering it, please think about moving your documentation masters to DocBook (or some format from which you can generate DocBook). I've already thought of converting the online MH/nmh book (hosted at http://www.ics.uci.edu/~mh/book/ ) to DocBook. Unfortuntately, work on that book never seems to make it to the top of my long to-do list. Eric's project sounds worthwhile too, and (as an old troff hacker) I'd be a good one to help. But I've got the same problem with that as with the book: I'm not sure I'll get to it anytime soon. :-( Still, if other people are interested in working on this, maybe I can find enough cycles to help around the edges. Another idea that I had: as this conversion happens (if it does), maybe it would make sense to integrate the manpages with the book pages -- cross-linking the two and eliminating duplicate info. Ah, what a wonderful-sounding project that is! If you're interested, let's talk. ;-) Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
ImageMagick for displaying application/octet-stream
I just tried an experiment in my .mh_profile: #: eFaxes come as octet-stream (with filename=*.tif, but nmh ignores that?) #: ImageMagick exits gracefully if it can't figure out what type we have, #: so it seems like a good default show-er (for X, at least...): mhshow-show-application/octet-stream: %p/usr/X11R6/bin/display '%F' It seems to work pretty well on arbitrary application/octet-stream content. Even without seeing the filename extension, display seems to check the image header and do the right thing -- even with gzipped content, like gzipped TIFF files. Comments, anyone? Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Using web browser mail agent as nmh message viewer
On July 29, 2002 at 21:00, Earl Hood wrote: Jerry's message seems to imply that he wants to see the hole message in a manner similiar to a GUI client, with images shown inline and convenient links to attachments (which may have nothing to do with HTML). Right. Once in a while, it would be nice to have a multipart message shown in one continuous chunk when using the command-line nmh interface (which I always do), but this would probably require a custom pager. This is why I chose Mozilla's mail agent: it can take a whole multipart message and show all of it at once. (Mozilla is also more forgiving of some poorly-encoded messages that nmh complains about and quits.) I don't *always* need to see multipart messages in one window, so I have that smoz script for displaying messages in the cases where I need that behavior. I haven't found an easy way to do that with the nmh pager, which splits the message into its parts before handing each part to a viewer. One other reason I like to use the command-line interface first: a lot of the messages I get are just spam, and that gets obvious as soon as nmh shows me the first part. If I *don't* automatically use a whizzy HTML viewer, I can abort (by typing \^) as soon as I see that I don't want to read the message; it's quick and simple, and it doesn't allow web beacons or other spammers' tricks in the message to take effect. That said, I've learned some interesting stuff from other peoples' ideas of handling this problem. Thanks, all... Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Using web browser mail agent as nmh message viewer
Hi, all. All this discussion about hacking nmh has gotten me motivated to change my slacker's ;-) habits. Before I became a slacker, I used to always use MH/nmh to read and process mail from the command line (from a shell prompt). I love that flexibility, and the shell is the way I like to get work done in a hurry. But, these days, I get so much MIME mail with attachments... and nmh's MIME handling is so far from what I need... that I've been using the Mozilla mail agent to make the first cut at reading my mail, weeding out spam, etc... then using a script to pull the messages I want to keep from my Mozilla inbox into my nmh inbox, where I file them. Until now. I've decided to try going back to using nmh commands like show, rmm, etc. as my first-pass mail interface... and to use Mozilla's mail agent to display the MIME messages I want to see. (I know that I could also use exmh. But I typically keep two main windows open on my display: a tall terminal window and a stack of Mozilla windows. Also, Mozilla does a much better job of rendering web pages, handling links, etc. than exmh [used to do].) So I've written a shell script (see below) named smoz (send to Mozilla). It appends the specified message(s), or the current message, to a Mozilla mail folder. Then I can bring the Mozilla mail agent to the top of my window stack (if it isn't already there) and click on my temp local folder to see the messages that smoz appended. The basic way this works is: $ next (Message inbox:123) (header appears) part 1 text/plain 678 Press return to show content... ^\(kills next before displaying message) $ smoz(sends message to Mozilla folder; click on folder and read) $ (now I can use rmm, refile, etc.) This seems to work fine. (BTW, the script doesn't append ^M to each message line, as Mozilla seems to do for its other folders, but Mozilla doesn't seem to care.) I'm sending the script out in case it's useful to anyone else, or in case anyone has comments. I know that this is sort of a kludge, but I think it's a good start. Comments? Jerry [EMAIL PROTECTED] P.S. You can get the path to your Mozilla Local Folders folder by clicking on the folder and choosing the menu item Edit - Mail and Newsgroup Account Settings. BTW, I'm using Mozilla 1.1 beta. #!/bin/sh # $Id: smoz,v 0.2 2002/07/27 15:12:05 jpeek Exp $ # # smoz - send mail message(s) to Mozilla mail folder for display there # Usage: smoz [messagenums] # Absolute path of folder to append message(s) to # (NOTE: Name has a space. Watch quoting!) # (NOTE: This may change with each new Mozilla installation!) folder=/home/jpeek/.mozilla/default/y3kd03l3.slt/Mail/Local Folders/temp if [ ! -f $folder ] then echo `basename $0` ABORTING: can't find Mozilla folder (file) $folder exit 1 fi # Get absolute path(s) to message(s): case $# in 0) msgs=`mhpath cur` ;; # No arguments; use current message *) msgs=`mhpath $@` ;; esac # Make line like this: #From - Mon Apr 01 09:50:10 2002 dateline=From - `date +'%a %b %d %X %Y'` # Append messages; add From before and blank line after each one. # Note that output of loop is appended to the folder to avoid multiple opens. for msg in $msgs do echo $dateline cat $msg echo done $folder
Re: folder-specific defaults? [long]
Tobias Nijweide wrote: I've started to redo my patches to nmh, and have some questions on how people would like them implemented. This mail will ask some questions about the patch for per folder component/filter/etc files. Thanks for doing this, Tobias. BTW, it's great to see something happening with nmh again. 2 Where do we look for component files: a - If fixed path (Starting with '/', '~', './' or '../'), only one choice. b - Current, or selected folder c - Recursive search upwards from current folder, up to: d - User nmh directory e - /etc/nmh (or whatever is the value of nmhetcdir) I haven't actually tried your code, so I might be on the wrong track here... still, I've got some comments about c. Instead of recursive search upwards, can we assume that people who want to use this feature would simply make *links* (hard or soft), from whatever folders they create, into a master copy (somewhere) of the component files they want to use in that folder? It seems to me that a link is a fine way to propagate particular components files to the folder(s) where they're wanted. Using links (instead of a recursive search upwards) would also let people *block* the feature (and use the default components files in the nmh directory, I guess), in any particular subfolders where they want to. - I'm not sure what the impact of public folders would be. I have never used them, any ideas? Thanks for thinking of this obscure but useful nmh feature. As a sort of side question: do nmh hackers want/need a list of obscure nmh features to keep in mind as they hack the code? (I'm talking about features like public folders, private sequences, relative folder paths starting with @, etc.) This might be especially useful for nmh hackers from the exmh (and mh-e, etc.) worlds, where some nmh features may not be obvious or accessible. But back to your question: Public folders have different semantics than private folders do because, I think, they're intended to be accessed by many people. Sequences are treated differently in a public folder (they're not stored in a public-access file in the folder; they're stored in a particular user's own nmh directory), and I think it makes sense that components can be treated differently, too. Still, there *are* times when using components in a public folder would be good. For instance, we used to have a group of consultants who did bug-tracking and end-user consulting via a central mail folder. All new bugs and user questions went into that folder; whoever handled a bug would use anno to mark its state (accepted, replied, closed, etc.). And we all replied from the same central bug-tracking address, *not* from our own personal addresses. In a case like that, the *ability* to have a shared replcomps file would be nice. One sort-of-kludgey way to control this, folder by folder, is the way that private sequences are handled: by per-folder entries in each user's context. I'm offline now (on a laptop running Win98), so I don't have access to nmh. But private sequences are handled with an entry something like atr-cur-/prj/mail/bugs/inbox: 23 (That says: in the public folder +/prj/mail/bugs/inbox, *my* current message is 23.) Maybe there could be (optional) context entries for each component, something like atr-replcomps-/prj/mail/bugs/inbox: . meaning to use the components file in that folder (.) when your current folder is +/prj/mail/bugs/inbox. This is getting pretty complicated, so I'm not sure I'm adding anything to the discussion except confusion. ;-) Still, as you point out (in your final paragraph, thanks) it *is* important to think these features through carefully. I wish I had access to nmh from here! 3 - In my current version, for comp I change what happens when you use a +folder argument and no msg argument. Traditionally this means you use the current msg from that folder as a draft, in my version this just takes the component files from that folder. I can imagine this would break some things people are currently doing. I've never used this feature, but it seems to me that it was designed for flexibility and programmability. Maybe you want to have more than one folder for mail drafts: some drafts for use on each of your consulting jobs (say), and some for personal mail. Or maybe someone has programs that use this feature: a temporary drafts folder that's used only while a program is running, so it doesn't conflict with the user's main draft-folder. Some solutions? - Use a different flag (-compfolder? yuk) I guess I don't see what's wrong with -compfolder. It lets you specify exactly what you mean... and (I think) it could be abbreviated to -compf, so it's not that much to type. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Do you use (n)MH book? Should I maintain it?
Hi, all. I'm glad to see more talk about nmh. Richard mentioned version 2.0; that seems like a great chance for nmh to catch up with things that other mail agents have. I'd hate to see nmh die from disuse because it can't handle things like IMAP, new-ish MIME features, etc. Speaking of disuse, I'm wondering about the MH book I wrote years ago. It's still online at various sites, and it gets some hits... but I can't tell (easily) whether those hits are from real users or from robots. Would you please take 15 seconds now to send me a quick reply and tell me: - do you use the online book? (one word -- yes or no -- is enough). - if you do use it, how often? (one word, like daily/weekly/occasionally) If you want to add comments, that would be fine too. Thanks... Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Anyone home?
chad wrote: I would say that if you are interested and don't get a response in a reasonable time, a new SourceForge project may be in order. I'd suggest ``1 January 2002'' as a reasonable cut-off, Hi all -- How's SourceForge doing these days? VA Software isn't in the best shape now, I hear. I've been trying to find a big chunk of time to move the online MH book to SourceForge, but now I'm wondering if I might move it there and the server would go away. Comments, anyone? Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: [Fwd: Re: Questions about IMAP and sequences]
On 11 September 2000 at 15:01, "Dan Harkless" [EMAIL PROTECTED] wrote: multiple users sharing a single nmh folder (with unique sequences) has to be a pretty darn rare situation IMO, it's rare because people these days don't think of being able to do it; they're used to GUI mail front-ends that don't allow (?) this kind of thing. For instance, I've done that in two different companies where I worked in groups that used MH for bug tracking and etc. We'd have central folder(s) of bug reports that everyone accessed (and had their own current message, sequences of messages they were working on, etc.). We could use "anno" to make annotations that everyone could see (like assigning a bug and tracking its state). We could use the "mark" command to maintain our own sequences (by priority, "do today", etc.). "pick" was great for searching bugs and finding out who was working on which bugs. We had a central "bin" directory of scripts to make this easier -- and, of course, individual workers could write their own scripts. A central maintainer actually owned the bug folders, inc'ed new reports into them, refiled messages into archive folders when a bug was fixed, and so on. (Directory modes were set so only the maintainer could move messages out of the folders, but group-write file permissions let everyone in the group make annotations on the messages.) Etc. etc. Sure, there are more sophisticated bug tracking systems that do a lot more, but that's not my point. The point is that the flexibility in nmh makes seamless integration between "email apps" and "other apps" easy to do. In GUI environments -- especially ones that glop all the messages into a single file -- this sort of integration is a lot harder. This is why I'm writing my tomes ;-) about not losing nmh flexibility with IMAP, wherever it's reasonable to keep it. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Questions about IMAP and sequences
On 29 August 2000 at 21:54, John Reinhagen [EMAIL PROTECTED] wrote: 2. How important is order in an nmh sequence? The sequence is physically stored in one of two places: - the file named in the "mh-sequences:" nmh profile entry; that's typically a file named ".mh_sequences" in each folder. In this file, the sequence is stored on a long line (no newlines) starting with the sequence name. For example, a sequence named "temp": temp: 1295 1302 1310 1314 1327 1330 1334 1343 1348-1349 1369-1370 1375 ... (I put in the the ... to mean "this line continues"). - the file named "context" in the user's nmh directory (typically $HOME/Mail). In this file, a sequence is stored on a line starting with atr-seqname-folder-path. For example, the sequence named "temp" in the folder +m/nmh-workers is stored like this: atr-temp-/u/jpeek/Mail/m/nmh-workers: 3-5 7-8 10 15 18-19 30 46 51 ... In both cases, ranges of two or more contiguous message numbers are stored with a dash (-) separating the first and last message numbers in the range. If I remember right, the context file didn't used to have the full pathname of the folder if the folder was a subfolder of the user's MH (nmh) directory. Otherwise, the format of these files has been the same as long as I can remember (which is more than 15 years...). nmh utilities (for example, mhpath, forw, show, refile, scan, etc.) use these files to map the sequence names to their message numbers. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: nmh new mail notification
If you don't need notification right inside your xterm, Simon, you might look into an X-based utility like xbiff or xmailbox. They watch any mail file you tell them to -- for instance, the /var/spool/mail/simon file, the inbox folder (file) in Netscape, and so on. If you do need notification in your xterm, you'll need to do some checking of permisions and other things -- as Neil and Dan said. This is tricky stuff sometimes. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
