Re: Why not document dcc:?
Hi, > A lot of us use the "dcc:" header field. It acts like "bcc:" does on > most other MUAs. Is there any reason not to add a paragraph about it > to the send(1) manpage? > > Comments? Votes? +1. Perhaps mention it in the fcc description as an alternative. I found fcc useless for my purposes; it's really handy to have the real message-id, etc. Cheers, Ralph.
Re: Patch for bug #3200 (with patch attached this time)
Hi Jeffrey, > You should mail the comments directly to him: > > Jeffrey C Honig <[EMAIL PROTECTED]> Done. > +/* > + * c_flags bits > + */ > +#define CF_TRUE(1<<0) /* usually means component is present */ > +#define CF_ADDRPARSED (2<<0) /* address has been parsed */ > +#define CF_DATEFAB (3<<0) /* datefield fabricated */ This looks wrong. Wouldn't 1, 2, and 4 be better values? Also, can FNORD be called repeatedly, i.e. does it insert a separator? It's definition didn't appear in the patch and I haven't the source to hand. Cheers, Ralph.
Re: Request for comment: update to mh-format.5
Hi, >A format string consists of ordinary text, and special >multi-character escapesequences which begin with `%'. s/eseq/e seq/ Cheers, Ralph.
Re: Solaris 'vim' configure bug
Hi, > if echo 'r /nonexist-file > q' | ex > > works but > > if echo 'r /nonexist-file > q' | ex > /dev/null 2>&1 > > hangs. > > Redirecting just standard output cause no problem. But there doesn't > seem any output to redirect anyway... Can you use strace on Solaris to see what ex is actually doing? Cheers, Ralph.
Re: Scan of folders with 10k+ messages?
Hi, I see we all chipped in to help Harlan, probably thinking no one else had yet. Is there any chance the mailing list can turnaround posts a little more quickly? $ s -nos lp | g '^Date' Date: Thu, 20 Feb 2003 10:48:49 -0800 Date: Thu, 20 Feb 2003 13:55:18 -0500 Date: Thu, 20 Feb 2003 12:06:09 -0700 Date: Thu, 20 Feb 2003 20:13:16 +0100 Date: Thu, 20 Feb 2003 11:25:23 -0800 Date: Thu, 20 Feb 2003 13:53:04 -0800 Date: Thu, 20 Feb 2003 23:41:27 + $ s -nos lp | g 'for [EMAIL PROTECTED];' for [EMAIL PROTECTED]; Fri, 21 Feb 2003 04:11:30 -0500 (EST) for [EMAIL PROTECTED]; Fri, 21 Feb 2003 04:11:37 -0500 (EST) for [EMAIL PROTECTED]; Fri, 21 Feb 2003 04:11:44 -0500 (EST) for [EMAIL PROTECTED]; Fri, 21 Feb 2003 04:11:48 -0500 (EST) for [EMAIL PROTECTED]; Fri, 21 Feb 2003 04:11:50 -0500 (EST) for [EMAIL PROTECTED]; Fri, 21 Feb 2003 04:11:53 -0500 (EST) for [EMAIL PROTECTED]; Fri, 21 Feb 2003 04:11:55 -0500 (EST) Cheers, Ralph.
Re: Scan of folders with 10k+ messages?
Hi Harlan, > 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? See scan's -form and -format options, and mh-format(5). In particular, copy the existing format file used by scan, e.g. /etc/nmh/scan.default, and change the `%4(msg)' to `%5(msg)' before making it your default using ~/.mh_profile. Sorry, that's a bit terse, but hopefully you get the idea. If not, come back. Cheers, Ralph.
Scanning an Empty Folder Doesn't Change Current Folder.
Hi, After many years of MH use, I recently did $ folders +inbox # inbox/foo showed up in the list $ scan @foo scan: no messages in inbox/foo $ rmf @.# since I don't want the empty folder no more. I soon realised what I'd done from the messages telling me that +inbox/bar wasn't empty, etc. But I still lost all my 80-odd mail messages in +inbox. There weren't even any ,* files since rmf doesn't leave those behind. I'd argue that scan should still change the current folder even if the destination is empty. Does anyone know the reasoning behind the current design? Also, I can understand why rmf must *really* remove the files since its ultimate aim is to rmdir their parent directory. But perhaps a multiple-pass approach would be better where it would first remove the mail messages by renaming to ,* then, if it looks and sees it can do the rmdir sucessfully because there isn't other stuff in the directory, unlink the ,* files before rmdiring the folder. That way I'd have had some ,* files to recover easily from. Alternatively, have rmf not do anything if it can tell it won't ultimately succeed. Good to see nmh activity's still happening. Cheers, Ralph.
Re: POP3 handling of long lines (patch)
Hi Nick, > > ps: I have absolutely no idea if there will ever be a new nmh > > release, or if anyone really still cares (and is able) to make cvs > > commits, I know I can't. > > So development of NMH is dead, then? Well, there hasn't been any signs of life for a while, so it may be. Which is a shame because November's _Linux Journal_ published my letter mentioning MH and nmh and pointing them at www.mhost.com/nmh and www.ics.uci.edu/~mh/book/. (See last letter on page 6.) Cheers, Ralph.
Re: [Fwd: Re: Questions about IMAP and sequences]
Hi, > > Well, the real crux of the problem is that there are some things > > that you simply cannot _do_ within the context of IMAP. The big > > one that comes to mind is annotations (there really isn't a way to > > modify messages on the server, from my reading of the > > specification). > > Ouch, that really bites. That was one of the first questions that > popped into my mind when I first started hearing about IMAP, but I've > been too lazy to find out if you could do that or not. The fact that > messages are individual text files is one of the biggest wins of nmh > for me. Me too. I reformat crappy emails with lines 120 chars long, delete large HTML duplicates that add nothing if I want to keep the mail, etc. Couldn't nmh develop into having multiple back-ends for different formats and cope with some formats not allowing some operations? Then anno on IMAP would gracefully fail. Ralph.
Re: [Fwd: Re: Questions about IMAP and sequences]
Hi, > 9) Subfolders!: IMAP supports subfolders. Should we? What would the > notation and data representation be? Any backward-compatibility > problems? Speaking of which, how would local caches be stored? In a > folder called "IMAP:[EMAIL PROTECTED]"? Yuck. Auxiliary files to keep > track of mappings? How do IMAP's subfolders differs from nmh's, e.g. `refile +inbox/tasks'. Or are you just saying nmh's IMAP support would include IMAP's subfolders? Ralph.
Re: FORW: Yahoo! Directory Support Response
Hi, > Well, after a long delay, I finally heard back from the Yahoo! > Directory Support department, which I emailed asking why they seem to > be refusing to list nmh. All they sent me was a form-letter with the > same info I already read on their website. Feh. > > I wonder who the #2 web directory is out there, and what their > submission policies are. I seem to remember there being a site > called something like "OpenDirectory", started by folks fed up with > Yahoo!, that allows unfettered link submission. I don't remember the > exact name or URL, though... #2? I was going to suggest the #1 directory site when this Yahoo stuff came up but I think nmh is already listed there. It's http://dmoz.org. (Directory Mozilla IIRC.) I always use it in preference to Yahoo which I find limited and out of date. Not surprising really if they have to pay people to maintain the index. dmoz.org's index is used by several other `web crawler' sites that like to have a directory available as well. Ralph.
Re: Off Topic: Text/ascii mh reader
Hi, > I read your mail with the 'show' command, which is part of 'nmh'. I > have defined my 'showproc' to be 'less', since I prefer that to the > default. I am using the 'repl' command to reply. It invokes the > 'vi' editor. This becomes even quicker once you tailor your shell with aliases or ~/bin scripts. s -- show a message n -- move to next message sc -- scan the last 20 messages ref -- refile messages inbox -- scan the last 20 messages in inbox If they're Berkeley mail users then they should be right at home with a command line interface. Why try and move them to a curses one? Ralph.
Re: Problem with Fcc
Hi, > execlp (fileproc, r1bindex (fileproc, '/'), > "-link", "-file", file, fold, NULL); > _exit (-1); > ... > fprintf (verbose ? stdout : stderr, > " errored (0%o)\n", status); > } > > so I guess the trick is to figure out what an octal "177400" as a > return value for pidwait() would mean. I'd guess that 0177400, which is 0xff00 is two values. The lower byte, 0x00, is the signal that killed the process; none. The upper byte, 0xff, is the exit value of the process; 255 or -1. That might be due to the _exit(-1) call following the execlp or it could be that the execlp succeeded and the fileproc program exited with -1. With the code written as it is we can't tell. It isn't sufficient to put an _exit() after a failed exec(). The value of errno should be output to stderr. Ralph.
