From fdc@columbia.edu Wed Jan 9 20:20:43 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id UAA04634; Wed, 9 Jan 2002 20:20:27 -0500 (EST) Date: Wed, 9 Jan 2002 20:20:27 EST From: Frank da Cruz To: bug-mm@columbia.edu cc: kermites@columbia.edu, unixsys@columbia.edu, postmaster@columbia.edu, Vace Kundakci , Walter Bourne Subject: MM truncating problem maybe fixed? Bug-Report: Bug in Columbia MM, version 0.90.4(29) (SunOS) Message-ID: X-IMAPbase: 1133641346 253 Status: O X-Status: X-Keywords: X-UID: 1 Short story: I added some code to MM to address the truncating problem, and it *seems* to work. Long version: I spoke with Melissa about MM and found out where the latest (patched) sources were: /src/acis/ccmd/src /src/acis/mm/obj/solaris25 I made an ~fdc/mm/ directory on prost with mm and ccmd subdirectories. Copied all the files from the /src tree. Checked that they built OK; in ~/mm/ccmd: make -f Makefile.solaris solaris In ~/mm/mm: make -f Makefile.solaris This makes an MM 0.90.4(xx) binary: Columbia MM, version 0.90.4(24) Copyright (c) 1986, 1990 The Trustees of Columbia University in the City of New York Compiled by fdc@watsol on 9 Jan 2002 6:16pm Report bugs to bug-mm Now the truncating problem: The editor is run by mm_execute() in exit.c, which is just a fork() and execvp(). Then the upper fork calls wait_for_process(pid), which calls do_wait(pid, true), where "true" means "blocking". do_wait() might need looking at but first assume it works as advertised. Where is Howie's sleep()? Nowhere. I added an msleep() (millisecond sleep) routine to datime.c, for Solaris only. Uses select(). Builds without complaint. Then I added a chk_edit(filename) routine to edit.c, which sleeps for half a second and then in a loop, gets the size of the filename, compares it with the previous size, and if they are not equal, sleeps for 1/10 second and tries again, up to 25 times. If, after 25 iterations, the size still doesn't settle down, or some other bad thing happens, chk_edit() returns < 1. Then I found all the places in edit.c where mm_execute() is called with editor[0], and after each of these, I called chk_edit() on the temp file. If chk_edit() returns < 1, we set a trouble flag, which is supposed to inhibit deletion of the temp file. The very first time I tried it, I caught it in the act: (Exit from EMACS here) /p/kd/fdc/.mm-outgoing.25233: 0 6263 (BAD) /p/kd/fdc/.mm-outgoing.25233: 6263 6263 (OK) S> This seems to exonerate wait_for_process() (e.g. of killing EMACS prematurely). The messages won't appear unless there is at least one size mismatch. If the size doesn't settle down after 3 seconds (500 msec + 25 x 100 msec), it prints "Possible problem with edit, temp file saved: " and the filename. The results (for watsol = Solaris 2.5.1 Sparc) are in: /amd/prost/p/kd/fdc/mm/ Diffs are in: /amd/prost/p/kd/fdc/mm/ccmd/datime.c.diff /amd/prost/p/kd/fdc/mm/mm/edit.c.diff The executable is: /amd/prost/p/kd/fdc/mm/mm/mm I didn't notice any kind of edit history file, but a copy of this message is in ~/mm/NOTES.fdc. I'll be the guinea pig, feel free to join in; time will tell. - Frank P.S. The fact that the BUG command puts "SunOS" in the Bug-Report: header doesn't really mean SunOS -- the Solaris versions really are compiled for Solaris, but the real name of Solaris is SunOS. P.P.S. This message itself was truncated when I exited from EMACS, but the new code fixed it automatically. P.P.P.S. Melissa or Postmaster, I guess you can add me to the bug-mm list :-) From melissa@columbia.edu Thu Jan 10 09:40:23 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by kachifo.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA06411; Thu, 10 Jan 2002 09:40:01 -0500 (EST) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.9.3/8.9.3) id JAA12363; Thu, 10 Jan 2002 09:40:01 -0500 (EST) Date: Thu, 10 Jan 2002 9:40:01 EST From: Melissa Metz To: Frank da Cruz Cc: bug-mm@columbia.edu, kermites@columbia.edu, unixsys@columbia.edu, postmaster@columbia.edu, Vace Kundakci , Walter Bourne Subject: Re: MM truncating problem maybe fixed? In-Reply-To: Your message of Wed, 9 Jan 2002 20:20:27 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 2 Cool. > I didn't notice any kind of edit history file, but a copy of this > message is in ~/mm/NOTES.fdc. We kept track of the edit histories in RCS. e.g. cd /src/acis/mm/src, co -l edit.c, , ci -u datime.c, . The comment can be as long as you like; you can use "ci -u edit.c The executable is: > /amd/prost/p/kd/fdc/mm/mm/mm FYI, it's better to call your home directory /p/kd/fdc rather than /amd/prost/p/kd, because the latter will not activate amd to mount /p/kd if it is not already mounted (but it is always mounted when fdc logs in). > P.S. The fact that the BUG command puts "SunOS" in the Bug-Report: > header doesn't really mean SunOS -- the Solaris versions really are > compiled for Solaris, but the real name of Solaris is SunOS. Right, uname also reflects the name SunOS. Sun claims that Solaris is the whole operating system and all applications, while SunOS is just the kernel. --Melissa From fdc@columbia.edu Mon Jan 14 10:58:16 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id KAA27543; Mon, 14 Jan 2002 10:58:14 -0500 (EST) Date: Mon, 14 Jan 2002 10:58:14 EST From: Frank da Cruz To: bug-mm@columbia.edu Subject: MM updates Bug-Report: Bug in Columbia MM, version 0.90.4(43) (SunOS) Message-ID: Status: O X-Status: X-Keywords: X-UID: 3 Updates since last week: ------------------------------ Thu Jan 10 09:24:55 2002 Various refinements and tuning, #ifdef adjustment, message improvement, etc. The main impact of these changes is (a) there is always at least a 500-msec delay after returning from EMACS, and (b) if you return from EMACS with an empty file, there's a longer delay because MM has no way of knowing if the file is empty because it hasn't been written yet (this has happened to me many times), or because you really saved an empty file. read_from_temp(), which is called after every editor invocation, executes an fsync() on the file to forestall truncation, but doesn't. I suspect fsync() has no effect on a file open with O_RDONLY. The Solaris 2.5.1 man page suggests as much: ERRORS EBADF: fildes is not a valid file descriptor open for writing. although in Solaris 2.5.1 fsync() on a read-only file returns 0 and does not set errno. The Solaris 8 man page, on the other hand, says "EBADF: The fildes argument is not a valid file descriptor". I wonder if EMACS does an fsync(), and if it does, how can MM be reading partial files? ------------------------------ Sat Jan 12 15:25:07 2002 At some point in the last few years, MM started adding a blank line to the end of every message after returning from the editor. Off-by-one bug at the end of read_from_temp(), fixed in edit.c. Changed copyright date from "1986, 1990" to "1986, 2002". This makes it a bit more obvious that it is being maintained, handles Y2K, etc. I made this change only in misc.c to keep the differences small. ------------------------------ Sun Jan 13 11:34:11 2002 Changed #ifdefs around new code from #ifdef SOLARIS to #if defined(BSD) || defined(_AIX) || defined(SVR4), since (a) this is what is used for dttzone(), which depends on the same struct definitions (timeval and timezone) and functions (gettimeofday()), and (b) to include SunOS, which also has/had the truncating problem. datime.c, edit.c. But surprisingly, this did not pick up Solaris -- I assumed that defining SOLARIS would imply SVR4 but it doesn't, so I changed the #ifdefs for the new code to: #if defined(BSD) || defined(SOLARIS) || defined(SVR4) || defined(_AIX) But I did not change the #ifdefs around dttzone(). datime.c, edit.c. Tried building for SunOS: ccmd: "make clean; make sun" failed at link time, but then worked if I manually deleted ccmd.a, test.o, and skel.o and did "make sun" again. mm: "make clean; make" fails because of the hardwired SOLARIS definition in Makefile. Copied the Makefile out of /src/acis/mm/obj/sunos41 and used that instead and mm build ok. Tried building for Solaris 8 on newcunix in /p/kd/fdc/mm/solaris8/: ccmd: "make clean; rm -f ccmd.a test.o skel.o; make solaris" (ok) mm: "make clean; make" (ok) Tried building for HP-UX 11.00 but it bombed right away with undefined symbols. Didn't try fixing or building on AIX or anywhere else. In heavy testing and real use of MM over the past several days, I have not experienced a single truncation (normally I have 3-4 per day). However, after rearranging the code last Thursday, I also have not seen a single instance of the file size changing. The 500-msec pause appears to be sufficient, but the subsequent size-checking loop is still there as a precaution (e.g. for high load, memory full, swap-space low). I'd suggest the MM version number be bumped up and the new source replace the old source on the public FTP server. Where things are: These notes: /p/kd/fdc/mm/NOTES.fdc ccmd sources: /p/kd/fdc/mm/solaris25/ccmd/ mm sources: /p/kd/fdc/mm/solaris25/mm/ ccmd diffs: /p/kd/fdc/mm/solaris25/ccmd/*.diff (datime.c.diff) mm diffs: /p/kd/fdc/mm/solaris25/mm/*.diff (edit.c.diff, misc.c.diff) Solaris 2.5.1 binary: /p/kd/fdc/mm/solaris25/mm/mm Solaris 8 binary: /p/kd/fdc/mm/solaris8/mm/mm SunOS 4.1.3 binary: /p/kd/fdc/mm/sunos41/mm/mm ------------------------------ Other things on my list (that I'll probably never get to but who knows)... Maybe add a SET command to enable/disable chk_edit() since most people don't need it. Check and enable or fill in msleep() for other platforms. Character sets, when sending a message: . Don't strip 8th bit from text (what is 8th bit used for now?) . SET CHARACTER-SET (default US-ASCII), SHOW CHARACTER-SET . Add header: Content-Type: text/plain; charset="iso-8859-1" or whatever. . Add header: Content-Transfer-Encoding: 7bit (or 8bit) according to charset. MM shouldn't "do" anything with character sets, just let the user declare which one is used in the outbound message and not strip the 8th bit from text, Subject, or other header data characters. The SET CHARACTER-SET command would take a keyword list of MIME charset names for only those MIME charsets that are also internation standard sets (i.e. ISO registered), since it's impolite and antisocial to send email in proprietary character sets; an internal table tells whether each one is 7bit or 8bit. The commands and headers are easy, but figuring how to undo whatever is currently done with the 8th bit is hard. Slightly more ambitious tasks: . Add switches (cmswi()) to some of the commands; for example: COPY /APPEND /REPLACE /TEXT-ONLY . COPY and MOVE to pipelines. . Hooks to Kermit, e.g. COPY /DOWNLOAD . Allow definition of macros . Allow macros to accept parameters . Devise a way of accomplishing OR in message selection; currently conditions are all connected by implied ANDs. This would also require syntax for grouping. . Add an option that tells MM, when it reads a message and finds a charset header, to send the corresponding ISO 2022 escape sequence to switch the terminal into the character set used by the message or, if there is no charset header, to switch it back into its prevailing charset (such as Latin-1). Of course this can work only with standard ISO-registered character sets, not with (e.g.) Windows code pages or random MIME charsets, and only with ISO-2022 / ANSI X3.64 compliant terminals (e.g. VT220 or 320). The latter would require MM to have to several distinct charset settings: . The default (global) charset for sending . The default charset for reading (when message doesn't specify one) . A way to send a message with a given charset without affecting the global one (e.g. SEND /CHARACTER-SET:blah). . A way to tell MM, when replying, whether to automatically choose the same charset as the original message (again, without affecting the global outbound charset), e.g. REPLY /SAME-CHARSET or something, plus a global setting for whether this should be the default. Also: . Consolidate the various makefiles and make a master makefile that builds both ccmd and mm (or is there one that I missed?) . Clean up compiler warnings. . Check/update/fix ports to HP-UX, AIX, etc. Definitely NOT on my list: . Enclosures (if I want this I'll use another mail client!) . Desktop metaphors (folders, in-boxes, address books, etc -- ditto!) ------------------------------ - Frank From fdc@columbia.edu Wed Jan 16 17:59:36 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id RAA07712; Wed, 16 Jan 2002 17:59:30 -0500 (EST) Date: Wed, 16 Jan 2002 17:59:29 EST From: Frank da Cruz To: bug-mm@columbia.edu Subject: Not so fast... Bug-Report: Bug in Columbia MM, version 0.90.4(43) (SunOS) Message-ID: Status: O X-Status: X-Keywords: X-UID: 4 I hadn't had a truncated message in a week, but today I'm getting tons of them, using the same MM binary. The load on watsol is not especially high, so I can't imagine what's making it happen today but not the past week. Anyway, when it happens, there is no pause between EMACS exiting and the MM S> prompt, which means there must be a path through the code that I didn't catch. So let's not install any new MM's until I have a chance to track it down. - Frank From fdc@columbia.edu Mon Feb 4 18:00:31 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id SAA06554; Mon, 4 Feb 2002 18:00:27 -0500 (EST) Date: Mon, 4 Feb 2002 18:00:27 EST From: Frank da Cruz To: Melissa Metz Subject: Re: new MM? In-Reply-To: Your message of Mon, 4 Feb 2002 17:39:08 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 5 > If you haven't had any problems with the new MM, let's install it. I > just lost another message. Did your changes making it back to the > source tree? > Nope. I thought I had nailed it but I didn't. I'm losing messages galore today too. There is evidently some other path thru the code that I didn't find. But (like you) I've been too caught up in real-job stuff to get near it since then. But yes, it's driving me crazy too. It's obviously an excellent barometer of NFS performance... If I can't find the real problem (maybe the wait() isn't right? -- Maybe EMACS doesn't fsync() the file? maybe NFS doesn't care if EMACS fsync's the file...) maybe I'll add a SET TEMP-DIRECTORY command to make it use the local disk... - Frank From budd@cs.bu.edu Wed Feb 13 10:54:18 2002 Flags: 000000000001 Return-Path: Received: from cs.bu.edu (CS.BU.EDU [128.197.10.2]) by kachifo.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA04332 for ; Wed, 13 Feb 2002 10:54:17 -0500 (EST) Received: from csa.bu.edu (budd@csa [128.197.12.3]) by cs.bu.edu (8.10.1/8.10.1) with ESMTP id g1DFsGF14325; Wed, 13 Feb 2002 10:54:16 -0500 (EST) Received: (from budd@localhost) by csa.bu.edu (8.10.1/8.10.1) id g1DFsCx25331; Wed, 13 Feb 2002 10:54:12 -0500 (EST) Date: Wed, 13 Feb 2002 10:54:12 -0500 (EST) From: Phil Budne Message-Id: <200202131554.g1DFsCx25331@csa.bu.edu> To: fdc@columbia.edu, klh@panix.com Subject: Re: MM+CCMD (was Re: command-line completion) Cc: budd@cs.bu.edu, buuudd@cs.bu.edu Status: O X-Status: X-Keywords: X-UID: 6 I still use MM, if only occasionally for the "sort" command. The TOPS-20 feature I'd want to replicate would be using mmap() to access the mail file in-place so startup and quit run faster (I read mail on an old, slow Sun IPX). I remember mentioning this to Fuat and Melissa once at a Usenix, but I think MM development had wound down by that time, and I've never gotten around to doing it myself. I don't think GPL per-se is necessary, so long as the terms allow modification and redistribution. An open-source repository (CVS or otherwise) and someone to act as arbiter/editor would be great.... Another tool that might bear resurection is MRC's "MS" -- his CCMD-based MM clone that used the IMAP C-Client library. It was emasculated (due to the limits of IMAP), which is why he named it MS (the name used for the DEC-internal hacked version of MM). -phil From fdc@columbia.edu Wed Feb 13 10:55:23 2002 Flags: 000000000001 Return-Path: Received: by watsol.cc.columbia.edu (8.9.3/8.9.3) id KAA28936 for fdc; Wed, 13 Feb 2002 10:55:22 -0500 (EST) Path: newsmaster.cc.columbia.edu!panix!panix2.panix.com!not-for-mail From: klh@panix.com (Ken Harrenstien) Newsgroups: alt.sys.pdp10 Subject: MM+CCMD (was Re: command-line completion) Date: 13 Feb 2002 01:42:51 -0500 Organization: PANIX Public Access Internet and UNIX, NYC Lines: 65 Message-ID: References: NNTP-Posting-Host: panix2.panix.com X-Trace: news.panix.com 1013582572 13968 166.84.1.2 (13 Feb 2002 06:42:52 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: 13 Feb 2002 06:42:52 GMT Xref: newsmaster.cc.columbia.edu alt.sys.pdp10:21503 Content-Type: text To: undisclosed-recipients:; Status: O X-Status: X-Keywords: X-UID: 7 In article , Frank da Cruz wrote: >Gee, maybe it's time to gather up all the pieces and put it back together. >At Columbia, CCMD got the Y2K and y2K+1 patches (announced here) and that >was about the end of it. Would love to send my stuff in, at least. Note that the code is still copyrighted by Columbia and the notice says nothing about modification. If no one there has time to maintain it, perhaps you could spare a few cycles to get it GPL'd (or free-forked, etc) so that aspect doesn't hinder possible development or distribution by others. >Meanwhile I still use MM, as do other survivors from the DEC-20 era. >Recently Columbia migrated its user file system to humongous NFS servers, >and now we are all faced with the "NFS bug": Edit a message in EMACS under >MM, save the message in EMACS, exit EMACS, return to MM, find the result >truncated, sometimes partially, sometimes totally. EMACS has told Unix >(Solaris in this case, but it also happens elsewhere) to save the file and >then exits. Does EMACS do an fsync()? (I don't know.) In any case, since >this is an NFS disk, the file is written when Unix feels like getting >around to it AND when NFS feels like getting around to it, if ever, and MM >often reads it back before it is fully written. Hmmm. Have used MM+EMACS on NFS configs and seen this on other places, but can't recall it ever happening on Panix, which uses NetBSD NFS servers. >The problem is alleviated somewhat if you add a pause to MM at the point >where it gets control back from EMACS but before it reads in the temp file. >But since there is no way of knowing how long the pause must be, it can >(and does) still fail, no matter what you choose. > >On "bad NFS days", you can lose one message after another this way, so >I started adding code to MM to try to catch the situation and fix it, but >so far have not succeeded (it's only a spare time project and I don't have >any). I know Mark says NFS and Pine just don't mix and maybe the same is >true of MM and nothing can be done about it. You could try making it use temporary edit files on /tmp or /var/tmp, which normally are non-NFS dirs and have the 1000 ("sticky") mode bit set so only owners can delete/rename files therein. I don't remember if this still applies to Solaris though. At any rate, clearly this is fixable by conspiracy, with sufficient motivation; unfortunately I'm not an expert on elisp but I gather you can do just about anything with it, which presumably would extend to doing pipe or socket I/O. As an interesting note, the original PDP-10 EMACS (actually TECO) maintains its buffer pointers in a specific block pointed to by AC 2, precisely so superior processes are able to read out the contents directly from memory. This is how the QMAIL program snarfs things back on ITS; I don't remember if MM does the same thing on TOPS-20. >Once this is fixed, my list for MM includes: [...] >Actually I have much longer list but will probably never get to it so no >point including it. You never know. Now I'm wondering how many other MM users still exist, whether because they prefer the UI or because they want old mail files to remain accessible. --Ken From fdc@columbia.edu Wed Feb 13 10:57:10 2002 Flags: 000000000001 Return-Path: Received: by watsol.cc.columbia.edu (8.9.3/8.9.3) id KAA29327 for fdc; Wed, 13 Feb 2002 10:57:09 -0500 (EST) Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail From: fdc@columbia.edu (Frank da Cruz) Newsgroups: alt.sys.pdp10 Subject: Re: MM+CCMD (was Re: command-line completion) Date: 13 Feb 2002 10:55:14 -0500 Organization: Columbia University Lines: 69 Message-ID: References: NNTP-Posting-Host: watsol.cc.columbia.edu X-Trace: newsmaster.cc.columbia.edu 1013615716 29461 128.59.39.139 (13 Feb 2002 15:55:16 GMT) X-Complaints-To: postmaster@columbia.edu NNTP-Posting-Date: 13 Feb 2002 15:55:16 GMT Xref: newsmaster.cc.columbia.edu alt.sys.pdp10:21512 Content-Type: text To: undisclosed-recipients:; Status: O X-Status: X-Keywords: X-UID: 8 In article , Ken Harrenstien wrote: : In article , : Frank da Cruz wrote: : : >Gee, maybe it's time to gather up all the pieces and put it back together. : >At Columbia, CCMD got the Y2K and y2K+1 patches (announced here) and that : >was about the end of it. : : Would love to send my stuff in, at least. Note that the code is still : copyrighted by Columbia and the notice says nothing about : modification. : Don't worry about the copyright -- it's just a copy of the original Kermit copyright. Modifications and fixes gratefully accepted, just as they always have been with Kermit; just send 'em to me. [MM+EMACS NFS truncating problem...] : You could try making it use temporary edit files on /tmp or /var/tmp, : which normally are non-NFS dirs and have the 1000 ("sticky") mode bit : set so only owners can delete/rename files therein. I don't remember : if this still applies to Solaris though. : Right, this is one of the ideas on my list for next time I have a chance to work on this. I'm not sure I'm comfortable putting personal, possibly senstive email in /tmp, but no doubt that's just paranoia. Another is to simply not delete temp files -- but then there needs to be a way to refresh the current message from them in case the first time you read them in, they are incomplete. Also there needs to be a way to manage them. Currently they are named with the pid, but we'd have to extend that to pid + serial number or somesuch, and then delete them all upon exit. Many other possibilities exist... : At any rate, clearly this is fixable by conspiracy, with sufficient : motivation; unfortunately I'm not an expert on elisp but I gather you : can do just about anything with it, which presumably would extend to : doing pipe or socket I/O. : It should be fixable or at least work-around-able in MM itself. However, if EMACS does not do all in its power to flush saved files out to disk, that should be fixed too, but who fixes EMACS? But since the real problem is NFS, maybe there is no good solution except not to use NFS. : >Once this is fixed, my list for MM includes: : [...] : >Actually I have much longer list but will probably never get to it so no : >point including it. : : You never know. Now I'm wondering how many other MM users still : exist, whether because they prefer the UI or because they want old : mail files to remain accessible. : For the record, I use MM for its user interface and functionality. It does everything I want (with a few exceptions, mainly character-set stuff), and it does not insult me with desktop metaphors ("My Favorite New Mail Folder" etc). It totally ignores enclosures, which is exactly what I want a mail client to do. Most important, it does not make me take my hands away from the home keys. I'm a fast touch typer, and I mightily resent any application that does not let me go at full speed. I realize I'm a niche market :-) There are perhaps as many as 100 other MM users at Columbia. At this point, sad to say, I think I'm the MM maintainer. Sad only because I don't have the time to do it. Anybody who's interested in helping out, let me know and I'll make my current source available. - Frank From fdc@columbia.edu Wed Feb 13 15:05:03 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id PAA17147; Wed, 13 Feb 2002 15:04:59 -0500 (EST) Date: Wed, 13 Feb 2002 15:04:58 EST From: Frank da Cruz To: Phil Budne Subject: Re: MM+CCMD (was Re: command-line completion) In-Reply-To: Your message of Wed, 13 Feb 2002 10:54:12 -0500 (EST) Cc: klh@panix.com Message-ID: Status: O X-Status: X-Keywords: X-UID: 9 > I still use MM, if only occasionally for the "sort" command. The > TOPS-20 feature I'd want to replicate would be using mmap() to access > the mail file in-place so startup and quit run faster (I read mail on > an old, slow Sun IPX). I remember mentioning this to Fuat and Melissa > once at a Usenix, but I think MM development had wound down by that > time, and I've never gotten around to doing it myself. > Since our big nemisis today is NFS I'm not sure what mmap support would gain us. Plus it's not especially portable. Plus the newgroups are full of "I converted my program to use mmap() rather than read() and write() and now it's slowere than before!"... It will be a long time, if ever, before Unix catches up with TOPS-20 in areas like that. > I don't think GPL per-se is necessary, so long as the terms allow > modification and redistribution. An open-source repository (CVS or > otherwise) and someone to act as arbiter/editor would be great.... > Whatever. I've always steered clear of all that stuff, preferring to do everything by hand and by eye so I know what's been done. > Another tool that might bear resurection is MRC's "MS" -- his > CCMD-based MM clone that used the IMAP C-Client library. It was > emasculated (due to the limits of IMAP), which is why he named it MS > (the name used for the DEC-internal hacked version of MM). > I must have missed this one. But of course I remember DEC MS -- it was awful compared to MM, but the nice thing about was that it also worked in TOPS-10 because the command parsing was done with GLXLIB rather than COMND. - Frank From fdc@columbia.edu Wed Feb 13 17:36:57 2002 Flags: 000000000001 Return-Path: Received: by watsol.cc.columbia.edu (8.9.3/8.9.3) id RAA23489 for fdc; Wed, 13 Feb 2002 17:36:56 -0500 (EST) From: Neil Franklin Newsgroups: alt.sys.pdp10 Subject: Re: MM+CCMD (was Re: command-line completion) Date: 13 Feb 2002 20:53:56 +0100 Organization: My own Private Self Lines: 67 Message-ID: <6u1yfpupij.fsf@chonsp.franklin.ch> References: X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 13 Feb 2002 19:53:56 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 NNTP-Posting-Host: galapagos.ethz.ch X-Trace: pfaff.ethz.ch 1013629965 galapagos.ethz.ch (13 Feb 2002 20:52:45 +0100) Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!iad-feed.news.verio.net!iad-peer.news.verio.net!news.verio.net!newsfeed.cwix.com!newsfeed.nyc.globix.net!newsfeed.sjc.globix.net!hub1.meganetnews.com!DirecTVinternet!DirecTV-DSL!news-out.spamkiller.net!propagator-maxim!news-in.spamkiller.net!news-zh.switch.ch!pfaff.ethz.ch!chonsp.franklin.ch!not-for-mail Xref: newsmaster.cc.columbia.edu alt.sys.pdp10:21514 Content-Type: text To: undisclosed-recipients:; Status: O X-Status: X-Keywords: X-UID: 10 fdc@columbia.edu (Frank da Cruz) writes: > In article , > Ken Harrenstien wrote: > : > : You could try making it use temporary edit files on /tmp or /var/tmp, > : which normally are non-NFS dirs and have the 1000 ("sticky") mode bit > : set so only owners can delete/rename files therein. I don't remember > : if this still applies to Solaris though. root.murnau:/root 2> uname -a SunOS murnau 5.6 Generic_105181-29 sun4u sparc SUNW,Ultra-2 root.murnau:/root 3> la /tmp total 337 drwxrwxrwt 4 sys sys 442 Feb 13 20:23 ./ drwxr-xr-x 26 root root 1024 Nov 15 15:06 ../ Was still so in Solaris 2.6. I doubt it has changed in standard install. But it is removed on security concious sites (and all other sticky directories). > to work on this. I'm not sure I'm comfortable putting personal, possibly > senstive email in /tmp, but no doubt that's just paranoia. Generally one should be getting rid of /tmp anyway. Anything that requires an directory with the sticky bit is a security hole waiting to happen. Problem: malicious user does ln -s /etc/passwd /tmp/whatever then root uses an program that is known to write to /tmp/whatever. Instant broken user database. Or with different link any other root-only-writable file shot. Not to mention, that any modern Unix program should prefer $TMP to hardcoded /tmp. and $TMP is intended to be set to ~/.tmp/ or so, which will end up back on NFS. > Currently they are named with the pid, but we'd have to extend that to pid + > serial number or somesuch, and then delete them all upon exit. Use the Message-ID: field? > It should be fixable or at least work-around-able in MM itself. However, > if EMACS does not do all in its power to flush saved files out to disk, > that should be fixed too, but who fixes EMACS? The FSF owns it. Their website www.gnu.org surely lists maintainers for each program. > But since the real problem > is NFS, maybe there is no good solution except not to use NFS. Must be Solaris NFS client. The NFS protocol specifies that the server should only report back after it has flushed. One reason NFS is so slow. Perhaps Solaris client (or even your NFS server) has an "fix" for that, that does not wait for confirmation, which some "helpfull" admin has switched on. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual Robbery From mrc@CAC.Washington.EDU Wed Feb 13 20:43:07 2002 Flags: 000000000011 Return-Path: Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA16604 for ; Wed, 13 Feb 2002 20:43:06 -0500 (EST) Received: from mailscan-out2.cac.washington.edu (mailscan-out2.cac.washington.edu [140.142.33.17]) by mxout2.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g1E1h5MP020476 for ; Wed, 13 Feb 2002 17:43:05 -0800 Received: FROM smtp.washington.edu BY mailscan-out2.cac.washington.edu ; Wed Feb 13 17:43:05 2002 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g1E1h2jv006681 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 13 Feb 2002 17:43:04 -0800 Date: Wed, 13 Feb 2002 17:43:02 -0800 (PST) From: Mark Crispin To: Frank da Cruz Subject: Re: MM+CCMD (was Re: command-line completion) In-Reply-To: Message-ID: Organization: Pandamonium Reigns MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 11 On 13 Feb 2002, Frank da Cruz wrote: > Don't worry about the copyright -- it's just a copy of the original Kermit > copyright. Modifications and fixes gratefully accepted, just as they always > have been with Kermit; just send 'em to me. Consider the UW "free fork" copyright, as used in the IMAP toolkit (not Pine). It's much more free than GPL, yet it very definitely retains ownership. > It should be fixable or at least work-around-able in MM itself. However, > if EMACS does not do all in its power to flush saved files out to disk, > that should be fixed too, but who fixes EMACS? But since the real problem > is NFS, maybe there is no good solution except not to use NFS. Yup, NFS is a problem, especially if you use O_RDWR I/O on UNIX. > For the record, I use MM for its user interface and functionality. It does > everything I want (with a few exceptions, mainly character-set stuff), and > it does not insult me with desktop metaphors ("My Favorite New Mail Folder" > etc). It totally ignores enclosures, which is exactly what I want a mail > client to do. Most important, it does not make me take my hands away from > the home keys. So how is Pine unsuitable? I've been trying to understand why diehard MM users still use it and don't move to Pine, given all the effort taken to make Pine be the ideological successor of MM. The problem that I saw with Columbia MM was that it only tried to clone TOPS-20 MM instead of creating its successor. Foremost in all my IMAP work was to create something that an MM user would want to give up MM for. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. From fdc@columbia.edu Thu Feb 14 09:52:09 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id JAA27976; Thu, 14 Feb 2002 09:52:07 -0500 (EST) Date: Thu, 14 Feb 2002 9:52:06 EST From: Frank da Cruz To: Mark Crispin Subject: Re: MM+CCMD (was Re: command-line completion) In-Reply-To: Your message of Wed, 13 Feb 2002 17:43:02 -0800 (PST) Message-ID: Status: O X-Status: X-Keywords: X-UID: 12 Hi Mark. > So how is Pine unsuitable? I've been trying to understand why diehard MM > users still use it and don't move to Pine, given all the effort taken to > make Pine be the ideological successor of MM. The problem that I saw with > Columbia MM was that it only tried to clone TOPS-20 MM instead of creating > its successor. Foremost in all my IMAP work was to create something that > an MM user would want to give up MM for. > There's no accounting for taste :-) Pine is a great piece of work and 98% of Columbia shell account users use it, so it obviously appeals to many people. I, on the other hand, like MM better because (a) I'm very comfortable with it, having used it for 20+ years; (b) I really do not like menu-driven programs; (c) Desktop metaphors ("folders", "address books", etc) just really rub me the wrong way -- I know what a file is, I know what a directory is, I edit my .mminit file directly, etc. I can see all the effort that went into allowing Pine to be used without taking hands off home keys -- EMACS-style Control chars for navigating a menu, etc -- but I just don't like menus. That's just me; most people feel exactly the opposite. It's like Windows vs Unix: do you favor the novice or the expert? If you favor the novice, you piss off the experts; if you favor the expert, you'll only attract a small (but loyal) following. By the way, you might be interested that Columbia (not me -- I'm out of the management game -- just write software) has been trying its best to kill off shell accounts and just let everybody use Windows and Web browsers for everything. But users will not give up Pine. It still sees huge amounts of usage every day, perhaps partly for some of the reasons listed here (which also apply to MM of course): http://www.columbia.edu/kermit/safe.html Now to change the subject slightly, I see in Pine where it says: SPECIAL REQUEST: This software is made available world-wide as a public service of the University of Washington in Seattle. In order to justify continuing development, it is helpful to have an idea of how many people are using Pine. Are you willing to be counted as a Pine user? Pressing Return will send an anonymous (meaning, your real email address will not be revealed) message to the Pine development team at the University of Washington for purposes of tallying. As the manager of a Pine-like project, I wonder how UW views its Pine group. Columbia sees zero value in what we do and refuses to pay us for it, thus forcing us to sell licenses, etc, to support ourselves. Of course you and I remember a time when universities thought it was a good thing develop and support software that was used externally, but for Columbia at least those days are gone. Is UW more enlightened? Or does it get external funding for Pine work, or what? If you don't mind my asking, how many people are involved? - Frank From mrc@CAC.Washington.EDU Thu Feb 14 23:06:09 2002 Flags: 000000000001 Return-Path: Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id XAA19657 for ; Thu, 14 Feb 2002 23:06:09 -0500 (EST) Received: from mailscan-out2.cac.washington.edu (mailscan-out2.cac.washington.edu [140.142.33.17]) by mxout2.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g1F468eH021857 for ; Thu, 14 Feb 2002 20:06:08 -0800 Received: FROM smtp.washington.edu BY mailscan-out2.cac.washington.edu ; Thu Feb 14 20:06:08 2002 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g1F465jv023963 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 14 Feb 2002 20:06:07 -0800 Date: Thu, 14 Feb 2002 20:06:05 -0800 (PST) From: Mark Crispin To: Frank da Cruz Subject: Re: MM+CCMD (was Re: command-line completion) In-Reply-To: Message-ID: Organization: Pandamonium Reigns MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 13 On Thu, 14 Feb 2002, Frank da Cruz wrote: > There's no accounting for taste :-) True, but some effort has been put in to making Pine be something that MM users would want to use. > (b) I really do not like menu-driven programs; That isn't a valid criticism of Pine. Pine is modal depending upon what state you are in, but so is MM. The valid observation is that Pine has one-letter immediate effect commands, whereas MM has line commands comprised of words. This leads to an "alphabet soup" in Pine which MM avoids. "delete all" is certainly easier to learn than ";aad". However, I believe that Pine's metaphor of first selecting (and seeing) the messages affected and then doing the action is superior to MM's action first. In Pine, you don't have unpleasant surprises about what messages are affected, and you can do multiple actions on the same set of messages. > (c) Desktop metaphors ("folders", "address books", etc) just really rub me the > wrong way The IMAP specification and the IMAP toolkit use the term "mailbox" for this reason. I have fought a long battle against the word "folder" because it has other implications that I vehemently oppose; in particular, the concept that the same object must contain both mailboxes and messages (or, put another way, that the message and not the mailbox is the terminal node in the naming hierarchy). > It's like Windows vs Unix: do you > favor the novice or the expert? I use both continually. I don't favor either over the other. I think that Windows has a much better GUI (none of the X based GUIs turn my crank), UNIX has a better command line interface, and each system has its own strengths and weaknesses when it comes to programming. [Both have that idiotic sockets interface, grr.] > As the manager of a Pine-like project, I wonder how UW views its Pine group. > Columbia sees zero value in what we do and refuses to pay us for it, thus > forcing us to sell licenses, etc, to support ourselves. This has been a long-standing issue. I doubt that we will be giving away WebPine. We have the advantage of being: (1) a critical application (let's face it, as nice as Kermit is, it isn't critical) that tens of thousands of UW users rely upon. (2) a project personally founded by our director, and his pet project. (3) that director being the favorite of his superior who is at the university vice-president level. (4) our entire organization having a very good reputation, especially compared to its predecessor. (5) a state university, and thus expected to develop software to be used by other state agencies. The cost of funding Pine is less than the cost of cleaning up after the latest Outlook/Netscape/Eudora/whatever virus... ;-) > Of course you and > I remember a time when universities thought it was a good thing develop and > support software that was used externally, but for Columbia at least those > days are gone. Is UW more enlightened? It's a fortunate combination of things that would be difficult to duplicate. The dark side of the open source movement (Richard Stallman and cohorts) is doing an excellent job of seeing to it that such a combination won't ever be duplicated. RMS' attacks on us because of Pine's licensing were directly responsible for the demise of in-progress open source projects at a couple of our peer universities -- they didn't want to become the target of RMS venom. If you didn't hear about that; basically, we don't distribute PC Pine source, and we don't allow redistribution of modified Pine sources or binaries without permission from us. Proof to RMS that we are evil. The IMAP toolkit free-fork license (which is very different from the Pine license!) was a direct reaction to RMS. Not only is free-fork fully compatible with RMS' precious GPL, it is much more free than GPL *and* gives the original author more rights than GPL. *Snicker* > Or does it get external funding for > Pine work, or what? We may get some dough from outside to help fund our efforts on IMAP. But don't forget, we're a state agency, and a lot of our "outside" customers are other state agencies. > If you don't mind my asking, how many people are > involved? The e-mail development team consists of four dedicated programmers plus a part of: a fifth programmer, a documentation/bugtracker person, a web mistress, an assistant director, and a director. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. From fdc@columbia.edu Fri Feb 15 11:12:53 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id LAA21006; Fri, 15 Feb 2002 11:12:50 -0500 (EST) Date: Fri, 15 Feb 2002 11:12:50 EST From: Frank da Cruz To: pete@pwilson.net Subject: Re: Columbia COMND In-Reply-To: Your message of Fri, 15 Feb 2002 07:29:11 -0800 (PST) Cc: klh@panix.com Message-ID: Status: O X-Status: X-Keywords: X-UID: 14 > I haven't followed this discussion closely, or at all, for the > last couple of days, but I'd be glad to work to get the thing > GPLed. > GPL might not be the right choice. As you know, some people hate that license. But let's not get hung up on licenses. > Thing is, I'm planning to implement it (in C) for Unix and > Win32. > Implement what? You mean CCMD? It's already implemented for Unix (at least some brands of Unix, like Solaris). Porting it to Windows would require some work. Also it's all K&R (not ANSI) C, so you get a lot of warnings. But you can't just convert it to ANSIC because then it won't build with non-ANSI compilers, of which there are still many. Thus to make it more widely portable requires more and more #ifdefs, like in C-Kermit. See: http://www.columbia.edu/kermit/ckcplm.html#x3 > I'm following the description (SAIL-COMND Interface, > Andrew R. Lowry and David S. Millman, Columbia University, > Center for Computing Activities, User Services Group, 15 June > 1979) for that. But it would be awfully nice to have a look at > the _real_ docs, the actual PDP-10 code, for guidance. > I'm sure Tim has the COMND JSYS source (from the TOPS-20 monitor) lying around somewhere. If not, somebody else in the group is sure to. Also I'm sure Tim has the MCRM online, so you can read the manual for COMND, which as I recall was accurate. > Not sure what Ken's or Columbia's position is, but the code > certainly deserves to be kept alive, imo. And I just found out > that Dan Murphy lives about 10 mins from my front door. How > 'bout that? > Cool! As to Columbia's position -- I don't know. I doubt the code has any commercial value today, since nobody wants anything but GUIs, so perhaps it doesn't matter. On the other hand, I'm not a big fan of the school of thought that says people who write code must give it to rich companies to sell without getting anything in return. If that was rule I wouldn't be here, still programming after all these years. Very few people are paid to write free software, and yet programmers need food, medical plans, pensions, etc, like anybody else. - Frank From klh@panix.com Fri Feb 15 11:47:39 2002 Flags: 000000000011 Return-Path: Received: from mail3.panix.com (mail3.panix.com [166.84.0.167]) by kachifo.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA24837 for ; Fri, 15 Feb 2002 11:47:38 -0500 (EST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 4E9409821A; Fri, 15 Feb 2002 11:47:38 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g1FGlcj29911; Fri, 15 Feb 2002 11:47:38 -0500 (EST) Date: Fri, 15 Feb 2002 11:47:38 EST From: Ken Harrenstien To: Frank da Cruz Cc: pete@pwilson.net, klh@panix.com Subject: Re: Columbia COMND In-Reply-To: Your message of Fri, 15 Feb 2002 11:12:50 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 15 > > I haven't followed this discussion closely, or at all, for the > > last couple of days, but I'd be glad to work to get the thing > > GPLed. > > > GPL might not be the right choice. As you know, some people hate > that license. But let's not get hung up on licenses. Agreed. FWIW, I went with a "free-fork" license similar to PINE because I wanted to hang on to a shred of control for a little longer. > > Thing is, I'm planning to implement it (in C) for Unix and > > Win32. > > > Implement what? You mean CCMD? It's already implemented for > Unix (at least some brands of Unix, like Solaris). Porting it to > Windows would require some work. Also it's all K&R (not ANSI) C, > so you get a lot of warnings. But you can't just convert it to > ANSIC because then it won't build with non-ANSI compilers, of > which there are still many. Thus to make it more widely portable > requires more and more #ifdefs, like in C-Kermit. See: Are you sure? I was of the same mind for a long time, but recently realized all the platforms I cared about, even the little ones, had enough ANSI C constructs that it was no longer a problem, and converted all of my stuff to use ANSI prototypes. Saved my bacon a number of times as a result. I don't think I did much ANSI-fication of MM+CCMD, but have found enough bugs that I'm convinced it would help a lot. Kermit is in a somewhat different situation as it's a highly useful bootstrapping tool. MM on the other hand is almost certainly only going to be used by fairly modern systems, so I'm not worried about it. > I'm sure Tim has the COMND JSYS source (from the TOPS-20 monitor) > lying around somewhere. If not, somebody else in the group is > sure to. Also I'm sure Tim has the MCRM online, so you can read > the manual for COMND, which as I recall was accurate. I can probably dig up the source for the TOPS-20 version of CCMD so you can see the equivalents even more clearly. "Probably" means "I *should* be able to, but not sure how long it will take". > As to Columbia's position -- I don't know. I doubt the code has > any commercial value today, since nobody wants anything but GUIs, > so perhaps it doesn't matter. On the other hand, I'm not a big > fan of the school of thought that says people who write code must > give it to rich companies to sell without getting anything in > return. If that was rule I wouldn't be here, still programming > after all these years. Very few people are paid to write free > software, and yet programmers need food, medical plans, pensions, > etc, like anybody else. All that is really needed to start with is a little note clarifying it is OK to modify and redistribute provided all changes are given back to Columbia (which I'm sure is what was intended in the first place). The rest is more a question of "what happens when you are gone" -- ie when nobody is left at Columbia who cares, you want to be sure that anyone else who does care can still keep it going. --Ken From fdc@columbia.edu Fri Feb 15 11:55:40 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id LAA01592; Fri, 15 Feb 2002 11:55:37 -0500 (EST) Date: Fri, 15 Feb 2002 11:55:37 EST From: Frank da Cruz To: Ken Harrenstien Cc: pete@pwilson.net Subject: Re: Columbia COMND In-Reply-To: Your message of Fri, 15 Feb 2002 11:47:38 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 16 > > ... But you can't just convert it to > > ANSIC because then it won't build with non-ANSI compilers, of > > which there are still many. Thus to make it more widely portable > > requires more and more #ifdefs, like in C-Kermit. See: > > Are you sure? I was of the same mind for a long time, but recently > realized all the platforms I cared about, even the little ones, had > enough ANSI C constructs that it was no longer a problem, and > converted all of my stuff to use ANSI prototypes. Saved my bacon a > number of times as a result. > I confess I'm a portability fanatic. I build even the latest release of C-Kermit on 20-year-old platforms. > I don't think I did much ANSI-fication of MM+CCMD, but have found > enough bugs that I'm convinced it would help a lot. > As a first step we should probably at least combine our sources. Should I send you mine or you send me yours? I doubt I'll have time to work on it for quite a while, as my job (career) is on the line in the current cash crisis. > All that is really needed to start with is a little note clarifying it > is OK to modify and redistribute provided all changes are given back > to Columbia (which I'm sure is what was intended in the first place). > Exactly. We get the support burden, so we need to have the code we're supporting. Of course this also implies some quality control -- if somebody sends in malicious or buggy code, we're not obligated to take it. You would not believe how angry this makes some people. > The rest is more a question of "what happens when you are gone" -- ie > when nobody is left at Columbia who cares, you want to be sure that > anyone else who does care can still keep it going. > Right. - Frank From bygg@cafax.se Fri Feb 15 14:03:25 2002 Flags: 000000000011 Return-Path: Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA24305 for ; Fri, 15 Feb 2002 14:03:24 -0500 (EST) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.2/8.12.2) with ESMTP id g1FJ3NOh011380 for ; Fri, 15 Feb 2002 20:03:23 +0100 (MET) Received: (from bygg@localhost) by nic.cafax.se (8.12.2/8.12.2/Submit) id g1FJ3NZ2011379 for fdc@columbia.edu (Frank da Cruz); Fri, 15 Feb 2002 20:03:23 +0100 (MET) Date: Fri, 15 Feb 2002 20:03:23 WET From: Johnny Eriksson To: fdc@columbia.edu (Frank da Cruz) Subject: Re: command-line completion In-Reply-To: Your message of 12 Feb 2002 11:16:18 -0500 Message-ID: Status: O X-Status: X-Keywords: X-UID: 17 There are certainly users of MM out there... I have also started thinking about fixing the seven-bit restrictions of MM, but since CCMD uses bit 8 as a flag this is not a simple task. I did a half-hearted start on implementing a new COMND% emulator, but it is nowhere releaseable shape yet. It would be interesting to know how many old-fashioned keyboard-banging MM users there are in the world. I do know at least a handful of other Swedish people that have this affliction... --Johnny From fdc@columbia.edu Fri Feb 15 14:17:29 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id OAA22636; Fri, 15 Feb 2002 14:17:11 -0500 (EST) Date: Fri, 15 Feb 2002 14:17:09 EST From: Frank da Cruz To: Johnny Eriksson cc: Ken Harrenstien , pete@pwilson.net, bug-mm@columbia.edu Subject: Re: command-line completion In-Reply-To: Your message of Fri, 15 Feb 2002 20:03:23 WET Message-ID: Status: O X-Status: X-Keywords: X-UID: 18 > There are certainly users of MM out there... > > I have also started thinking about fixing the seven-bit restrictions of > MM, but since CCMD uses bit 8 as a flag this is not a simple task. > I did a half-hearted start on implementing a new COMND% emulator, but > it is nowhere releaseable shape yet. > The question is: what is the purpose of the flag? I started looking into this several years ago but didn't get far enough to answer this question. If its function is something we can live without, maybe CCMD can be salvaged for international use. Once CCMD is 8-bit clean, I have some other ideas for MM (did I post these already?): . SET CHARACTER-SET (default US-ASCII), SHOW CHARACTER-SET . Add header: Content-Type: text/plain; charset="iso-8859-1" or whatever. . Add header: Content-Transfer-Encoding: 7bit (or 8bit) according to charset. MM shouldn't "do" anything with character sets, just let the user declare which one is used in the outbound message and not strip the 8th bit from text, Subject, or other header data characters. The SET CHARACTER-SET command would take a keyword list of MIME charset names for only those MIME charsets that are also internation standard sets (i.e. ISO registered), since it's impolite and antisocial to send email in proprietary character sets; an internal table tells whether each one is 7bit or 8bit. The commands and headers are easy, but figuring how to undo whatever is currently done with the 8th bit is hard. Then, somewhat more ambitious: . Add an option that tells MM, when it reads a message and finds a charset header, to send the corresponding ISO 2022 escape sequence to switch the terminal into the character set used by the message or, if there is no charset header, to switch it back into its prevailing charset (such as Latin-1). Of course this can work only with standard ISO-registered character sets, not with (e.g.) Windows code pages or random MIME charsets, and only with ISO-2022 / ANSI X3.64 compliant terminals (e.g. VT220 or 320). The latter would require MM to have to several distinct charset settings: . The default (global) charset for sending . The default charset for reading (when message doesn't specify one) . A way to send a message with a given charset without affecting the global one (e.g. SEND /CHARACTER-SET:blah). . A way to tell MM, when replying, whether to automatically choose the same charset as the original message (again, without affecting the global outbound charset), e.g. REPLY /SAME-CHARSET or something, plus a global setting for whether this should be the default. > It would be interesting to know how many old-fashioned keyboard-banging > MM users there are in the world. I do know at least a handful of other > Swedish people that have this affliction... > Yes, lots of people seem to be interested in this question. Many people think they are the last person on earth to use MM. I know there are several such people just in my building, and perhaps 100 total at Columbia University. Beyond that I have no idea. - Frank From pete@pwilson.net Fri Feb 15 16:31:33 2002 Flags: 000000000011 Return-Path: Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with SMTP id QAA21514 for ; Fri, 15 Feb 2002 16:31:32 -0500 (EST) Message-ID: <20020215213132.58113.qmail@web11603.mail.yahoo.com> Received: from [66.30.74.229] by web11603.mail.yahoo.com via HTTP; Fri, 15 Feb 2002 13:31:32 PST Date: Fri, 15 Feb 2002 13:31:32 -0800 (PST) From: Pete Wilson Reply-To: pete@pwilson.net Subject: just to explain my stake in command-line completion To: Frank da Cruz , Ken Harrenstien , pete@pwilson.net, bug-mm@columbia.edu, Johnny Eriksson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O X-Status: X-Keywords: X-UID: 19 Hi folks -- Sorry to miss this meeting; I've been out all day. I'd better explain my interest in COMND/CCMD (hey, what's the diff, anyway?). I'm writing an embedded CLI for a paying client, along with SNMP and HTTP interfaces. Guy wants a unified, multifunctional management interface. Sounds good to me! Dream-type assignment. Many of the ideas I've heard over the years, along with my experiences, have solidified in this project so that I have some hopes that a real nice i/f might come out of all this. I had read Dan Murphy's reminiscences some time ago, but never really understood COMND: I left DEC in '72. Then, a few days ago, a discussion started in comp.human-factors around command completion. It was then that I posted to that group and also to alt.sys.pdp10 a command-completion question: "Does anybody really _use_ this stuff anymore?" Well! I should say so! It was obvious from the tons of responses that there was plenty of interest in command completion; and that COMND-style realization might be a fruitful tree. That's when I asked Frank for the URLs that he very kindly provided. And _that's_ when I saw and began to read the SAIL/CCMD description and got real, real hot about the whole thing. I plan to implement some small, useful subset of something like COMND in the client's code. But I'd like to make (later) a complete implementation. And then I'd like to make the mechanism freely available somewhere/how. If that's through Columbia, that's great. If it's through FSF, that's great too. If the code belongs to Columbia, then I guess it's Columbia's call. My client is OK with this plan. As for MM, my own interest is zero right now, except as MM integrates COMND. I have a feeling that the bit-8 issues, for example, are MM issues and not COMND issues. Is that right? I'm looking for an actual implementation, perhaps in ASM-10, perhaps in C, that I can look at to augment and ratify the docs. If it's C code and it's machine-readable, that would be outstanding. Can you folks help me out with that? I am also a portability freak and standards-obsessed, to boot, Frank :-) -- Pete Wilson __________________________________________________ Do You Yahoo!? Got something to say? Say it better with Yahoo! Video Mail http://mail.yahoo.com From fdc@columbia.edu Sat Feb 16 12:14:43 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id MAA13647; Sat, 16 Feb 2002 12:14:41 -0500 (EST) Date: Sat, 16 Feb 2002 12:14:41 EST From: Frank da Cruz To: Ken Harrenstien cc: pete@pwilson.net Subject: Re: Columbia COMND In-Reply-To: Your message of Fri, 15 Feb 2002 12:25:49 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 20 > > As a first step we should probably at least combine our sources. > > Should I send you mine or you send me yours? I doubt I'll have time > > to work on it for quite a while, as my job (career) is on the line > > in the current cash crisis. > > Likewise. We should probably do both, so we all at least have the > same parts on hand. Whoever gets the time first can then piddle > around. > It probably won't be me! > Do you have a server where I can put/pickup stuff... > Yes: ftp://kermit.columbia.edu/kermit/mm/mm-fdc-20020216.tar.gz See NOTES.fdc for my notes -- basically my attempts to work around the EMACS/NFS truncating problem, which seemed to be successful for about a week, but proved otherwise when we started having some really bad NFS days. (The optimism at the beginning of this file trails off towards the end.) Also note that the MM and CCMD files are fully patched. There is no kind of RCS/SCCS/CVS stuff here -- sorry, I just don't have time for all that... For putting stuff, use: ftp://kermit.columbia.edu/kermit/incoming/ - Frank From fdc@columbia.edu Sat Feb 16 12:31:40 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id MAA16421; Sat, 16 Feb 2002 12:31:37 -0500 (EST) Date: Sat, 16 Feb 2002 12:31:37 EST From: Frank da Cruz To: pete@pwilson.net Subject: Re: just to explain my stake in command-line completion In-Reply-To: Your message of Fri, 15 Feb 2002 13:31:32 -0800 (PST) Cc: Ken Harrenstien Message-ID: Status: O X-Status: X-Keywords: X-UID: 21 > I plan to implement some small, useful subset of something like > COMND in the client's code. But I'd like to make (later) a > complete implementation. And then I'd like to make the mechanism > freely available somewhere/how. If that's through Columbia, > that's great. If it's through FSF, that's great too. If the code > belongs to Columbia, then I guess it's Columbia's call. My > client is OK with this plan. > The question is, why do it all over again when it's already been done? We have it for you in C already. Our SAIL version is out there too -- too bad you can't use SAIL any more... If it's a license issue, we can talk about that. > As for MM, my own interest is zero right now, except as MM > integrates COMND. I have a feeling that the bit-8 issues, for > example, are MM issues and not COMND issues. Is that right? > They are COMND issues that affect MM. If you want your application to allow 8-bit characters, they'll affect you too. > I'm looking for an actual implementation, perhaps in ASM-10, > perhaps in C, that I can look at to augment and ratify the docs. > If it's C code and it's machine-readable, that would be > outstanding. > > Can you folks help me out with that? > As noted in my previous message: ftp://kermit.columbia.edu/kermit/mm/mm-fdc-20020216.tar.gz > I am also a portability freak and standards-obsessed, to boot, > Frank :-) > Good :-) - Frank From klh@panix.com Sun Feb 17 00:45:19 2002 Flags: 000000000001 Return-Path: Received: from mail2.panix.com (mail2.panix.com [166.84.0.213]) by menyapa.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id AAA08470 for ; Sun, 17 Feb 2002 00:45:19 -0500 (EST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail2.panix.com (Postfix) with ESMTP id A33D38EA1; Sun, 17 Feb 2002 00:45:18 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g1H5jIj14695; Sun, 17 Feb 2002 00:45:18 -0500 (EST) Date: Sun, 17 Feb 2002 0:45:18 EST From: Ken Harrenstien To: Frank da Cruz Cc: Ken Harrenstien , pete@pwilson.net Subject: Re: Columbia COMND In-Reply-To: Your message of Sat, 16 Feb 2002 12:14:41 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 22 > ftp://kermit.columbia.edu/kermit/mm/mm-fdc-20020216.tar.gz Thanks, have snarfed it. > Also note that the MM and CCMD files are fully patched. There is no > kind of RCS/SCCS/CVS stuff here -- sorry, I just don't have time for all > that... No problem, I know exactly what you mean. > For putting stuff, use: > > ftp://kermit.columbia.edu/kermit/incoming/ OK, it may be a while before I have something to dump there though. I started pulling things together and realized I had been dealing with 4 different ports without re-combining all of the fixes (generally I was in a big hurry, and once things worked, somehow forgot to go back and re-integrate). So now I have a 4-way merge diff on my hands. Will let you know... --Ken From pete@pwilson.net Sun Feb 17 03:42:07 2002 Flags: 000000000011 Return-Path: Received: from web11605.mail.yahoo.com (web11605.mail.yahoo.com [216.136.172.57]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with SMTP id DAA28042 for ; Sun, 17 Feb 2002 03:42:06 -0500 (EST) Message-ID: <20020217084206.40581.qmail@web11605.mail.yahoo.com> Received: from [66.30.74.229] by web11605.mail.yahoo.com via HTTP; Sun, 17 Feb 2002 00:42:06 PST Date: Sun, 17 Feb 2002 00:42:06 -0800 (PST) From: Pete Wilson Reply-To: pete@pwilson.net Subject: Columbia CCMD To: Ken Harrenstien , Frank da Cruz In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: O X-Status: X-Keywords: X-UID: 23 --- Ken Harrenstien wrote: > > ftp://kermit.columbia.edu/kermit/mm/mm-fdc-20020216.tar.gz > > Thanks, have snarfed it. As have I. > > Also note that the MM and CCMD files are fully patched. > There is no > > kind of RCS/SCCS/CVS stuff here -- sorry, I just don't have > time for all > > that... > > No problem, I know exactly what you mean. As do I. I'm working _only_ on CCMD. My plan: 1. Apply patches. 2. Build on SVR4. 3. Build on MS-DOS. 4. Build on Win32. Well, maybe I should call it my hope. > > For putting stuff, use: > > > > ftp://kermit.columbia.edu/kermit/incoming/ OK. -- Pete Wilson __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From klh@panix.com Sun Feb 17 23:32:04 2002 Flags: 000000000001 Return-Path: Received: from mail2.panix.com (mail2.panix.com [166.84.0.213]) by kachifo.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id XAA19420 for ; Sun, 17 Feb 2002 23:32:00 -0500 (EST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail2.panix.com (Postfix) with ESMTP id 6BFA98F86; Sun, 17 Feb 2002 23:31:48 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g1I4VmV27854; Sun, 17 Feb 2002 23:31:48 -0500 (EST) Date: Sun, 17 Feb 2002 23:31:48 EST From: Ken Harrenstien To: pete@pwilson.net Cc: Ken Harrenstien , Frank da Cruz Subject: Re: Columbia CCMD In-Reply-To: Your message of Sun, 17 Feb 2002 00:42:06 -0800 (PST) Message-ID: Status: O X-Status: X-Keywords: X-UID: 24 > As do I. I'm working _only_ on CCMD. My plan: Since this appears to be the most urgent item, I am going ahead and attempting to merge just the CCMD files. I finally puzzled out the history of all my MM/CCMD versions and it's not as bad as I thought, I've reduced them to one KLH-canonical version. I now have four main trees to merge: (1) The "original" distribution, with such patches as were officially posted. (2) The "panix" version, which is used where I get my mail. Fortunately they seem to have conditionalized all their mods correctly. (3) The "fdc" Columbia version that Frank just dropped off. (4) The "klh" version, which has a lot of OS-dependent mods to use new signal and terminal I/O mechanisms (without, I hope, breaking the old ones). My plan is to merge first "panix", then "fdc", into "klh" and drop that off in the location Frank provided. Will let you know when the CCMD stuff is there, and I do suggest you wait until then. CCMD sure needs a bunch of attention. If it looks like Pete can use the stuff, that would be a great opportunity to clean it up and restore it to real utility (unlike MM, which is not as generally useful). --Ken (ps I'll worry about the TOPS-20 version later when/if I ever regain access to the dumps.) From klh@panix.com Tue Feb 19 05:08:25 2002 Flags: 000000000011 Return-Path: Received: from mail2.panix.com (mail2.panix.com [166.84.0.213]) by kachifo.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id FAA19489 for ; Tue, 19 Feb 2002 05:08:25 -0500 (EST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail2.panix.com (Postfix) with ESMTP id BE7668EC8; Tue, 19 Feb 2002 05:08:24 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g1JA8Ov06644; Tue, 19 Feb 2002 05:08:24 -0500 (EST) Date: Tue, 19 Feb 2002 5:08:24 EST From: Ken Harrenstien To: Frank da Cruz Cc: Ken Harrenstien , pete@pwilson.net Subject: Merged CCMD deposited Message-ID: Status: O X-Status: X-Keywords: X-UID: 25 > For putting stuff, use: > > ftp://kermit.columbia.edu/kermit/incoming/ Have put these two files there: -rw-r--r-- 1 klh klh 50 Feb 19 01:30 ccmd-a20219.MD5 -rw-r--r-- 1 klh klh 578977 Feb 19 01:29 ccmd-a20219.tar.gz This contains just CCMD, not MM. The top-level file KLH.NOTES has a few notes you should read. There is still lots of junk in there that I didn't have the energy to get rid of. I would not trust anything called "makefile.*" for example. I see after the fact that I also included some of my own junk, like "ccmd.bad". Sorry... better next time. Although the original files did work for me on my favorite systems (FreeBSD, Linux, NetBSD, Solaris, Tru64), due to the large number of changes there is actually a fair chance that this will not now work for them or for you. I have put this preliminary version out anyway, without testing it beyond verifying that it compiles on FreeBSD, because I don't know how much more time I can put into it. I do plan to make sure it works on all of the systems I mentioned, because I need it there, but it may take a while. Likewise for MM itself. In the meantime, you now have something to chew on. --Ken From klh@panix.com Wed Feb 20 05:50:29 2002 Flags: 000000000011 Return-Path: Received: from mail3.panix.com (mail3.panix.com [166.84.0.167]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id FAA08761 for ; Wed, 20 Feb 2002 05:50:29 -0500 (EST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 6C74198182; Wed, 20 Feb 2002 05:50:29 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g1KAoTw24084; Wed, 20 Feb 2002 05:50:29 -0500 (EST) Date: Wed, 20 Feb 2002 5:50:29 EST From: Ken Harrenstien To: Frank da Cruz Cc: Ken Harrenstien , pete@pwilson.net Subject: Re: Merged CCMD deposited In-Reply-To: Your message of Tue, 19 Feb 2002 17:00:12 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 26 > > > For putting stuff, use: > > > > > > ftp://kermit.columbia.edu/kermit/incoming/ > > > > Have put these two files there: > > > > -rw-r--r-- 1 klh klh 50 Feb 19 01:30 ccmd-a20219.MD5 > > -rw-r--r-- 1 klh klh 578977 Feb 19 01:29 ccmd-a20219.tar.gz > > > OK, I put 'em in: > > ftp://kermit.columbia.edu/kermit/mm/ccmd-klh-a20219.MD5 > ftp://kermit.columbia.edu/kermit/mm/ccmd-klh-a20219.tar.gz I was still unhappy with the cruddy OS conditionals and so revised them more thoroughly and have deposited a new version: -rw-r--r-- 1 klh klh 54 Feb 20 02:18 ccmd-klh-a20220.MD5 -rw-r--r-- 1 klh klh 205039 Feb 20 02:18 ccmd-klh-a20220.tar.gz This time I verified that it works at least on FreeBSD with my MM. Did find a CCMD config bug, however; it's described in the KLH.NOTES for this version. This one should be much easier for Pete to deal with in terms of porting, although there is still much that can be done. You may not agree with the scheme I put in for OS conditionals since it is a departure from the old style, but you can always revise it again (as long as it is improved rather than reverting to the old hopelessly broken scheme). Good luck! I'm pretty sure I'm done for a while. --Ken From fdc@columbia.edu Wed Feb 20 17:54:12 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id RAA24838; Wed, 20 Feb 2002 17:54:09 -0500 (EST) Date: Wed, 20 Feb 2002 17:54:08 EST From: Frank da Cruz To: bug-mm@columbia.edu Subject: New CCMD Bug-Report: Bug in Columbia MM, version 0.90.4(43) (SunOS) Message-ID: Status: O X-Status: X-Keywords: X-UID: 27 >From Ken Harrenstein (you all know who he is right?)... He took the latest patched CCMD that I was using -- with Y2K patches all installed, etc, and filtered in all the changes he has made in the past 10 years. I haven't looked at it or messed with it yet except to read his notes. Files: [/w/pub/ftp/kermit/mm] ls -lG -rw-rw-r-- 1 fdc 12627 Feb 20 17:48 NOTES.FDC -rw-rw-r-- 1 fdc 5401 Feb 20 17:47 NOTES.KLH -rw-rw-r-- 1 fdc 54 Feb 20 05:41 ccmd-klh-a20220.MD5 -rw-rw-r-- 1 fdc 205039 Feb 20 05:41 ccmd-klh-a20220.tar.gz -rw-rw-r-- 1 fdc 923 Feb 4 1991 ccmd-patch.01 -rw-rw-r-- 1 fdc 904940 Feb 16 12:09 mm-fdc-20020216.tar.gz -rw-rw-r-- 1 fdc 1269 Jan 3 1991 patch.01 -rw-rw-r-- 1 fdc 7314 Jan 4 1991 patch.02 -rw-rw-r-- 1 fdc 959 Feb 4 1991 patch.03 -rw-rw-r-- 1 fdc 1881 Sep 18 1992 patch.04 -rw-rw-r-- 1 fdc 9619 Jan 18 2000 patch.mm-ccmd.y2k -rw-rw-r-- 1 fdc 2870 Jan 8 2001 patch.mm-ccmd.y2k1 [/w/pub/ftp/kermit/mm] Ken's notes are NOTES.KLH (from today); mine are NOTES.FDC (from a few weeks ago). - Frank From klh@panix.com Thu Feb 21 00:51:14 2002 Flags: 000000000011 Return-Path: Received: from mail3.panix.com (mail3.panix.com [166.84.0.167]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id AAA05176 for ; Thu, 21 Feb 2002 00:51:14 -0500 (EST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 881BE98215; Thu, 21 Feb 2002 00:51:13 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g1L5pDE23654; Thu, 21 Feb 2002 00:51:13 -0500 (EST) Date: Thu, 21 Feb 2002 0:51:13 EST From: Ken Harrenstien To: Frank da Cruz Cc: Ken Harrenstien , pete@pwilson.net Subject: Re: Merged CCMD deposited In-Reply-To: Your message of Wed, 20 Feb 2002 14:00:34 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 28 > > > Any special reason yesterday's was 5.8MB and today's is 2.0? Talk about > > > simplification! :-) > > > > Just a lot of unintentional crap in the first one (eg an ancient ccmd.a)... > > > OK, great, I'll get rid of the first one then. Thanks! It's probably a good idea, once you get around to seriously trying it, to check with me to see if there are any further mods. Have already tweaked the Makefile a little bit to get it to build on Solaris 8 (put -DHAVE_ENV=0 in the solaris: command line), but it seems to work there now. --Ken From klh@panix.com Wed Feb 27 03:42:03 2002 Flags: 000000000011 Return-Path: Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id DAA12061 for ; Wed, 27 Feb 2002 03:42:03 -0500 (EST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id 2A6A748806; Wed, 27 Feb 2002 03:42:03 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g1R8g3Z04510; Wed, 27 Feb 2002 03:42:03 -0500 (EST) Date: Wed, 27 Feb 2002 3:42:03 EST From: Ken Harrenstien To: Frank da Cruz Cc: Ken Harrenstien , pete@pwilson.net Subject: Re: Merged CCMD deposited In-Reply-To: Your message of Thu, 21 Feb 2002 8:57:28 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 29 > Well then you might as well send the latest, since all we have at Columbia > is Solaris... Thanks! OK, here you go. This has the COMPLETE merge, both CCMD and MM. -rw-r--r-- 1 klh klh 51 Feb 23 01:02 mmklh-a20223.MD5 -rw-r--r-- 1 klh klh 414453 Feb 23 01:02 mmklh-a20223.tar.gz In order to build a version corresponding to what you now have, you should: ccmd: cd ccmd; make solaris mm: cd mm; rm config.h; ln -s config.h-cunix config.h; make fdc-solaris KLH.NOTES has more info. I conditionalized your edit.c hacks as I wasn't sure how they would play elsewhere, and I haven't experienced the problem for some years. Between config.h-cunix and the "fdc-solaris" target you should get more or less the same thing you now have. I changed the config setup for MM to be more like CCMD's, but again, it is still not where I'd like it to be. Rather than spend more time trying to perfect something that not many people still care about, I'm putting it out now. Whew. --Ken From fdc@columbia.edu Wed Feb 27 10:31:27 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id KAA17629; Wed, 27 Feb 2002 10:31:25 -0500 (EST) Date: Wed, 27 Feb 2002 10:31:25 EST From: Frank da Cruz To: Ken Harrenstien Subject: Re: Merged CCMD deposited In-Reply-To: Your message of Wed, 27 Feb 2002 3:42:03 EST Cc: bug-mm@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 30 > > Well then you might as well send the latest, since all we have at Columbia > > is Solaris... Thanks! > > OK, here you go. This has the COMPLETE merge, both CCMD and MM. > > -rw-r--r-- 1 klh klh 51 Feb 23 01:02 mmklh-a20223.MD5 > -rw-r--r-- 1 klh klh 414453 Feb 23 01:02 mmklh-a20223.tar.gz > Terrific, many thanks. I put it in the usual place: ftp://kermit.columbia.edu/kermit/mm/mm-ccmd-klh-a20227.tar.gz and: ftp://kermit.columbia.edu/kermit/mm/NOTES.KLH But probably won't have a chance to mess with it (beyond extracting the notes file) for some time. Meanwhile, I'm cc'ing "bug-mm" (the old crowd) so they know what's what, hence the quoting of the rest of your message. > In order to build a version corresponding to what you now have, you > should: > ccmd: > cd ccmd; make solaris > mm: > cd mm; rm config.h; ln -s config.h-cunix config.h; > make fdc-solaris > > KLH.NOTES has more info. > I conditionalized your edit.c hacks as I wasn't sure how they would > play elsewhere, and I haven't experienced the problem for some years. > Between config.h-cunix and the "fdc-solaris" target you should get > more or less the same thing you now have. > > I changed the config setup for MM to be more like CCMD's, but again, > it is still not where I'd like it to be. Rather than spend more time > trying to perfect something that not many people still care about, I'm > putting it out now. > > Whew. > --Ken > Whew indeed. Many thanks! I will take it from there, probably the next time we have a bad enough NFS day to get me riled up. Squeaky wheel, etc. - Frank From klh@panix.com Wed Feb 27 11:43:49 2002 Flags: 000000000001 Return-Path: Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by kachifo.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA05183 for ; Wed, 27 Feb 2002 11:43:46 -0500 (EST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id F2B3498240; Wed, 27 Feb 2002 11:43:45 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g1RGhjA12184; Wed, 27 Feb 2002 11:43:45 -0500 (EST) Date: Wed, 27 Feb 2002 11:43:45 EST From: Ken Harrenstien To: Frank da Cruz Cc: Ken Harrenstien Subject: MM+EMACS vs Solaris (file truncation) In-Reply-To: Your message of Wed, 27 Feb 2002 10:31:25 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 31 > Whew indeed. Many thanks! I will take it from there, probably the next > time we have a bad enough NFS day to get me riled up. Squeaky wheel, etc. Speaking of squeaky wheels, has anyone tried complaining to Sun? That *is* what commercial software is supposed to be about, after all -- you pay through the nose for their promise (implied or not) that they'll fix their problems. From your comments it sounds as if a test case shouldn't be hard to generate. (And if you can generate such a test program, there may be a few things I can do about it from my end.) The thing is that I have yet to encounter this phenomenon on the Panix NetBSD systems, although all of the messages I write are composed with MM and all of the files being operated on are NFS files. The only place I have been really hit with this was SunOS, and it happened even though I used my own editor (ELLE) rather than EMACS, and was very careful to make sure it invoked fsync(). I assumed it was an old artifact of an abandoned OS and am really surprised that this problem persists on Solaris. I wonder if it has something to do with their default NFS configuration parameters (remember they used to distribute SunOS with UDP checksums turned off!!!!). --Ken From klh@panix.com Thu Apr 25 15:11:32 2002 Flags: 000000000011 Return-Path: Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by hickory.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA01938 for ; Thu, 25 Apr 2002 20:11:31 -0400 (EDT) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id E059C982BD; Thu, 25 Apr 2002 20:11:17 -0400 (EDT) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g3Q0BH111971; Thu, 25 Apr 2002 20:11:17 -0400 (EDT) Date: Thu, 25 Apr 2002 20:11:17 EDT From: Ken Harrenstien To: Ron Young Cc: klh@panix.com, fdc@columbia.edu Subject: Re: Command line completion (from alt.sys.pdp10) In-Reply-To: Your message of Thu, 25 Apr 2002 09:58:15 -0700 Message-ID: Status: O X-Status: X-Keywords: X-UID: 32 > I am in the middle of working on my master thesis (writing a foreign > language search engine) and would really like to use the old ccmd > command completion routines. I followed the thread on ccmd in > alt.sys.pdp10 a couple of months ago but could not find any resolution > about the public availablity of a new version. > > Would it be possible to get your modified copy of ccmd? The only > version that I have been able to find is one from Columbia U. dated > circa 1991 that has dependencies on the old BSD stdio library. > > My target platforms in descending order of preference are: x86 linux, > solaris 8 (on ultrasparc/64 bit), and windows. > > Any assistance that you could provide, will be greatly appreciated. Sure. I sent the latest stuff to fdc@columbia.edu but I am not sure whether he put it in a publicly accessible location; hopefully he will comment. If not, I can e-mail you a tarball. --Ken From klh@panix.com Fri Apr 26 13:11:07 2002 Flags: 000000000001 Return-Path: Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by dewberry.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA11284 for ; Fri, 26 Apr 2002 18:11:07 -0400 (EDT) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail1.panix.com (Postfix) with ESMTP id C3E0C487BE; Fri, 26 Apr 2002 18:11:06 -0400 (EDT) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g3QMB5t29002; Fri, 26 Apr 2002 18:11:05 -0400 (EDT) Date: Fri, 26 Apr 2002 18:11:03 EDT From: Ken Harrenstien To: Frank da Cruz Cc: klh@panix.com Subject: Re: Command line completion (from alt.sys.pdp10) In-Reply-To: Your message of Fri, 26 Apr 2002 10:13:20 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 33 > By the way, Ken, I finally got around to building a new MM from this and > I haven't had any messages truncated since then. Of course that doesn't > prove anything... Hey! Who needs proof? There actually is a possibility that two of the changes I made, to use native sigaction and termios instead of relying on BSD compatibility frobs, are bypassing some poor code that isn't visible to us. (If you really want to find out, you could always comment out your special preventive measures :-) Anyway, very glad it works OK for you, I was hoping my merge wouldn't just become another fork. --Ken From klh@panix.com Fri Apr 26 13:16:09 2002 Flags: 000000000001 Return-Path: Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by marionberry.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA05064 for ; Fri, 26 Apr 2002 18:16:09 -0400 (EDT) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail2.panix.com (Postfix) with ESMTP id 910458F88; Fri, 26 Apr 2002 18:16:08 -0400 (EDT) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g3QMG8l00310; Fri, 26 Apr 2002 18:16:08 -0400 (EDT) Date: Fri, 26 Apr 2002 18:16:06 EDT From: Ken Harrenstien To: Ron Young Cc: Ken Harrenstien , fdc@columbia.edu Subject: Re: Command line completion (from alt.sys.pdp10) In-Reply-To: Your message of Fri, 26 Apr 2002 14:05:11 -0700 Message-ID: Status: O X-Status: X-Keywords: X-UID: 34 > In looking at the test.c source (specifically the comment command) > I am confused at when the noise words "start" and "end" should > appear. > > Unless I am way off, I would think that the terminal i/o for the > comment command should look like: > > Test> comment(To eol) ":"(start)";"(end) "$" > ++++++++++++ ++++++++ +++++++++++++ +++ > (where +++ denotes input) > > After the first tab is entered, nothing happens (the tab character > is expanded but no noise word output), if you type another tab, the > terminal beeps. If you type everything in without tabs the parse > succeeds. > > Any illumination that you can provide would be very much appreciated. Afraid I don't know, I have never tried to use the test.c program. My focus was on getting MM ported, not on using CCMD in general. You'd have to examine the code to see if there are any obvious problems in either test.c, or CCMD, or even in the whole concept of how that particular syntax should work (you can bring up your own TOPS-20 to verify :-). --Ken From ron@isri.unlv.edu Fri Apr 26 13:21:04 2002 Flags: 000000000001 Return-Path: Received: from wiggins.isri.unlv.edu (wiggins.isri.unlv.edu [131.216.20.115]) by marionberry.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA08091 for ; Fri, 26 Apr 2002 18:21:03 -0400 (EDT) Received: from wiggins (localhost [127.0.0.1]) by wiggins.isri.unlv.edu (Postfix) with ESMTP id EE53F5E734; Fri, 26 Apr 2002 15:21:02 -0700 (PDT) To: Ken Harrenstien Cc: fdc@columbia.edu, ron@isri.unlv.edu Subject: Re: Command line completion (from alt.sys.pdp10) In-Reply-To: Your message of "Fri, 26 Apr 2002 18:16:06 EDT." Date: Fri, 26 Apr 2002 15:21:02 -0700 From: Ron Young Message-Id: <20020426222103.EE53F5E734@wiggins.isri.unlv.edu> Status: O X-Status: X-Keywords: X-UID: 35 Your message dated: Fri, 26 Apr 2002 18:16:06 EDT -------- I've looked at things some more and it appears that the test of the closing delimiter (whether it is doubled or not) is causing some weirdness in cmqstr.c... As for bringing up TOPS-20, simh is a worderful thing 8-), that's the reason why I starting reading alt.sys.pdp10...I just wish I had more time to play with the simulators. I'll let you know if/when I find the bug. thanks again. -ron > > Afraid I don't know, I have never tried to use the test.c program. My > focus was on getting MM ported, not on using CCMD in general. You'd > have to examine the code to see if there are any obvious problems in > either test.c, or CCMD, or even in the whole concept of how that particular > syntax should work (you can bring up your own TOPS-20 to verify :-). > > --Ken > > > =============================================================================== Ron Young, Sr. Software Design Engineer & System Admin.(702) 895-1070 (voice) Information Science Research Institute (702) 895-1183 (fax) University of Nevada, Las Vegas (UNLV/ISRI) ron@isri.unlv.edu Box 454021, Las Vegas, NV 89154 From klh@panix.com Fri Apr 26 13:30:44 2002 Flags: 000000000001 Return-Path: Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by dewberry.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA23606 for ; Fri, 26 Apr 2002 18:30:39 -0400 (EDT) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 229969820E; Fri, 26 Apr 2002 18:30:39 -0400 (EDT) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g3QMUdp02607; Fri, 26 Apr 2002 18:30:39 -0400 (EDT) Date: Fri, 26 Apr 2002 18:30:39 EDT From: Ken Harrenstien To: Ron Young Cc: Ken Harrenstien , fdc@columbia.edu Subject: Re: Command line completion (from alt.sys.pdp10) In-Reply-To: Your message of Fri, 26 Apr 2002 15:21:02 -0700 Message-ID: Status: O X-Status: X-Keywords: X-UID: 36 > As for bringing up TOPS-20, simh is a worderful thing 8-), that's > the reason why I starting reading alt.sys.pdp10...I just wish I had > more time to play with the simulators. Don't we all... One thing though, if you ever do go this route, I suggest you bring up the most recent TOPS-20, which would require using KLH10 rather than SIMH. The problem is that KS TOPS-20 development was apparently frozen some time before KL work stopped, because the KS was no longer capable of supporting what TOPS-20 grew into. This doesn't apply to TOPS-10, but I don't think TOPS-10 had COMND%. --Ken From fdc@columbia.edu Wed May 1 02:57:05 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id MAA10370; Wed, 1 May 2002 12:57:03 -0400 (EDT) Date: Wed, 1 May 2002 12:57:03 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: prost slow to Watson In-Reply-To: Your message of Wed, 1 May 2002 11:43:16 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 37 > We are currently experiencing slowness between prost (e.g. staff > homedirs) and Watson hosts (e.g. watsol, staff workstations). We are > looking into it. > I would call this a Bad NFS day, if ever there was one, but still my new copy of MM is not truncating any messages... A good sign? - Frank From melissa@columbia.edu Wed May 1 08:50:16 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA28926; Wed, 1 May 2002 13:50:15 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.9.3/8.9.3) id NAA24506; Wed, 1 May 2002 13:50:15 -0400 (EDT) Date: Wed, 1 May 2002 13:50:15 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: prost slow to Watson In-Reply-To: Your message of Wed, 1 May 2002 12:57:03 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 38 > A good sign? Looks good to me. I copied it into ~melissa/ so I am running your version. I guess if there are no problems for a couple weeks we can install it "for real". --Melissa From fdc@columbia.edu Wed May 1 08:53:56 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id NAA23498; Wed, 1 May 2002 13:53:54 -0400 (EDT) Date: Wed, 1 May 2002 13:53:53 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: prost slow to Watson In-Reply-To: Your message of Wed, 1 May 2002 13:50:15 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 39 > > A good sign? > > Looks good to me. I copied it into ~melissa/ so I am running your > version. I guess if there are no problems for a couple weeks we can > install it "for real". > Except what do you bet that when we turn debugging off, the problem comes back? :-) - Frank From melissa@columbia.edu Wed May 1 09:07:19 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA02596; Wed, 1 May 2002 14:07:18 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.9.3/8.9.3) id OAA24793; Wed, 1 May 2002 14:07:18 -0400 (EDT) Date: Wed, 1 May 2002 14:07:18 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: prost slow to Watson In-Reply-To: Your message of Wed, 1 May 2002 13:53:53 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 40 I guess we have to turn debugging off, then wait a week or two, *then* install it :-). --Melissa From melissa@columbia.edu Mon May 6 05:17:04 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA26174; Mon, 6 May 2002 10:17:04 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.9.3/8.9.3) id KAA24265; Mon, 6 May 2002 10:17:03 -0400 (EDT) Date: Mon, 6 May 2002 10:17:03 EDT From: Melissa Metz To: fdc@columbia.edu Cc: melissa@columbia.edu Subject: awwww.... Message-ID: Status: O X-Status: X-Keywords: X-UID: 41 Awww, I just lost one as I left emacs. See screen shot below. My keystrokes were the usual ^X^S^X^Zd. It seems to confirm that it got the 992 characters from the file, but they are gone. Bad malloc?? --Melissa -------------------------------- --Melissa --1-:---F1 *MM Outgoing* (Text Fill)--L25--Bot---------------------------- wait3 returned 24122 wait3 errno 2 wait3 status is 0 /p/sy/melissa/tmp/.mm-outgoing.23799: 992 992 (OK) S>d From: Melissa Metz To: Jill Williams Cc: Jeff Eldredge , Jill Williams , Postmaster , Melissa Metz , emailgroup@columbia.edu Subject: Re: vanity proposal In-Reply-To: Your message of Mon, 06 May 2002 10:00:21 -0400 S> From fdc@columbia.edu Mon May 6 05:25:58 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id KAA15141; Mon, 6 May 2002 10:25:56 -0400 (EDT) Date: Mon, 6 May 2002 10:25:56 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: awwww.... In-Reply-To: Your message of Mon, 6 May 2002 10:17:03 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 42 > Awww, I just lost one as I left emacs. See screen shot below. My > keystrokes were the usual ^X^S^X^Zd. It seems to confirm that it > got the 992 characters from the file, but they are gone. Bad malloc?? > Foo. > wait3 returned 24122 > wait3 errno 2 > wait3 status is 0 > /p/sy/melissa/tmp/.mm-outgoing.23799: 992 992 (OK) > Well that's a good clue! The file was created (does 992 seem to be about the right size?) but MM failed to read it, or find a place for it. OK, next time I have free moment, I know where to look. Thanks! - Frank From fdc@columbia.edu Fri May 10 04:46:05 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id JAA26285; Fri, 10 May 2002 09:46:01 -0400 (EDT) Date: Fri, 10 May 2002 9:46:00 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: "Message was short." In-Reply-To: Your message of Fri, 10 May 2002 9:18:24 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 43 > I don't know if you've ever seen this message from MM: > > chk_edit /p/sy/melissa/tmp/.mm-outgoing.7705... > read_from_temp /p/sy/melissa/tmp/.mm-outgoing.7705 1 1 (OK) > read_from_temp /p/sy/melissa/tmp/.mm-headers.7705 88 88 (OK) > Message was short. Not removing temp files > S>q > > I get this when I change my mind and leave emacs without entering any > text. It is an attempt to work around the truncated message problem, > but for some reason it does not detect the actual problem, only this > unrelated case. FYI in the debugging department. > It's a special case. If the temp file is empty on return from EMACS, MM has no way of knowing if it's because you really exited from MM without saving any text in the file, or because the file was completely truncated (which used to happen to me all the time). In this case it goes through the whole 3-second sampling loop to see if the file starts growing. If it's still 0 after that, then you get the "Message was short" message. Have you had any truncations since Tuesday evening? There is one thing I noticed in the code, that I would pay more attention to if truncations happened again. Apparently the original read_from_temp routine got the size of the file, did a malloc for that many bytes + 2, and read the file into the buffer, very simple. The current routine does a fixed-size malloc, and then rmalloc's in a loop until it has read the whole file. Do you recall why that change was made? I don't see why the complicated method would be more likely to work than the simple one... But in any case, if any of these mallocs or reads fail, you should get a message at that point. - Frank From fdc@columbia.edu Tue May 14 05:53:04 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id KAA10387; Tue, 14 May 2002 10:53:00 -0400 (EDT) Date: Tue, 14 May 2002 10:53:00 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: "Message was short." In-Reply-To: Your message of Tue, 14 May 2002 10:41:36 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 44 > I don't remember why we changed the malloc code. Maybe the RCS logs > say something? > > Yes, I have had several truncations since (last) Tuesday. I had one > just today. (It's off my screen already.) > Foo! I haven't had a single one. And I used to get them many times each day. This is really strange... We both have our mail files on prost, right? Ever since this first started happening (10 years ago?) it has always seemed to happen to certain particular users, but never to others, even on the same computer. > Should I let you know each time? > Yes, along with the messages. > BTW, I copy your binary to my binary directory, so if you make any > updates let me know. > > Thanks again for looking at this. > My pleasure -- since I use it constantly, I need it to work. I'm just glad I'm not the only one still using it! - Frank From fdc@columbia.edu Tue May 14 06:28:12 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id LAA16792; Tue, 14 May 2002 11:28:09 -0400 (EDT) Date: Tue, 14 May 2002 11:28:09 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: "Message was short." In-Reply-To: Your message of Tue, 14 May 2002 11:15:51 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 45 > Right, my files are on prost. I've noticed some delays accessing my > files lately. But the debugging messages always come up saying the > right file length and the text is always completely empty (though the > headers are intact). > So stat() sees the file's length but either read() gets an EOF right away, or the malloc's are messing up. I think I already catch everything that could possibly go wrong in read_from_temp() in edit.c. If you see something like: read_from_temp /p/kd/fdc/.mm-headers.19750 184 184 (OK) that means that stat() said the file size was 184 (in this case) and read() got 184 characters too, and furthermore that none of the *alloc()s got any errors. And yet you still lost the text, so maybe it's all the weird calloc()/rmalloc() code and pointer shuffling. I can't see any reason for or advantage to this. Let's try going back to the simple single malloc(). I'll see if I can put up a new binary in a few minutes. - Frank From fdc@columbia.edu Tue May 14 07:13:37 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id MAA24292; Tue, 14 May 2002 12:13:36 -0400 (EDT) Date: Tue, 14 May 2002 12:13:35 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: "Message was short." In-Reply-To: Your message of Tue, 14 May 2002 11:15:51 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 46 OK, new mm in ~fdc/bin.solaris/mm. I fell back to the old simple single-malloc scheme and I also straightened what might be a mess with longs vs ints for file sizes (stat() returns a long, and mm was feeding this directly to malloc() and read(), which take ints). Also, LOTS more debugging messages (but only if something goes wrong). - Frank From fdc@columbia.edu Thu May 16 15:21:28 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id UAA19786; Thu, 16 May 2002 20:21:26 -0400 (EDT) Date: Thu, 16 May 2002 20:21:26 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: lost again In-Reply-To: Your message of Wed, 15 May 2002 15:54:41 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 47 > chk_edit /p/sy/melissa/tmp/.mm-outgoing.11064... > read_from_temp: /p/sy/melissa/tmp/.mm-outgoing.11064: 902 902 (OK) > read_from_temp: /p/sy/melissa/tmp/.mm-headers.11064: 215 215 (OK) > OK, one more time. Since it seems that read_from_temp() was not failing at any point, but its caller was not seeing the result, there must be something wrong with how read_from_temp() was returning its result: read_from_temp() { char * newtext; ... newtext = malloc(...); ... return(newtext); } It probably shouldn't matter that newtext is on the stack but who knows. So I made it static. Also I put debugging in read_from_temp()'s callers to catch any change in the pointer value or the text size. Also I found a bunch of unguarged foo = malloc(), strcpy(foo,...) sequences and plugged them, but only in edit.c -- there are probably lots more in other modules. The binary is in the usual place, ~fdc/bin.solaris/mm. Let me know what happens (since you're the only one who's getting truncations any more!) - Frank From melissa@columbia.edu Fri May 17 07:50:08 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA26361; Fri, 17 May 2002 12:50:06 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.9.3/8.9.3) id MAA22421; Fri, 17 May 2002 12:50:06 -0400 (EDT) Date: Fri, 17 May 2002 12:50:06 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: lost again In-Reply-To: Your message of Thu, 16 May 2002 20:21:26 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 48 > there are probably lots more in other modules. Yes, we were young and wild and didn't check the result of malloc :-(. > you're the only one who's getting truncations any more! Maybe it is my huge mail. --Melissa From melissa@columbia.edu Fri May 24 06:16:19 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA12562; Fri, 24 May 2002 11:16:18 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.9.3/8.9.3) id LAA01726; Fri, 24 May 2002 11:16:18 -0400 (EDT) Date: Fri, 24 May 2002 11:16:18 EDT From: Melissa Metz To: fdc@columbia.edu Cc: melissa@columbia.edu Subject: MM again Message-ID: Status: O X-Status: X-Keywords: X-UID: 49 Lost it. --Melissa --1-:---F1 *MM Outgoing* (Text Fill)--L5--Top---------------------------- chk_edit /p/sy/melissa/tmp/.mm-outgoing.29690... read_from_temp: /p/sy/melissa/tmp/.mm-outgoing.29690: 974 974 (OK) read_from_temp: /p/sy/melissa/tmp/.mm-headers.29690: 267 267 (OK) S>d From: Melissa Metz To: Melissa Metz Cc: Melissa Metz , unix@columbia.edu, joel@columbia.edu, selsky@columbia.edu Subject: Re: systems lunch In-Reply-To: Your message of Tue, 14 May 2002 10:21:49 EDT S> From melissa@columbia.edu Fri May 24 06:35:03 2002 Flags: 000000000011 Return-Path: Received: (from melissa@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id LAA22713; Fri, 24 May 2002 11:35:02 -0400 (EDT) Date: Fri, 24 May 2002 11:35:02 EDT From: Melissa Metz To: fdc@columbia.edu Cc: melissa@columbia.edu Subject: MM: partial truncation option Message-ID: Status: O X-Status: X-Keywords: X-UID: 50 I usually get the total truncation, but just now I have been given the partial truncation option. Maybe the number of characters (336?? final newline not included) will help somehow :-). --Melissa --1-:---F1 *MM Outgoing* (Text Fill)--L20--All--------------------------- chk_edit /p/sy/melissa/tmp/.mm-outgoing.1711... read_from_temp: /p/sy/melissa/tmp/.mm-outgoing.1711: 885 885 (OK) read_from_temp: /p/sy/melissa/tmp/.mm-headers.1711: 83 83 (OK) S>d From: Melissa Metz To: unixsys, rtc Subject: Netra T1, X1, V100 Benno noticed yesterday that the Sun Fire V100, which we thought was "just like" the T1 AC200 we have, has slower IDE disks (7200 rpm IDE instead of 10000 rpm UltraSCSI). I took a look at the "Price and Buy" pages for these models and found that the V100 and X1 really are identical (including the price!) except for the CD drive in t From fdc@columbia.edu Fri May 24 06:48:30 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id LAA25031; Fri, 24 May 2002 11:48:27 -0400 (EDT) Date: Fri, 24 May 2002 11:48:27 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM: partial truncation option In-Reply-To: Your message of Fri, 24 May 2002 11:35:02 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 51 > I usually get the total truncation, but just now I have been given the > partial truncation option. Maybe the number of characters (336?? > final newline not included) will help somehow :-). > I got one total truncation a few days ago -- otherwise no problem in thousands of messages. But there still seems to be a path thru the code where the text can be lost, but I'll be darned if I can find it. My worry is that the pointer to the text buffer gets lost later on somewhere, or that a NUL gets deposited in its first position. Such a thing would be very hard to track down. Partial truncation, on the other hand, can happen even if MM is working right. If the file was not fully written to disk, yet its size stopped changing -- in other words if there was a long pause between file updates, or updates of its NFS doppelganger. But in that case, the same kind of thing should happen with trn, Pine, etc. Sigh. - Frank From fdc@columbia.edu Fri May 24 08:08:07 2002 Flags: 000000000001 Return-Path: Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.9.3/8.9.3) id NAA11682; Fri, 24 May 2002 13:08:05 -0400 (EDT) Date: Fri, 24 May 2002 13:08:05 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM: partial truncation option In-Reply-To: Your message of Fri, 24 May 2002 12:41:14 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 52 > > If the file was not fully written to disk, ... > > But MM gave the correct count of characters, and then displayed a > shorter message. > Yikes! So it truncated the message after it successfully read it in? Not only that, my code later does a strlen() on the newtext buffer to make sure it agrees with the file length (e.g. in case NULs were inserted), and since you didn't see a complaint, that check worked too. Fooey, this is a whole new ball game. Thanks -- more places to look... - Frank From fdc@columbia.edu Sun Jul 21 12:24:57 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g6LLOulH025847; Sun, 21 Jul 2002 17:24:56 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g6LLOuBI025846; Sun, 21 Jul 2002 17:24:56 -0400 (EDT) Date: Sun, 21 Jul 2002 17:24:56 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM: partial truncation option In-Reply-To: Your message of Fri, 24 May 2002 11:35:02 EDT Cc: bug-mm@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 53 > I usually get the total truncation, but just now I have been given the > partial truncation option. Maybe the number of characters (336?? > final newline not included) will help somehow :-). > I had a few minutes to work on mm some more... I did not have a Eureka experience, but I did add more debugging for what it's worth. But I also did something new: Added "set user-temp-files-keep" (keyword chosen so it goes at end of list, since it wasn't clear to me how to insert a new keyword -- do I have to change all the #defines in set.h?). Made the default for this "yes" if FDC_EDITFIX is defined, since otherwise what good is it? set.h, set.c, extern.h. Filled in action for "set user-temp-files-keep yes" -- just check the boolean variable for this setting in purge() and change all open()s for temporary files to include O_TRUNC (since we keep recycling the same name). Then in cmd_quit(), delete the temp files (i.e. when user says BYE or QUIT). Thus after editing a message, the temp files stay around until the next time you enter the editor from within MM, or you (really) exit from MM, so now if any message is truncated after editing, you can get it back from the temp file -- and if the temp file itself is truncated, we know it's the editor's fault and not MM's. edit.c. The new binary is in ~fdc/bin.solaris/mm. - Frank From melissa@columbia.edu Fri Aug 9 05:54:09 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g79Es36t016914; Fri, 9 Aug 2002 10:54:03 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g79Es3Kc011495; Fri, 9 Aug 2002 10:54:03 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g79Es3lE011494; Fri, 9 Aug 2002 10:54:03 -0400 (EDT) Date: Fri, 9 Aug 2002 10:54:02 EDT From: Melissa Metz To: unix@columbia.edu Cc: fdc@columbia.edu Subject: ["Fuat C. Baran" : newcunix] Message-ID: Status: O X-Status: X-Keywords: X-UID: 54 Some newcunix comments. While there are few MM users, I guess we will need to do something to make MM work on newcunix. I guess recompile with the "correct" path? --Melissa --------------- Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g792grdt008927; Thu, 8 Aug 2002 22:42:53 -0400 (EDT) Received: (from fuat@localhost) by hazelnut.cc.columbia.edu (8.12.3/8.12.3/Submit) id g792grgT008926; Thu, 8 Aug 2002 22:42:53 -0400 (EDT) Date: Thu, 8 Aug 2002 22:42:53 EDT From: "Fuat C. Baran" To: melissa@columbia.edu Cc: fuat@columbia.edu URL: http://www.columbia.edu/~fuat/ Subject: newcunix Message-ID: term didn't work gnuemacs mode for mm doesn't work: Cannot open load file: /usr/local/lib/mm/mmail.el --Fuat From fdc@columbia.edu Fri Aug 9 06:06:30 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g79F6PIf002681; Fri, 9 Aug 2002 11:06:25 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g79F6OI2002680; Fri, 9 Aug 2002 11:06:24 -0400 (EDT) Date: Fri, 9 Aug 2002 11:06:24 EDT From: Frank da Cruz To: Melissa Metz Cc: unix@columbia.edu Subject: Re: ["Fuat C. Baran" : newcunix] In-Reply-To: Your message of Fri, 9 Aug 2002 10:54:02 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 55 > Fuat said: > > gnuemacs mode for mm doesn't work: > > Cannot open load file: /usr/local/lib/mm/mmail.el > > Some newcunix comments. While there are few MM users, I guess we will > need to do something to make MM work on newcunix. I guess recompile > with the "correct" path? > I hate Unix compared to TOPS-20 because of stuff like this. Hardwiring paths into programs is so gross. Remember when we first started using Unix, we actually discussed adding logical names to the kernel? But then gave up on it because nobody "owned" Unix so there was nobody would take our changes. Meanwhile, every change of Unix variety or release changes the file system layout. Meanwhile, why not add Yet Another Symlink? I suppose I can do something in the code to make it search a list of paths, or get an MM_ELISP_PATH environment variable or whatever, but can't guarantee anything quick since this is Do-Or-Die month for the Kermit project. Also we still haven't solved the fundamental problem with files being truncated upon return from EMACS. At least now that we save the temp file, it's better than before. Maybe it's good enough, because the few remaining MM users might be able to grasp concepts like "temp file". But before installing my version of MM for production I should at least clean up the messages. I'll try to do more later. - Frank From melissa@columbia.edu Fri Aug 9 06:22:20 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g79FMD6t029237; Fri, 9 Aug 2002 11:22:13 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g79FMDKc012041; Fri, 9 Aug 2002 11:22:13 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g79FMDgk012040; Fri, 9 Aug 2002 11:22:13 -0400 (EDT) Date: Fri, 9 Aug 2002 11:22:12 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz , unix@columbia.edu Subject: Re: ["Fuat C. Baran" : newcunix] In-Reply-To: Your message of Fri, 9 Aug 2002 11:06:24 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 56 Thanks, Frank. We don't need anything quick, we can wait. --Melissa From unicode-bounce@unicode.org Thu Sep 5 05:43:44 2002 Flags: 000000000001 Return-Path: Received: from unicode.org (unicode.org [209.235.17.55]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8E3hiC5010405 for ; Fri, 13 Sep 2002 23:43:44 -0400 (EDT) Received: from sarasvati.unicode.org (localhost.localdomain [127.0.0.1]) by unicode.org (8.11.6/8.11.6) with ESMTP id g8E383321646; Fri, 13 Sep 2002 23:08:04 -0400 Received: with ECARTIS (v1.0.0; list unicode); Fri, 13 Sep 2002 23:08:03 -0400 (EDT) Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by unicode.org (8.11.6/8.11.6) with ESMTP id g8E37v321640 for ; Fri, 13 Sep 2002 23:07:57 -0400 Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by netscape.com (8.10.0/8.10.0) with ESMTP id g8E2IEm26785 for ; Fri, 13 Sep 2002 19:18:14 -0700 (PDT) Received: from netscape.com ([10.169.99.244]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id H2ERCZ00.BIG; Fri, 13 Sep 2002 20:07:47 -0700 Message-ID: <3D82A648.8030006@netscape.com> Date: Fri, 13 Sep 2002 20:00:24 -0700 From: momoi@netscape.com (Katsuhiko Momoi) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: ja, en, zh-cn, en-us, es-mx MIME-Version: 1.0 To: zhangweiwu@private.21cn.com CC: unicode@unicode.org Subject: Re: the best utf mailer References: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-archive-position: 2265 X-ecartis-version: Ecartis v1.0.0 Sender: unicode-bounce@unicode.org Errors-to: unicode-bounce@unicode.org X-original-sender: momoi@netscape.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-ID: X-List-ID: X-list: unicode Status: O X-Status: X-Keywords: X-UID: 57 Hi, There are quite a few other mailers which support UTF-8 these days. May I suggest Netscape 7 Mail? Others surely can suggest other favorite Mail of theirs. Netscape6/7's thread view is multilingual (if messages use MIME-encoded headers) and it will display any language script supported by encoding/converter libraries we have. The number of encodings is too large to mention here but Netscape 7 certainly supports all major Chinese encodings including GB18030 (with Surrogate range support on Windows). For both body and header displays, MIME-charset info is used and fonts are selected automatically. Reply messages will reflect the encoding of the original mail message. Both view default encoding and send default encoding can be set via Preference Dialog. For each folder, you can set a different fallback encoding to use for displaying messages without MIME charset info. For special folders (or newsgroups), you can also optionally "force" the chosen fallback encoding on all the messages in that folder/newsgroup ignoring incorrect MIME charset headers. (This will probably work well on certain Chinese language newsgroups where MIME info may be non-existent or incorrect.) Netscape 7 supports IMAP, POP3, Netscape Webmail, AOL Mail, AIM, ICQ, S/MIME, 128-bit encryption with certs, can be hooked up to LDAP server for address look up. JavaScript is turned off by default for Mail. It will not execute attachments automatically. Inline attachments can be displayed in a body window, and recognized MIME types such as .doc, .pdf can be opened with helper applications, but exectubale attachments must be saved locally first. There will be no automatic execution of attachments avoiding security risks and viruses. The technical info below, my & Naoki Hotta's Unicode 17 paper on Netscape 6 Mail, is somewhat dated but it may be useful for understanding underlying technologies that support international features in Netscape 7. You can download Simplified Chinese version of Netscape 7 from: http://wp.netscape.com/zh-cn/index.html - Kat Weiwu Zhang wrote: > I have been using Outlook Express for years. I speaks English, Chinese > and some French, the later two language cannot be coded in one single > email in any coding scheme except unicode. Now I'm sending UTF-8 > emails all the time to avoid changing code. > > My problem: > > Is Outlook the only mailer that supports UTF-8 (include the Chinese > part), html sourcing, stationary, certification and encryption? > > I am a HTML source fan; I often edit mail source to make it perfect, > but Outlook Express loves to re-format html emails in some silly way, > especially in UTF-8 mode (moving style definition to body, using > captical html tags, using silly tags like
, and so). > > Endora don't support any Chinese coding. > > I cannot give up encryption too, because I'm in a country where > communication is sometimes watched. > > -- Katsuhiko Momoi Senior International Manager, Web Standards/Embedding Netscape Technology Evangelism/Developer Support __________________________________________________ Try Netscape 7.0 Official Release Download now: http://home.netscape.com/download/index.html Then tell us what you think: http://channels.netscape.com/ns/browsers/7/feedback/default.jsp From selsky@columbia.edu Tue Sep 10 12:48:13 2002 Flags: 000000000001 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8ALlgdp007955; Tue, 10 Sep 2002 17:47:42 -0400 (EDT) Received: (from selsky@localhost) by hazelnut.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8ALlgSb007954; Tue, 10 Sep 2002 17:47:42 -0400 (EDT) Date: Tue, 10 Sep 2002 17:47:42 -0400 From: Matt Selsky To: Benn Oshrin Cc: Melissa Metz , Frank da Cruz , unix@columbia.edu Subject: Re: newcunix Message-ID: <20020910214741.GA7399@columbia.edu> References: <129590000.1031694064@starscream> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <129590000.1031694064@starscream> User-Agent: Mutt/1.4i Status: O X-Status: X-Keywords: X-UID: 58 > >Benno: what if I just copy (or move) /usr/local/lib/movemail into > >/opt/ACISmm/lib? I'm thinking copy, since there is a small chance > >something else depends on the rare /usr/local copy (e.g. emacs RMAIL on > >old cunix). > > Can't see why not... Is /usr/local/lib/movemail the same as "movemail" that is distributed with emacs? See /opt/emacs-20.7/libexec/emacs/20.7/sparc-sun-solaris2.8/movemail and /opt/emacs-21.2/libexec/emacs/21.2/sparc-sun-solaris2.8/movemail We can link to one of those so we have a recently updated version of movemail. From melissa@columbia.edu Wed Sep 11 04:28:10 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8BDS6Bc002701; Wed, 11 Sep 2002 09:28:06 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8BDS6Kc028928; Wed, 11 Sep 2002 09:28:06 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8BDS6h9028927; Wed, 11 Sep 2002 09:28:06 -0400 (EDT) Date: Wed, 11 Sep 2002 9:28:06 EDT From: Melissa Metz To: Matt Selsky Cc: Benn Oshrin , Melissa Metz , Frank da Cruz , unix@columbia.edu Subject: Re: newcunix In-Reply-To: Your message of Tue, 10 Sep 2002 17:47:42 -0400 Message-ID: Status: O X-Status: X-Keywords: X-UID: 59 > Is /usr/local/lib/movemail the same as "movemail" that is distributed > with emacs? Yes. > /opt/emacs-20.7/libexec/emacs/20.7/sparc-sun-solaris2.8/movemail > /opt/emacs-21.2/libexec/emacs/21.2/sparc-sun-solaris2.8/movemail But /usr/local/lib/movemail doesn't change its name so often :-). watsol has /opt/emacs-20.7 and 21.1, which of course have sparc-sun-solaris2.5.1... I'm afraid I don't know how to fix the links. MM only looks for /opt/local/bin/movemail. Would it be easier to symlink the appropriate emacs movemail into /opt/local/bin on each host? --Melissa From fdc@columbia.edu Wed Sep 11 04:50:09 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8BDmQPP020265; Wed, 11 Sep 2002 09:48:27 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8BDmQOU020260; Wed, 11 Sep 2002 09:48:26 -0400 (EDT) Date: Wed, 11 Sep 2002 9:48:26 EDT From: Frank da Cruz To: Melissa Metz Cc: Matt Selsky , Benn Oshrin , Melissa Metz , unix@columbia.edu Subject: Re: newcunix In-Reply-To: Your message of Wed, 11 Sep 2002 9:28:06 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 60 > > Is /usr/local/lib/movemail the same as "movemail" that is distributed > > with emacs? > > Yes. > > > /opt/emacs-20.7/libexec/emacs/20.7/sparc-sun-solaris2.8/movemail > > /opt/emacs-21.2/libexec/emacs/21.2/sparc-sun-solaris2.8/movemail > > But /usr/local/lib/movemail doesn't change its name so often :-). > > watsol has /opt/emacs-20.7 and 21.1, which of course have > sparc-sun-solaris2.5.1... I'm afraid I don't know how to fix the > links. MM only looks for /opt/local/bin/movemail. Would it be easier > to symlink the appropriate emacs movemail into /opt/local/bin on each > host? > Then it will just break again next time a new EMACS is installed or the directory layout reorganized. Too bad we can't use logical names any more. Anyway, having a symlink point at a moving target is hopeless. How often does movemail change? Probably never? In which case it's probably better to have a copy of it in /usr/local/bin that won't move. It might have made more sense to put it in the same directory with the mm executable, which is probably how it used to be when we still subscribed to the /usr/local/bin model. - Frank From selsky@columbia.edu Wed Sep 11 05:29:12 2002 Flags: 000000000001 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8BESndp002933; Wed, 11 Sep 2002 10:28:49 -0400 (EDT) Received: (from selsky@localhost) by hazelnut.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8BESn3X002932; Wed, 11 Sep 2002 10:28:49 -0400 (EDT) Date: Wed, 11 Sep 2002 10:28:49 -0400 From: Matt Selsky To: Frank da Cruz Cc: Melissa Metz , Benn Oshrin , unix@columbia.edu Subject: Re: newcunix Message-ID: <20020911142849.GB2441@columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Status: O X-Status: X-Keywords: X-UID: 61 > It might have made more sense to put it in the same directory with the > mm executable, which is probably how it used to be when we still subscribed > to the /usr/local/bin model. How about we copy movemail from the latest emacs into /opt/ACISmm/bin/movemail (so it will appear in /opt/local/bin/movemail)? movemail doesn't seem to actually need anything from emacs itself. I don't see any paths to /opt in it, but can someone confirm what exactly movemail does? This will eliminate the need to update symlinks and I'm pretty sure movemail doesn't change all that much and we can always copy it over again if there's a newer version that we need. From melissa@columbia.edu Wed Sep 11 06:41:19 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8BFfFBc002942; Wed, 11 Sep 2002 11:41:16 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8BFfFKc001107; Wed, 11 Sep 2002 11:41:15 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8BFfFY6001106; Wed, 11 Sep 2002 11:41:15 -0400 (EDT) Date: Wed, 11 Sep 2002 11:41:15 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz , Matt Selsky , Benn Oshrin , Melissa Metz , unix@columbia.edu Subject: Re: newcunix In-Reply-To: Your message of Wed, 11 Sep 2002 9:48:26 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 62 > Then it will just break again next time a new EMACS is installed or > the directory layout reorganized. No, our /opt system, called opium, generates /opt/local/bin based on a config file. If we list emacs in there it will generate the right link. This should keep working as long as we have emacs. --Melissa From selsky@columbia.edu Wed Sep 11 07:19:02 2002 Flags: 000000000001 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8BGIgdp007074; Wed, 11 Sep 2002 12:18:42 -0400 (EDT) Received: (from selsky@localhost) by hazelnut.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8BGIgLJ007073; Wed, 11 Sep 2002 12:18:42 -0400 (EDT) Date: Wed, 11 Sep 2002 12:18:42 -0400 From: Matt Selsky To: Melissa Metz Cc: Frank da Cruz , Benn Oshrin , unix@columbia.edu Subject: Re: newcunix Message-ID: <20020911161842.GB6585@columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Status: O X-Status: X-Keywords: X-UID: 63 On Wed, Sep 11, 2002 at 11:47:28AM -0400, Melissa Metz wrote: > > > How about we copy movemail from the latest emacs into > > /opt/ACISmm/bin/movemail (so it will appear in /opt/local/bin/movemail)? > > This sounds fine. > > --Mleissa Why is mm in /opt/ACISmisc/bin not /opt/ACISmm/bin? From selsky@columbia.edu Wed Sep 11 07:49:38 2002 Flags: 000000000001 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8BGnFdp008213; Wed, 11 Sep 2002 12:49:15 -0400 (EDT) Received: (from selsky@localhost) by hazelnut.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8BGnFK3008212; Wed, 11 Sep 2002 12:49:15 -0400 (EDT) Date: Wed, 11 Sep 2002 12:49:15 -0400 From: Matt Selsky To: Melissa Metz Cc: Frank da Cruz , Benn Oshrin , unix@columbia.edu Subject: Re: newcunix Message-ID: <20020911164914.GA7940@columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Status: O X-Status: X-Keywords: X-UID: 64 > Maybe we couldn't figure out how to link /opt/ACISmm/bin into > /opt/local/bin? :-) Are there any other mm binaries, etc in /opt/ACISmisc? What are the files that comprise mm? Can I move them into /opt/ACISmm? From selsky@columbia.edu Wed Sep 11 12:54:12 2002 Flags: 000000000001 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8BLrudp018307; Wed, 11 Sep 2002 17:53:56 -0400 (EDT) Received: (from selsky@localhost) by hazelnut.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8BLrulG018306; Wed, 11 Sep 2002 17:53:56 -0400 (EDT) Date: Wed, 11 Sep 2002 17:53:56 -0400 From: Matt Selsky To: Melissa Metz Cc: Frank da Cruz , Benn Oshrin , unix@columbia.edu Subject: Re: newcunix Message-ID: <20020911215356.GJ16768@columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Status: O X-Status: X-Keywords: X-UID: 65 On Wed, Sep 11, 2002 at 02:40:00PM -0400, Melissa Metz wrote: > > > Are there any other mm binaries, etc in /opt/ACISmisc? > > Just mm.old. > > watsol has other files in /usr/local/lib/mm, but I see the ones we are > using are all in /opt/ACISmm/lib. I've replaced the /opt/ACISmm/lib/movemail symlink with an actual copy of movemail. What is /opt/ACISmm/lib/sparc-sun-solaris2.5.1 for? Is a symlink to /opt/emacs-20.7/libexec/emacs/20.7/sparc-sun-solaris2.5.1 Is it still needed? It will break when emacs is upgraded or mm is run on a different version of solaris. Also, any chance we can make the ACISmm layout slightly more FHS-compliant? binaries probably shouldn't be in "lib". But I guess that's for another day. From melissa@columbia.edu Thu Sep 12 05:57:08 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8CEv2cl025025; Thu, 12 Sep 2002 10:57:02 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8CEv2Kc022693; Thu, 12 Sep 2002 10:57:02 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8CEv2SH022692; Thu, 12 Sep 2002 10:57:02 -0400 (EDT) Date: Thu, 12 Sep 2002 10:57:01 EDT From: Melissa Metz To: Matt Selsky Cc: Melissa Metz , Frank da Cruz , Benn Oshrin , unix@columbia.edu Subject: Re: newcunix In-Reply-To: Your message of Wed, 11 Sep 2002 17:53:56 -0400 Message-ID: Status: O X-Status: X-Keywords: X-UID: 66 > I've replaced the /opt/ACISmm/lib/movemail symlink with an actual copy > of movemail. Thanks. > What is /opt/ACISmm/lib/sparc-sun-solaris2.5.1 for? It is dated yesterday. Looks like a mistake. Could have been me. > Also, any chance we can make the ACISmm layout slightly more > FHS-compliant? binaries probably shouldn't be in "lib". But I guess > that's for another day. My MM is configured to run /opt/local/bin/movemail (in my personal config file). Due to /opt/ACISlinks/bin, this is symlinked directly to /usr/local/lib/mm/movemail. The central MM seems to look for /usr/local/lib/mm/movemail. It seems like movemail should be in ACISmm/bin (and then we remove the link in ACISlinks). I think there aren't that many of us running MM anymore... Apparently those of us running on FHS systems are already set up to use /opt/local/bin. --Melissa From fdc@columbia.edu Thu Sep 12 06:08:00 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8CF6MPP010740; Thu, 12 Sep 2002 11:06:22 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8CF6MhY010739; Thu, 12 Sep 2002 11:06:22 -0400 (EDT) Date: Thu, 12 Sep 2002 11:06:22 EDT From: Frank da Cruz To: Melissa Metz Cc: Matt Selsky , Melissa Metz , Benn Oshrin , unix@columbia.edu Subject: Re: newcunix In-Reply-To: Your message of Thu, 12 Sep 2002 10:57:01 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 67 > > Also, any chance we can make the ACISmm layout slightly more > > FHS-compliant? binaries probably shouldn't be in "lib". But I guess > > that's for another day. > > My MM is configured to run /opt/local/bin/movemail (in my personal > config file). Due to /opt/ACISlinks/bin, this is symlinked directly > to /usr/local/lib/mm/movemail. The central MM seems to look for > /usr/local/lib/mm/movemail. > Right, because that's the built-in path: pathnames.h:#define MOVEMAIL "/usr/local/lib/mm/movemail" I agree that putting executables in /usr/local/lib/ might not be appropriate; I could change MM to look in (say) /usr/local/bin/ or /usr/local/bin/mm/, but that would only upset everybody who uses it and has dealt in one way (symlinks) or another (SET MOVEMAIL-PATH) with its default movemail path all these years. > It seems like movemail should be in > ACISmm/bin (and then we remove the link in ACISlinks). I think there > aren't that many of us running MM anymore... Apparently those of us > running on FHS systems are already set up to use /opt/local/bin. > Too bad Unix file systems don't have access counts so we could see how many people actually load the MM executable each day... Anyway, no worries as long as mm can fine movemail in /usr/local/lib/mm/. - Frank From melissa@columbia.edu Thu Sep 12 06:37:11 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by apakabar.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8CFb400010422; Thu, 12 Sep 2002 11:37:04 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8CFb3Kc023391; Thu, 12 Sep 2002 11:37:03 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8CFb3IY023390; Thu, 12 Sep 2002 11:37:03 -0400 (EDT) Date: Thu, 12 Sep 2002 11:37:03 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz , Matt Selsky , Melissa Metz , Benn Oshrin , unix@columbia.edu Subject: Re: newcunix In-Reply-To: Your message of Thu, 12 Sep 2002 11:06:22 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 68 > Too bad Unix file systems don't have access counts so we could see how > many people actually load the MM executable each day... This can be determined from accounting records if we wanted to search all over for it. Probably not worth it right now. --Melissa From melissa@columbia.edu Thu Sep 12 10:40:51 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8CJehfF005090; Thu, 12 Sep 2002 15:40:44 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8CJehKc027250; Thu, 12 Sep 2002 15:40:43 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8CJegoo027249; Thu, 12 Sep 2002 15:40:42 -0400 (EDT) Date: Thu, 12 Sep 2002 15:40:42 EDT From: Melissa Metz To: Matt Selsky Cc: Melissa Metz , Frank da Cruz , Benn Oshrin , unix@columbia.edu Subject: Re: newcunix In-Reply-To: Your message of Thu, 12 Sep 2002 14:44:45 -0400 Message-ID: Status: O X-Status: X-Keywords: X-UID: 69 > mm doesn't support IMAP, right? So people will have to stop using it > when we move to Cyrus or whatever. MM doesn't need to support IMAP. movemail does (or did). So those sly MM users can just suck their mail out of the IMAP server and stash it in their home directories. > Where do most people look for movemail in their .mmrc? Or do they > just use the global mm.conf? Most people do not run MM. There may be some on cunix (as on watsol) using the global mm.conf and accessing /usr/local/lib/mm/ on cunix. There are probably a few like me who updated their own .mminit. I guess the newcunix mm.conf should set the movemail-path to /opt/... This will work on old cunix as well so I guess we could set it globally... --Melissa From fdc@columbia.edu Sun Sep 15 14:40:52 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8FNekV5025645; Sun, 15 Sep 2002 19:40:46 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8FNejxo025639; Sun, 15 Sep 2002 19:40:45 -0400 (EDT) Sender: Frank da Cruz Date: Sun, 15 Sep 2002 19:40:44 EDT From: Frank da Cruz To: bug-mm@columbia.edu Cc: unix@columbia.edu, kermites@columbia.edu, Ken Harrenstien Subject: New MM Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Status: O X-Status: X-Keywords: X-UID: 70 Well I think I have MM about where I can live with it: . It hardly ever truncates outbound messages any more upon return from EMACS, even on really bad NFS days. And if it does, now you can get the message back from the temp file. . I removed most of the verbose debugging messages from earlier versions; now it must tells you the .mm-outgoing name. . I can use it to send 8-bit text messages (Latin-1, UTF-8, etc). In fact this is one: Grüße aus Köln (well, Nueva York :-) (Also see new headers above.) It builds fine on Solaris. A Solaris 2.5.1 binary is here: ~fdc/bin.solaris/mm The updated MM and CCMD sources are here: ftp://kermit.columbia.edu/kermit/mm/mm-ccmd-fdc-a20915.tar.gz It includes all my changes and all of Ken Harrenstein's changes, which are documented in the included README.TXT file, which also explains how to use the 8-bit features. But (of course there is always a But)... It just plain will not build on Linux -- it bombs immediately with syntax errors in /usr/include/string.h. Notes at the end of README.TXT. Can anyone dope this out? - Frank From fdc@columbia.edu Mon Sep 16 09:36:47 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8GIajV5001573 for ; Mon, 16 Sep 2002 14:36:45 -0400 (EDT) Received: by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8GIajFo001572 for fdc; Mon, 16 Sep 2002 14:36:45 -0400 (EDT) Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail From: fdc@columbia.edu (Frank da Cruz) Newsgroups: alt.sys.pdp10 Subject: New Columbia MM Date: 16 Sep 2002 13:37:49 -0400 Organization: Columbia University Lines: 29 Message-ID: NNTP-Posting-Host: watsol.cc.columbia.edu X-Trace: newsmaster.cc.columbia.edu 1032197871 16620 128.59.39.139 (16 Sep 2002 17:37:51 GMT) X-Complaints-To: postmaster@columbia.edu NNTP-Posting-Date: 16 Sep 2002 17:37:51 GMT Xref: newsmaster.cc.columbia.edu alt.sys.pdp10:23124 Content-Type: text To: undisclosed-recipients:; Status: O X-Status: X-Keywords: X-UID: 71 I did some more work on Columbia MM (the C-language one that runs on Solaris, etc). The main thing was to cut down on the truncations of outgoing messages upon return from the editor (especially when working on an NFS-mounted disk). Apparently you can never have a 100% guarantee of this on Sun OS's -- the situation is much improved, but as a fallback, now MM defers deleting the temp file that the editor writes out so you can get it back in case of emergency. While I was at it, I figured out a crude way to use MM for 8-bit text, and now I can read, reply to, and send mail in ISO-8859-1, KOI8-R, UTF-8, you name it. The new version, 0.91, builds and runs on SunOS 4.1.3 and Solaris 2.5.1 and later. I tried to build it on Linux and it blew up instantly -- maybe somebody can fix this? I didn't even try it on AIX, HP-UX, etc. Guinea-pigs/volunteers welcome. The updated MM/CCMD package (which also includes a ton of fixes from Ken Harrenstein) is here: ftp://kermit.columbia.edu/kermit/mm/mm-ccmd-fdc.tar.gz When you unpack this, it makes a "work" directory containing a README.TXT file (a brief edit history from Ken H and me) and an EIGHTBIT.TXT file (explanation of how to use the 8-bit features), and then the regular ccmd and mm subdirectories. - Frank From ishikawa@yk.rim.or.jp Mon Sep 16 15:32:11 2002 Flags: 000000000001 Return-Path: Received: from standard.erephon (pl1062.nas911.n-yokohama.nttpc.ne.jp [210.139.43.38]) by apakabar.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8H0W2Bk009086 for ; Mon, 16 Sep 2002 20:32:06 -0400 (EDT) Received: from yk.rim.or.jp (really [127.0.0.1]) by yk.rim.or.jp via smail with esmtp id (Debian Smail3.2.0.114) for ; Tue, 17 Sep 2002 09:31:52 +0900 (JST) Sender: ishikawa@columbia.edu Message-ID: <3D8677F7.CCBDAB87@yk.rim.or.jp> Date: Tue, 17 Sep 2002 09:31:51 +0900 From: Ishikawa X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: ja, en MIME-Version: 1.0 To: Frank da Cruz Subject: Re: New Columbia MM References: Content-Type: multipart/mixed; boundary="------------7D580C608DFE4CEACD55C7B3" Status: O X-Status: X-Keywords: X-UID: 72 This is a multi-part message in MIME format. --------------7D580C608DFE4CEACD55C7B3 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Frank da Cruz wrote: Hi, I fixed the tar file to compile your tar file on linux. Please see the attached comment and the diff file. (ccmd library would have tough competition in the linux/unix area since we have already GNU readline package and now that the BASH shell interpreter incorporates the programmable completion feature. But I it still is viable in the writers of application programs, I suppose.) I am not sure if MM catches up, but I believe that a source tar file that can be compiled is the very first step it can take into linux field. Thank you again for your kermit work, etc.. I thought of simply posting the newsgroup, but I was afraid that the attachment may be not allowed to non-binary newsgroups (the attachments are often stripped by intervening newsservers before people read the article.) > I did some more work on Columbia MM (the C-language one that runs on > Solaris, etc). The main thing was to cut down on the truncations of > outgoing messages upon return from the editor (especially when working > on an NFS-mounted disk). Apparently you can never have a 100% guarantee > of this on Sun OS's -- the situation is much improved, but as a fallback, > now MM defers deleting the temp file that the editor writes out so you > can get it back in case of emergency. > > While I was at it, I figured out a crude way to use MM for 8-bit text, > and now I can read, reply to, and send mail in ISO-8859-1, KOI8-R, UTF-8, > you name it. > > The new version, 0.91, builds and runs on SunOS 4.1.3 and Solaris 2.5.1 > and later. I tried to build it on Linux and it blew up instantly -- > maybe somebody can fix this? I didn't even try it on AIX, HP-UX, etc. > Guinea-pigs/volunteers welcome. > > The updated MM/CCMD package (which also includes a ton of fixes from > Ken Harrenstein) is here: > > ftp://kermit.columbia.edu/kermit/mm/mm-ccmd-fdc.tar.gz > > When you unpack this, it makes a "work" directory containing a > README.TXT file (a brief edit history from Ken H and me) and an > EIGHTBIT.TXT file (explanation of how to use the 8-bit features), > and then the regular ccmd and mm subdirectories. > > - Frank Here is a patch to compile the available tar under linux: (Debian GNU/Linux, but it should compile all right under other linux distribution.) A few comment: ======================================== ccmd: ---------------------------------------- "test" program linking failed since the system could not find -ltermlib library. I chose a different lib, namely, -ltermcap and the "test" program linked fine. (But I didin't modify the Makefile for this minor change. So making test still fails when we run make linux.) The link command line then was as follows: cc -g -DHAVE_BSTRING -DHAVE_TZ_BSD -DCCMD_OS_LINUX -o test test.o ccmd.a -ltermcap My quick testing showed that the linked "test" program seemed to work fine (but I don't know if the "match" command is working as expected... It seems to have somthing to do with date/time and as I note here, there were a few compilation issues regarding date/time-related functions.) Except that now I reliaze there are a few places where mktemp() function is used. Security-wise, the use of mktemp() has opened up a few bugs in recent years, and now its use is discouraged, and instead mkstemp() is suggested for its replacement. However, due to the slight sematincal change (mktemp() returns the suggested filename, whereas mkstemp() opens the suggested file on user's part) one place where mkstemp() is used is not quite easy to fix in 5-10 minutes hacking :-) So I just put in a comment. On my Debign GNU/Linux, gnu ld warns us about the dangerous usage of mktemp() and suggests the use of mkstemp() instead. But the program IS linked and left albeit the warning. ishikawa@duron$ cc -g -o test test.o ccmd.a -ltermcap ccmd.a(cmpara.o): In function `executeact': /ide-s-master/tools/work/ccmd/cmpara.c:747: the use of `mktemp' is dangerous, better use `mkstemp' ishikawa@duron$ ======================================== mm: ---------------------------------------- After fixing the ccmd above, mm seemed to link all right. With the attached few tweakings, the program compiled and linked. The warning about the use of mktemp() also applies here. gcc -g -DDEBUG -o mm action.o address.o alias.o babyl.o browse.o cmds.o compat.o dates.o debug.o display.o doinit.o dt.o edit.o exit.o file.o formattab.o headers.o help.o init.o keywords.o mailrc.o mbox.o mh.o misc.o mm.o more.o move.o mtxt.o newmail.o novice.o parse.o parsemsg.o pop2.o pop3.o print.o rd.o read.o send.o sendcmds.o sendmail.o seq.o set.o signals.o support.o token.o usage.o whoami.o version.o ../ccmd/ccmd.a -ltermcap ../ccmd/ccmd.a(cmpara.o): In function `executeact': /ide-s-master/tools/work/ccmd/cmpara.c:747: the use of `mktemp' is dangerous, better use `mkstemp' ... gcc -g -DDEBUG -I../ccmd -DMM_OS_LINUX -c sys-prof.c /bin/rm -f sys-prof gcc -g -DDEBUG -I../ccmd -DMM_OS_LINUX -o sys-prof sys-prof.o formattab.o ../ccmd/ccmd.a -ltermcap ../ccmd/ccmd.a(cmpara.o): In function `executeact': /ide-s-master/tools/work/ccmd/cmpara.c:747: the use of `mktemp' is dangerous, better use `mkstemp' ---- You might decided to create a config.h.linux for reference in your tar file for linux users, etc.. Thank you again for your software. --------------7D580C608DFE4CEACD55C7B3 Content-Type: text/plain; charset=iso-2022-jp; name="t.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="t.diff" /ide-s-master/tools/work/ccmd /ide-s-master/tools/work /ide-s-master/tools/work ======================================== /ide-s-master/tools/work/ccmd *** Makefile 2002/09/16 23:33:58 1.1 --- Makefile 2002/09/17 00:01:42 *************** *** 196,203 **** decosf: $(MAKE) OS="-DCCMD_OS_DECOSF" OSLIBS= RANLIB=: all linux: ! $(MAKE) OS="-DCCMD_OS_LINUX" OSLIBS= all solaris: $(MAKE) CC=gcc OS="-DCCMD_OS_SOLARIS" OSLIBS= RANLIB=: all --- 196,206 ---- decosf: $(MAKE) OS="-DCCMD_OS_DECOSF" OSLIBS= RANLIB=: all + # added HAVE_BSTRING, HAVE_TZ_BSD ci. # + # timezone might need better handling under linux. + linux: ! $(MAKE) OS="-DHAVE_BSTRING -DHAVE_TZ_BSD -DCCMD_OS_LINUX" OSLIBS= all solaris: $(MAKE) CC=gcc OS="-DCCMD_OS_SOLARIS" OSLIBS= RANLIB=: all *** ccmdlib.h 2002/09/16 23:40:26 1.1 --- ccmdlib.h 2002/09/16 23:42:11 *************** *** 62,67 **** --- 62,73 ---- #include #endif + /* a kludge (linux) by CI. */ + #if __linux__ + #include + #include + #endif + /* * We need one or more of unistd.h, fcntl.h, and sys/file.h. */ *** cmpara.c 2002/09/16 23:52:30 1.1 --- cmpara.c 2002/09/16 23:58:12 *************** *** 596,611 **** --- 596,626 ---- #if CCMD_OS_UNIX strcpy(fname,"/tmp/cmdXXXXXX"); /* get a file name */ + #if !__linux__ mktemp(fname); + #endif #else strcpy(fname,mktemp(getenv("TMP"),"cmd")); /* get a file name */ #endif + + #if __linux__ + + fd = mkstemp(fname); + if (fd < 0) { + cmxputs("?Could not create temporary file.\n"); + perror(fname); + return(text); + } + + #else fd = open(fname,O_WRONLY|O_CREAT,0700); /* open the tmp file */ if (fd < 0) { cmxputs("?Could not create temporary file.\n"); perror(fname); return(text); } + #endif + if (write(fd,text,strlen(text)) != strlen(text)) { cmxputs("?Could not write temporary file.\n"); perror(fname); *************** *** 734,739 **** --- 749,762 ---- strcpy(fname,mktemp(getenv("TMP"),"cmd")); /* get a file name */ #endif + /*CI: TODO/FIXME: a slight security problem here + in creating the temporary file and its usage. + We are creating a supposedly temporary file and + run a command to write to it. + "cmd > fname" + */ + + cmd = (char *) cmrealloc (cmd, strlen(cmd)+strlen(fname)+strlen(" > ")+1); strcat (cmd, " > "); strcat (cmd, fname); /ide-s-master/tools/work /ide-s-master/tools/work /ide-s-master/tools/work/mm /ide-s-master/tools/work /ide-s-master/tools/work ======================================== /ide-s-master/tools/work/mm *** config.h 2002/09/16 23:45:05 1.1 --- config.h 2002/09/16 23:49:18 *************** *** 7,13 **** #ifdef RCSID #ifndef lint ! static char *config_rcsid = "$Header: /ide-s-master/tools/work/mm/RCS/config.h,v 1.1 2002/09/16 23:45:05 ishikawa Exp ishikawa $"; #endif #endif /* RCSID */ --- 7,13 ---- #ifdef RCSID #ifndef lint ! static char *config_rcsid = "$Header: /ide-s-master/tools/work/mm/config.h,v 1.1 2002/09/16 23:45:05 ishikawa Exp ishikawa $"; #endif #endif /* RCSID */ *************** *** 17,23 **** /* First get general sys-dependent stuff for appropriate OS */ ! #include "sysh/s-sun58.h" /* Now apply any desired modifications to stuff from s-*.h */ --- 17,28 ---- /* First get general sys-dependent stuff for appropriate OS */ ! #include "sysh/s-linux.h" ! ! /* compile fix CI*/ ! #define HAVE_BSTRING ! #include ! /* Now apply any desired modifications to stuff from s-*.h */ *************** *** 45,47 **** --- 50,53 ---- #undef HAVE_QUOTAS /* have and use quota support? */ #define USAGE /* Compile usage logging */ + *** dates.c 2002/09/16 23:47:35 1.1 --- dates.c 2002/09/16 23:47:48 *************** *** 6,12 **** */ #ifndef lint ! static char *rcsid = "$Header: /ide-s-master/tools/work/mm/RCS/dates.c,v 1.1 2002/09/16 23:47:35 ishikawa Exp ishikawa $"; #endif /* --- 6,12 ---- */ #ifndef lint ! static char *rcsid = "$Header: /ide-s-master/tools/work/mm/dates.c,v 1.1 2002/09/16 23:47:35 ishikawa Exp ishikawa $"; #endif /* *************** *** 16,21 **** --- 16,25 ---- #include "mm.h" #include /* Now use gettimeofday */ + #if __linux__ + #include + #endif + static int dayspermonth[] = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }; char *month_names[] = { --------------7D580C608DFE4CEACD55C7B3-- From azz@azz.us-lot.org Mon Sep 16 16:26:23 2002 Flags: 000000000001 Return-Path: Received: from pinky.notnet.co.uk ([80.253.110.55]) by apakabar.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8H1QJBl000647 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 16 Sep 2002 21:26:22 -0400 (EDT) Received: from [smtp@fivegeeks.net@]vindaloo.fivegeeks.net ([81.91.98.20] helo=vindaloo.at.fivegeeks.net) by pinky.notnet.co.uk with asmtp id 17r784-0004a6-00 for fdc@columbia.edu; Tue, 17 Sep 2002 02:26:16 +0100 Received: from cartman.at.fivegeeks.net ([192.168.58.25] ident=OneGeek) by vindaloo.at.fivegeeks.net with esmtp (Exim 3.35 #1 (Debian)) id 17r792-0002JA-00 for ; Tue, 17 Sep 2002 02:27:16 +0100 Received: from azz by cartman.at.fivegeeks.net with local (Exim 4.10) id 17r77z-0007PP-00 for fdc@columbia.edu; Tue, 17 Sep 2002 02:26:11 +0100 To: fdc@columbia.edu (Frank da Cruz) Subject: Re: New Columbia MM References: From: Adam Sampson Organization: Don't wake me, 'cos I'm dreaming, and I might just stay inside again today. Date: 17 Sep 2002 02:26:11 +0100 In-Reply-To: Message-ID: Lines: 84 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Adam Sampson X-Notnet-Virus-Scan: No viruses found, Definitions updated Tue Sep 17 02:00:02 BST 2002 X-Notnet-Spam-Flag: NO X-Notnet-Spam-Status: No, hits=-9.4 required=5 tests=IN_REP_TO,UNIFIED_PATCH X-Notnet-Spam-Checker: Spamassassin v.2.20 Status: O X-Status: X-Keywords: X-UID: 73 fdc@columbia.edu (Frank da Cruz) writes: > The new version, 0.91, builds and runs on SunOS 4.1.3 and Solaris 2.5.1 > and later. I tried to build it on Linux and it blew up instantly -- > maybe somebody can fix this? The following patches make it at least compile and run; I haven't tested it extensively. diff -Naur work/ccmd/Makefile mm-linux-fixes/ccmd/Makefile --- work/ccmd/Makefile Thu Feb 21 05:20:47 2002 +++ mm-linux-fixes/ccmd/Makefile Tue Sep 17 02:10:51 2002 @@ -249,10 +249,10 @@ @$(RANLIB) $(LIBRARY) test: test.o $(LIBRARY) - $(CC) $(CFLAGS) -o $@ $@.o $(LIBRARY) -ltermlib $(OSLIBS) + $(CC) $(CFLAGS) -o $@ $@.o $(LIBRARY) -lncurses $(OSLIBS) skel: skel.o $(LIBRARY) - $(CC) $(CFLAGS) -o $@ $@.o $(LIBRARY) -ltermlib $(OSLIBS) + $(CC) $(CFLAGS) -o $@ $@.o $(LIBRARY) -lncurses $(OSLIBS) cmfncs.h cmfnc.h: $(M4FILES) split.awk m4 cmfnc.h4 | awk -f split.awk diff -Naur work/ccmd/machdep.h mm-linux-fixes/ccmd/machdep.h --- work/ccmd/machdep.h Thu Feb 21 05:16:08 2002 +++ mm-linux-fixes/ccmd/machdep.h Tue Sep 17 02:10:00 2002 @@ -134,7 +134,7 @@ #endif #ifndef HAVE_BSTRING /* System has bcopy/bzero/bcmp? */ -# define HAVE_BSTRING (CCMD_OS_BSD) +# define HAVE_BSTRING (CCMD_OS_BSD|CCMD_OS_LINUX) #endif #ifndef HAVE_VOIDSIG /* System sig handlers declared as void? */ @@ -165,7 +165,7 @@ #endif #ifndef HAVE_TZ_SYSV /* Have SYSV "extern timezone;" crock? */ -# define HAVE_TZ_SYSV (CCMD_OS_SYSV) +# define HAVE_TZ_SYSV (CCMD_OS_SYSV|CCMD_OS_LINUX) #endif #ifndef HAVE_VFPRINTF /* Have ANSI vfprintf() ? */ diff -Naur work/mm/Makefile mm-linux-fixes/mm/Makefile --- work/mm/Makefile Sun Sep 15 23:27:47 2002 +++ mm-linux-fixes/mm/Makefile Tue Sep 17 02:21:58 2002 @@ -128,7 +128,7 @@ $(MAKE) OS="-DMM_OS_DECOSF" OSLIBS="-ltermcap" all linux: - $(MAKE) OS="-DMM_OS_LINUX" OSLIBS="-ltermcap" all + $(MAKE) OS="-DMM_OS_LINUX" OSLIBS="-lncurses" all # fdc's Solaris entry includes truncation-protection code after editing. # Not sure I understand the difference in the OSLIBS clause... diff -Naur work/mm/sysh/s-linux.h mm-linux-fixes/mm/sysh/s-linux.h --- work/mm/sysh/s-linux.h Sat Feb 23 10:17:27 2002 +++ mm-linux-fixes/mm/sysh/s-linux.h Tue Sep 17 02:20:41 2002 @@ -70,7 +70,7 @@ * the other, or both, as appropriate. */ #define NEED_SYSTIME /* include */ -#undef NEED_TIME /* don't include */ +#define NEED_TIME /* don't include */ /* * Define NEED_WAIT if your system defines "union wait" in @@ -116,7 +116,7 @@ * are usually present on BSD-based systems, and missing on older systems * where MM will use memcpy(3), memset(3), and memcmp(3). */ -#undef HAVE_BSTRING /* we have bcopy and friends */ +#define HAVE_BSTRING /* we have bcopy and friends */ /* * Define HAVE_VFORK if your system has the vfork(2) system call. Hope this helps, -- Adam Sampson From ishikawa@yk.rim.or.jp Tue Sep 17 04:21:31 2002 Flags: 000000000011 Return-Path: Received: from standard.erephon (pl1438.nas911.n-yokohama.nttpc.ne.jp [210.139.44.158]) by apakabar.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8HNLTVU016248 for ; Tue, 17 Sep 2002 19:21:30 -0400 (EDT) Received: from yk.rim.or.jp (really [127.0.0.1]) by yk.rim.or.jp via smail with esmtp id (Debian Smail3.2.0.114) for ; Wed, 18 Sep 2002 08:21:25 +0900 (JST) Sender: ishikawa@columbia.edu Message-ID: <3D87B8F4.C34E091C@yk.rim.or.jp> Date: Wed, 18 Sep 2002 08:21:24 +0900 From: Ishikawa X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: ja, en MIME-Version: 1.0 To: Frank da Cruz Subject: Re: New Columbia MM References: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Status: O X-Status: X-Keywords: X-UID: 74 Hi, Frank da Cruz wrote: > > > I fixed the tar file to compile your tar file > > on linux. Please see the attached comment and > > the diff file. > > > Thanks! You are very welcome. Now come to think of it, the change I made for linux in mm/config.h probably should go into s-linux.h. You can figure that out easily. Just move the include and the define into s-linux.h and all is set, I think. > > (ccmd library would have tough competition > > in the linux/unix area since we have already > > GNU readline package and now > > that the BASH shell interpreter > > incorporates the programmable completion > > feature. But I it still is viable > > in the writers of application programs, I suppose.) > > > Well, CCMD was never used for anything serious except > MM anyway. Of course it predates GNU readline by > many years, but there is no point changing MM to use > readline -- much work for little or no advantage. Is this CCMD different from the kermit command input handler? (Just curious.) > > I am not sure if MM catches up, but > > I believe that a source tar file that can be compiled > > is the very first step it can take into linux > > field. > > > It worked in Linux long ago, but then Linux changed out > from under it. This is the first time it has been > updated in 12 years. Aga. 12 years! It IS a long time, isn't it? > > Thank you again for your kermit work, etc.. > > > My pleasure :-) > > - Frank Again thank you very much! Happy Hacking, Ishikawa, Chiaki PS: I have not tested MM yet very much and so I will let someone else to be the guinea pig for it under linux :-) At least, it compiles now, so. From fdc@columbia.edu Tue Sep 17 12:25:44 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8HLPhV5010658; Tue, 17 Sep 2002 17:25:43 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8HLPgVw010657; Tue, 17 Sep 2002 17:25:42 -0400 (EDT) Date: Tue, 17 Sep 2002 17:25:42 EDT From: Frank da Cruz To: Ishikawa Subject: Re: New Columbia MM In-Reply-To: Your message of Tue, 17 Sep 2002 09:31:51 +0900 Message-ID: Status: O X-Status: X-Keywords: X-UID: 75 > I fixed the tar file to compile your tar file > on linux. Please see the attached comment and > the diff file. > Thanks! > (ccmd library would have tough competition > in the linux/unix area since we have already > GNU readline package and now > that the BASH shell interpreter > incorporates the programmable completion > feature. But I it still is viable > in the writers of application programs, I suppose.) > Well, CCMD was never used for anything serious except MM anyway. Of course it predates GNU readline by many years, but there is no point changing MM to use readline -- much work for little or no advantage. > I am not sure if MM catches up, but > I believe that a source tar file that can be compiled > is the very first step it can take into linux > field. > It worked in Linux long ago, but then Linux changed out >From under it. This is the first time it has been updated in 12 years. > Thank you again for your kermit work, etc.. > My pleasure :-) - Frank From fdc@columbia.edu Tue Sep 17 12:26:47 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8HLQkV5011032; Tue, 17 Sep 2002 17:26:46 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8HLQjmQ011031; Tue, 17 Sep 2002 17:26:45 -0400 (EDT) Date: Tue, 17 Sep 2002 17:26:45 EDT From: Frank da Cruz To: Adam Sampson Subject: Re: New Columbia MM In-Reply-To: Your message of 17 Sep 2002 02:26:11 +0100 Message-ID: Status: O X-Status: X-Keywords: X-UID: 76 > The following patches make [MM] at least compile and run; I haven't > tested it extensively. > Many thanks, very helpful. It seems to be OK in Linux now. I posted a new version just now (in the same place) and announced on alt.sys.pdp10. - Frank From melissa@columbia.edu Tue Sep 17 14:12:35 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8IECX3K001139; Wed, 18 Sep 2002 10:12:33 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8IECXKc012619; Wed, 18 Sep 2002 10:12:33 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8IECXO4012618; Wed, 18 Sep 2002 10:12:33 -0400 (EDT) Date: Wed, 18 Sep 2002 10:12:33 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz , bug-mm@columbia.edu Subject: Re: New MM In-Reply-To: Your message of Tue, 17 Sep 2002 20:21:52 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 77 Hmm, that doesn't sound familiar to me. The biggest problem we had with date-and-time was Daylight Savings Time :-). Another issue can be, in some formats, a difference between when the message was sent ("Date:" header) and when it arrived (the first line -- "From " or the mail.txt equivalent). e.g. this message shows a bug: 1-Jun-2002 20:05:19-GMT,880;000000000001 ... Date: Sat, 1 Jun 2002 21:05:13 -0400 The message was delivered in 8 seconds, but if you do the math it took negative 3 hours. This sort of incremental change (we get it with DST) eventually changes the date. --Melissa From fdc@columbia.edu Tue Sep 17 15:17:28 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8I0HRV5029280; Tue, 17 Sep 2002 20:17:27 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8I0HRck029279; Tue, 17 Sep 2002 20:17:27 -0400 (EDT) Date: Tue, 17 Sep 2002 20:17:27 EDT From: Frank da Cruz To: Ishikawa Subject: Re: New Columbia MM In-Reply-To: Your message of Wed, 18 Sep 2002 08:21:24 +0900 Message-ID: Status: O X-Status: X-Keywords: X-UID: 78 > Now come to think of it, the change I made > for linux in mm/config.h probably should go into > s-linux.h. > Yes, I caught that, thanks. > Is this CCMD different from the kermit > command input handler? (Just curious.) > Yes, it's different. At the time I added the interactive command parser to C-Kermit, CCMD wasn't quite ready yet (and it was getting too big and complicated). Since then I added things to C-Kermit's parser that CCMD does not have, such string replacement (variables). - Frank From fdc@columbia.edu Tue Sep 17 15:21:54 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8I0LqV5029738; Tue, 17 Sep 2002 20:21:52 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8I0LqPQ029737; Tue, 17 Sep 2002 20:21:52 -0400 (EDT) Date: Tue, 17 Sep 2002 20:21:52 EDT From: Frank da Cruz To: Melissa Metz cc: bug-mm@columbia.edu Subject: New MM Message-ID: Status: O X-Status: X-Keywords: X-UID: 79 The new MM is pretty nice, but I seem to have broken something: "headers since blah" works unpredictably; e.g. "headers flagged since yesterday". Sometimes it misses them all, sometimes it goes back to the day before yesterday or the day before that. Does this ring a bell? I'm not aware of having touched any code that interprets message sequences or dates or times. (I wouldn't be surprised if this happened in Linux, but I'm talking about Solaris...) - Frank From fdc@columbia.edu Wed Sep 18 06:15:08 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8IFF10H017824; Wed, 18 Sep 2002 11:15:01 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8IFF1OI017814; Wed, 18 Sep 2002 11:15:01 -0400 (EDT) Date: Wed, 18 Sep 2002 11:15:00 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: New MM In-Reply-To: Your message of Wed, 18 Sep 2002 10:12:33 EDT Cc: bug-mm@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 80 > Hmm, that doesn't sound familiar to me. The biggest problem we had > with date-and-time was Daylight Savings Time... > I see now that MM is doing it right, but displaying it wrong. In 0.90: MM>h since yes 213) 17-Sep Frank da Cruz Re: New Columbia MM (1100 chars) 214) 17-Sep Frank da Cruz New MM (1015 chars) 215) 17-Sep Frank da Cruz Re: Kermit 95 2.0 (2259 chars) 216) 17-Sep Frank da Cruz Re: watsol print queue (1066 chars) ... But in 0.91: MM>h since yes 213) 16-Sep Frank da Cruz Re: New Columbia MM (1100 chars) 214) 16-Sep Frank da Cruz New MM (1015 chars) 215) 16-Sep Frank da Cruz Re: Kermit 95 2.0 (2259 chars) 216) 16-Sep Frank da Cruz Re: watsol print queue (1066 chars) It's the display of the date in the HEADERS command that's off (the actual date of these messages is 17-Sep). I didn't go near any of that code so it will be tricky to track down but I'll give it a shot. - Frank From fdc@columbia.edu Wed Sep 18 06:44:03 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8IFhw0H022375; Wed, 18 Sep 2002 11:43:58 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8IFhvrI022374; Wed, 18 Sep 2002 11:43:57 -0400 (EDT) Date: Wed, 18 Sep 2002 11:43:57 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: New MM In-Reply-To: Your message of Wed, 18 Sep 2002 11:36:08 EDT Cc: bug-mm@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 81 > > the actual date of these messages is 17-Sep) > > But is it early enough on 17-Sep to look like 16-Sep in another time > zone? > I don't think so! MM>type 213 Message 213 (1100 chars) Date: Tue, 17 Sep 2002 20:17:27 EDT From: Frank da Cruz To: Ishikawa Subject: Re: New Columbia MM In-Reply-To: Your message of Wed, 18 Sep 2002 08:21:24 +0900 ... MM>h 213 213) 16-Sep Frank da Cruz Re: New Columbia MM (1100 chars) MM> > > Whereas the one I'm using includes "s-sun58.h". Could that be the > > difference? If so, then I'd guess that s-sun58.h needs some work? > > I'm pretty certain we had not previously compiled for sun58, maybe > sun55. I don't think we would have used bsd43, though. > Hmmmm.... Oddly enough the Linux version (s-linux.h) is behaving exactly like the new Solaris one. Anyway, I see there are some differences between s-sun55.h and s-sun58.h; I'll try s-sun55.h, thanks. - Frank From fdc@columbia.edu Wed Sep 18 07:02:14 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8IG220H025146; Wed, 18 Sep 2002 12:02:02 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8IG22DY025145; Wed, 18 Sep 2002 12:02:02 -0400 (EDT) Date: Wed, 18 Sep 2002 12:02:01 EDT From: Frank da Cruz To: Melissa Metz Cc: bug-mm@columbia.edu Subject: Re: New MM In-Reply-To: Your message of Wed, 18 Sep 2002 11:46:33 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 82 > > Date: Tue, 17 Sep 2002 20:17:27 EDT > > Check the "envelope" header, the one that MM won't show you but it's > parsing it for its internal time sense. You have to use "more" to read > the file, not MM. > My golly you're right! >From fdc@columbia.edu Mon Sep 16 09:17:28 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8I0HRV5029280; Tue, 17 Sep 2002 20:17:27 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8I0HRck029279; Tue, 17 Sep 2002 20:17:27 -0400 (EDT) Date: Tue, 17 Sep 2002 20:17:27 EDT From: Frank da Cruz To: Ishikawa Subject: Re: New Columbia MM In-Reply-To: Your message of Wed, 18 Sep 2002 08:21:24 +0900 Message-ID: This is quite strange. I sent the message last night. Why would the >From line indicate the morning of the previous day? (Who adds the From line? Sendmail?) Plus it's funny that the message is In-Reply-To a message >From Ishikawa from a day in the future; but of course that's because Japan is across the International Date Line... Btw, when I switch from s-sun58.h to s-sun55.h (on watsol) I get: dates.c: In function `rfctime': dates.c:215: called object is not a function make[1]: *** [dates.o] Error 1 OK, let's try s-bsd43.h... Nope, that dies horribly. So does s-sun40.h. Anyway, from what you're saying, maybe MM doesn't have a problem after all? But there's still a difference in the HEADERS display -- 0.90 says the above is 17 Sep, 0.91 says it's 16 Sep. Which one is right? - Frank From melissa@columbia.edu Wed Sep 18 07:45:38 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8IGjb3K022239; Wed, 18 Sep 2002 12:45:37 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8IGjbKc015220; Wed, 18 Sep 2002 12:45:37 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8IGjbdu015219; Wed, 18 Sep 2002 12:45:37 -0400 (EDT) Date: Wed, 18 Sep 2002 12:45:37 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz , bug-mm@columbia.edu Subject: Re: New MM In-Reply-To: Your message of Wed, 18 Sep 2002 12:02:01 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 83 > This is quite strange. I sent the message last night. Why would the > From line indicate the morning of the previous day? (Who adds the From > line? Sendmail?) Plus it's funny that the message is In-Reply-To a message > from Ishikawa from a day in the future; but of course that's because Japan is > across the International Date Line... This is the creeping-DST bug. MM misinterprets the DST status of the message, so each time it writes out the file, you quit and restart MM, then read the file again, the time creeps +/- 1 hour. Maybe a difference in the DST or time() library or timezone setting or something? > From fdc@columbia.edu Mon Sep 16 09:17:28 2002 > Received: ... Tue, 17 Sep 2002 20:17:27 -0400 (EDT) > Date: Tue, 17 Sep 2002 20:17:27 EDT If you are restarting MM a lot (e.g. debugging), the message creeps 1 hour each time, and after 31 iterations 9/17 16:00 (GMT) becomes 9/16 09:00. > 1-Jun-2002 20:05:19-GMT,880;000000000001 > Date: Sat, 1 Jun 2002 21:05:13 -0400 This excerpt from my mail file sems to indicate 17:00 (21:00 -0400) -> 20:00 = 3 hours of creeping for me since June 1, or 3 times I ran a creeping version of MM. That probably rules out my current version. S>version Columbia MM, version 0.90.4(69) Copyright (c) 1986, 1990 The Trustees of Columbia University in the City of New York Compiled by fdc@watsol on 21 Jul 2002 5:10pm Report bugs to bug-mm > Anyway, from what you're saying, maybe MM doesn't have a problem after all? It's MM. You can determine which version by copying a file, reading it in, writing it out again, and running diff to see if the time changed. You could "normalize" the envelope times by moving all the messages into a no-envelope format like RMAIL, then reading it back in with MM (which will initialize using the Date: header) and writing it back out in your desired format. --Melissa From fdc@columbia.edu Wed Sep 18 07:53:57 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8IGrt0H003733; Wed, 18 Sep 2002 12:53:55 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8IGrtJI003732; Wed, 18 Sep 2002 12:53:55 -0400 (EDT) Date: Wed, 18 Sep 2002 12:53:55 EDT From: Frank da Cruz To: Melissa Metz Cc: bug-mm@columbia.edu Subject: Re: New MM In-Reply-To: Your message of Wed, 18 Sep 2002 12:45:37 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 84 OK good. Then what you're saying is that it's not a bug I introduced; it's always been there, and I'm seeing now only because I'm starting and stopping MM a lot. I don't know if I can spare the time to look at actually fixing the creeping effect but if it's always been there, then I'd say that 0.91 is an improvement -- doesn't make anything worse, makes some things better, and adds a couple new features that I've tested thoroughly. I'll add your description of the creeping bug to the release notes; maybe somebody on the TOPS-20 list will take an interest. What's the next step in making 0.91 official? - Frank From melissa@columbia.edu Wed Sep 18 13:17:47 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by apakabar.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8IMHkIJ010129; Wed, 18 Sep 2002 18:17:46 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8IMHkKc020338; Wed, 18 Sep 2002 18:17:46 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8IMHkgv020337; Wed, 18 Sep 2002 18:17:46 -0400 (EDT) Date: Wed, 18 Sep 2002 18:17:45 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz , bug-mm@columbia.edu Subject: Re: New MM In-Reply-To: Your message of Wed, 18 Sep 2002 12:53:55 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 85 It hasn't always been there. We've fixed it many times. But DST is pretty slippery. > I'd say that 0.91 is an improvement -- doesn't make anything worse, > makes some things better, and adds a couple new features that I've > tested thoroughly. Sounds true anyhow. > What's the next step in making 0.91 official? We used to announce to the MM mailing list, but that is hopelessly stale. I guess just put it up for ftp. --Melissa From fdc@columbia.edu Wed Sep 18 13:39:55 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8IMdm0H029905; Wed, 18 Sep 2002 18:39:48 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8IMdljo029904; Wed, 18 Sep 2002 18:39:47 -0400 (EDT) Date: Wed, 18 Sep 2002 18:39:47 EDT From: Frank da Cruz To: Melissa Metz Cc: bug-mm@columbia.edu Subject: Re: New MM In-Reply-To: Your message of Wed, 18 Sep 2002 18:17:45 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 86 > > What's the next step in making 0.91 official? > > We used to announce to the MM mailing list, but that is hopelessly > stale. I guess just put it up for ftp. > I'll be glad to do that, but what about AcIS, Cunix, etc? It's just a fresh set of new source and help files -- no CVS, RCS, or anything. In any case, I'd like to get it installed on Watsol, the Cunixes, etc (I can take care of Watsun). While we ponder that, some of you might want to give it a whirl and make sure it's OK. To recapitulate: . It should hardly ever truncate your messages upon return from EMACS . If it does, the .mm-outgoing- file is still there . You can send and reply to 8-bit mail and specify the encoding . You can download messages to your desktop computer Here's the (short) doc: ftp://kermit.columbia.edu/kermit/mm/release-0.91.txt By the way, the downloading feature can be used as follows (if you are viewing MM from Kermit 95's terminal window). Suppose you get a message full of enclosures and you want to see them (and you trust that doing so will not give you a virus, which is a separate question we can talk about some other time :-) Tell MM to: download /filename:xxx.eml Then Alt-x back to the K-95> prompt and type: run start xxx.eml Poof, pictures, music, Word documents, Excel spreadsheets, all before your very eyes. (Looking at the message in advance with MM lets you prescreen it for safety before unleashing Windows on it. Not for novices! But then neither is MM...) I'll probably make a few minor adjustments, even if I don't get any more feedback from anybody here or on the TOPS-20 list, but I should be totally done with it before the end of the week. - Frank From fdc@columbia.edu Fri Sep 20 05:02:54 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8KE2r0H001447 for ; Fri, 20 Sep 2002 10:02:53 -0400 (EDT) Received: by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8KE2rGM001446 for fdc; Fri, 20 Sep 2002 10:02:53 -0400 (EDT) Path: newsmaster.cc.columbia.edu!newsfeed.nyu.edu!News.Math.NCTU.edu.tw!news.CDPA.nsysu.edu.tw!ctu-peer!spring.edu.tw!news.nctu.edu.tw!newsfeed.media.kyoto-u.ac.jp!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-06!sn-xit-08!supernews.com!postnews1.google.com!not-for-mail From: hsnewman@blkbox.com (HarrisNewman) Newsgroups: alt.sys.pdp10 Subject: Re: New MM Take 2 Date: 19 Sep 2002 13:00:39 -0700 Organization: http://groups.google.com/ Lines: 45 Message-ID: References: NNTP-Posting-Host: 162.89.0.62 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1032465640 351 127.0.0.1 (19 Sep 2002 20:00:40 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 19 Sep 2002 20:00:40 GMT Xref: newsmaster.cc.columbia.edu alt.sys.pdp10:23137 Content-Type: text/plain; charset=ISO-8859-1 To: undisclosed-recipients:; Status: O X-Status: X-Keywords: X-UID: 87 Mark, I'm getting errors on Solaris 2.8 Intel: bash-2.03$ make solaris make CC=gcc \ OS="-DMM_OS_SOLARIS" DEBUG="-DFDC_EDITFIX -DANSIC=1" \ OSLIBS="-ltermcap -L/usr/local/lib -lspoolmail -lsocket -lnsl" \ all ./prepatch `./argsort patch.*` touch patches /bin/rm -f mkversion gcc -DFDC_EDITFIX -DANSIC=1 -I../ccmd -DMM_OS_SOLARIS -o mkversion mkversion.c w hoami.o compat.o dates.o \ ../ccmd/ccmd.a -ltermcap -L/usr/local/lib -lspoolmail -lsocket -lnsl ld: fatal: library -lspoolmail: not found ld: fatal: File processing errors. No output written to mkversion collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `mkversion' Current working directory /home/hsnewman/work/mm *** Error code 1 make: Fatal error: Command failed for target `solaris' bash-2.03$ -HN fdc@columbia.edu (Frank da Cruz) wrote in message news:... > OK, now it builds in Linux. Plus I also added a DOWNLOAD command > (and SET/SHOW DOWNLOAD-FILTER) that works just like PRINT, but it > downloads messages rather than prints them. > > I also cleaned stuff up and added a release-0.91.txt file that > documents the new features. There's a new README.TXT at the > top that tells what/where everything is, and the edit histories are > separated into notes-xxx.txt files (xxx = klh, fdc). The mm/INSTALL > file is updated. Help text is included for the new commands. > Today's version is here: > > ftp://kermit.columbia.edu/kermit/mm/mm-ccmd-fdc.tar.gz > > Thanks to everybody who replied about the Linux difficulties -- it > helped a lot. Now if anybody wants to try building on AIX, HP-UX, > Tru64, {Free,Net,Open}BSD, I'm sure some fixes will be needed; if > so please send them in! > > - Frank From fdc@columbia.edu Fri Sep 20 05:03:16 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8KE370H001498 for ; Fri, 20 Sep 2002 10:03:08 -0400 (EDT) Received: by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8KE373Q001492 for fdc; Fri, 20 Sep 2002 10:03:07 -0400 (EDT) Path: newsmaster.cc.columbia.edu!panix!news.stealth.net!news.stealth.net!newsfeed.news2me.com!news-west.rr.com!cyclone.austin.rr.com!twister.austin.rr.com.POSTED!53ab2750!not-for-mail From: "Harris S. Newman" Newsgroups: alt.sys.pdp10 References: Subject: Re: New MM Take 2 Lines: 54 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Thu, 19 Sep 2002 22:23:28 GMT NNTP-Posting-Host: 66.68.168.68 X-Complaints-To: abuse@rr.com X-Trace: twister.austin.rr.com 1032474208 66.68.168.68 (Thu, 19 Sep 2002 17:23:28 CDT) NNTP-Posting-Date: Thu, 19 Sep 2002 17:23:28 CDT Organization: Road Runner - Texas Xref: newsmaster.cc.columbia.edu alt.sys.pdp10:23139 Content-Type: text To: undisclosed-recipients:; Status: O X-Status: X-Keywords: X-UID: 88 I read the instructions, got it working, never mind. "HarrisNewman" wrote in message news:da3698f8.0209191200.aab2dd0@posting.google.com... > Mark, > I'm getting errors on Solaris 2.8 Intel: > bash-2.03$ make solaris > make CC=gcc \ > OS="-DMM_OS_SOLARIS" DEBUG="-DFDC_EDITFIX -DANSIC=1" \ > OSLIBS="-ltermcap -L/usr/local/lib -lspoolmail -lsocket -lnsl" \ > all > ./prepatch `./argsort patch.*` > touch patches > /bin/rm -f mkversion > gcc -DFDC_EDITFIX -DANSIC=1 -I../ccmd -DMM_OS_SOLARIS -o mkversion mkversion.c w > hoami.o compat.o dates.o \ > ../ccmd/ccmd.a -ltermcap -L/usr/local/lib -lspoolmail -lsocket -lnsl > ld: fatal: library -lspoolmail: not found > ld: fatal: File processing errors. No output written to mkversion > collect2: ld returned 1 exit status > *** Error code 1 > make: Fatal error: Command failed for target `mkversion' > Current working directory /home/hsnewman/work/mm > *** Error code 1 > make: Fatal error: Command failed for target `solaris' > bash-2.03$ > > -HN > > fdc@columbia.edu (Frank da Cruz) wrote in message news:... > > OK, now it builds in Linux. Plus I also added a DOWNLOAD command > > (and SET/SHOW DOWNLOAD-FILTER) that works just like PRINT, but it > > downloads messages rather than prints them. > > > > I also cleaned stuff up and added a release-0.91.txt file that > > documents the new features. There's a new README.TXT at the > > top that tells what/where everything is, and the edit histories are > > separated into notes-xxx.txt files (xxx = klh, fdc). The mm/INSTALL > > file is updated. Help text is included for the new commands. > > Today's version is here: > > > > ftp://kermit.columbia.edu/kermit/mm/mm-ccmd-fdc.tar.gz > > > > Thanks to everybody who replied about the Linux difficulties -- it > > helped a lot. Now if anybody wants to try building on AIX, HP-UX, > > Tru64, {Free,Net,Open}BSD, I'm sure some fixes will be needed; if > > so please send them in! > > > > - Frank From fdc@columbia.edu Fri Sep 20 07:58:11 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8KGvY0H025171; Fri, 20 Sep 2002 12:57:34 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8KGvYic025166; Fri, 20 Sep 2002 12:57:34 -0400 (EDT) Date: Fri, 20 Sep 2002 12:57:34 EDT From: Frank da Cruz To: Melissa Metz Cc: bug-mm@columbia.edu, unixsys@columbia.edu, kermites@columbia.edu Subject: MM 0.91 ready to go Message-ID: Status: O X-Status: X-Keywords: X-UID: 89 For those who didn't see the previous messages on this subject, here's a brief synopsis of what's new: ftp://kermit.columbia.edu/kermit/mm/release-0.91.txt The new release is in: ftp://kermit.columbia.edu/kermit/mm/ This directory should be a plug-in replacement for: ftp://kermit.columbia.edu/mm/ It's the new MM sources and makefiles, plus updated README.TXT and a small collection of binaries: ftp://kermit.columbia.edu/kermit/mm/binaries/ I propose renaming the old MM FTP directory to something else and moving the new one to ftp://kermit.columbia.edu/mm/, OK? Also I'd suggest installing the new MM watsol, the Cunixes, and Newcunix. I already installed it on watsun (leaving the previous one behind as /usr/local/bin/mm-0.91-patched. Detailed edit history is in the following two files: ftp://kermit.columbia.edu/kermit/mm/notes-klh.txt ftp://kermit.columbia.edu/kermit/mm/notes-fdc.txt - Frank From melissa@columbia.edu Fri Sep 20 10:15:48 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8KJFlOw003519; Fri, 20 Sep 2002 15:15:47 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8KJFlKc025911; Fri, 20 Sep 2002 15:15:47 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8KJFlCL025910; Fri, 20 Sep 2002 15:15:47 -0400 (EDT) Date: Fri, 20 Sep 2002 15:15:47 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: staffnews In-Reply-To: Your message of Fri, 20 Sep 2002 13:02:06 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 90 > will it be installed at CU? Yes it will. I haven't had a chance to respond to your earlier questions in that regard because I was handling the TC debacle etc. --Melissa From fdc@columbia.edu Fri Sep 20 12:42:13 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8KLgBYH005878 for ; Fri, 20 Sep 2002 17:42:12 -0400 (EDT) Received: by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8KLgBiM005871 for fdc; Fri, 20 Sep 2002 17:42:11 -0400 (EDT) Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail From: fdc@columbia.edu (Frank da Cruz) Newsgroups: alt.sys.pdp10 Subject: Columbia MM 0.91 Release Candidate Date: 20 Sep 2002 17:39:35 -0400 Organization: Columbia University Lines: 17 Message-ID: NNTP-Posting-Host: watsol.cc.columbia.edu X-Trace: newsmaster.cc.columbia.edu 1032557977 8402 128.59.39.139 (20 Sep 2002 21:39:37 GMT) X-Complaints-To: postmaster@columbia.edu NNTP-Posting-Date: 20 Sep 2002 21:39:37 GMT Xref: newsmaster.cc.columbia.edu alt.sys.pdp10:23145 Content-Type: text To: undisclosed-recipients:; Status: O X-Status: X-Keywords: X-UID: 91 In case anybody wants to check it out before I replace the 0.90 version on the Columbia FTP site: ftp://kermit.columbia.edu/kermit/mm/ The important files are: ftp://kermit.columbia.edu/kermit/mm/README.TXT ftp://kermit.columbia.edu/kermit/mm/release-0.91.txt ftp://kermit.columbia.edu/kermit/mm/mm-ccmd-0.91.tar.gz I've built it for various Solaris versions (2.5.1 - 9, Sparc and Intel), Linux, and FreeBSD. Some of the other builds failed miserably: OpenBSD and HP-UX. The rest are untested. - Frank From melissa@columbia.edu Tue Sep 24 11:21:24 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8OKLMuC008099; Tue, 24 Sep 2002 16:21:23 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8OKLMKc016529; Tue, 24 Sep 2002 16:21:23 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8OKLMEJ016528; Tue, 24 Sep 2002 16:21:22 -0400 (EDT) Date: Tue, 24 Sep 2002 16:21:22 EDT From: Melissa Metz To: fdc@columbia.edu Cc: melissa@columbia.edu Subject: debug messages Message-ID: Status: O X-Status: X-Keywords: X-UID: 92 I aborted a message I had started to compose, without typing any text, and saw the following (after a substantial pause): chk_edit /p/sy/melissa/tmp/.mm-outgoing.9668... Possible problem with edit [gnuemacs_edit_outgoing:chk_edit]. Temp file kept: /p/sy/melissa/tmp/.mm-outgoing.9668. read_from_temp: /p/sy/melissa/tmp/.mm-outgoing.9668: 0 0 (EMPTY) Text length mismatch [gnuemacs_edit_outgoing]: 0 != 0. Temp file kept: /p/sy/melissa/tmp/.mm-outgoing.9668. read_from_temp: /p/sy/melissa/tmp/.mm-headers.9668: 248 248 (OK) I guess the pause was MM trying again to read something from the file. However, in my experience it is not true that "0 != 0" (as stated above), so it should have been more accepting of the empty file. Not a big deal. --Melissa From fdc@columbia.edu Tue Sep 24 11:28:40 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8OKSagL026082; Tue, 24 Sep 2002 16:28:37 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8OKSasI026081; Tue, 24 Sep 2002 16:28:36 -0400 (EDT) Date: Tue, 24 Sep 2002 16:28:36 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: debug messages In-Reply-To: Your message of Tue, 24 Sep 2002 16:21:22 EDT Cc: bug-mm@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 93 > I aborted a message I had started to compose, without typing any > text, and saw the following (after a substantial pause): > > chk_edit /p/sy/melissa/tmp/.mm-outgoing.9668... > Possible problem with edit [gnuemacs_edit_outgoing:chk_edit]. > Temp file kept: /p/sy/melissa/tmp/.mm-outgoing.9668. > read_from_temp: /p/sy/melissa/tmp/.mm-outgoing.9668: 0 0 (EMPTY) > Text length mismatch [gnuemacs_edit_outgoing]: 0 != 0. > Temp file kept: /p/sy/melissa/tmp/.mm-outgoing.9668. > read_from_temp: /p/sy/melissa/tmp/.mm-headers.9668: 248 248 (OK) > > I guess the pause was MM trying again to read something from the file. > However, in my experience it is not true that "0 != 0" (as stated > above), so it should have been more accepting of the empty file. > You're not using 0.91! 0.91 doesn't print all the stupid messages and it doesn't say "0 != 0" :-) However, it does pause for 3 seconds when you exit from the editor after creating an empty file because it has no way of knowing whether the file empty because you saved it that way, or because it hasn't settled down yet. Also, something has started to dawn on me about the truncated messages. On Sept 14th, when I discovered that setting use-editor-always lets me have 8-bit text, I added this to my .mminit. Since then I have not lost a single message, even though I enter EMACS from MM hundreds of times a day, save the message, and exit back to MM. This would seem to point the finger at parse() (because use-editor-always totally bypasses parse() for message text collection)... Maybe some day when I'm bored I'll put use-editor-always back to false and see if I start losing messages again. - Frank From fdc@columbia.edu Tue Sep 24 11:43:34 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8OKhWgL029025; Tue, 24 Sep 2002 16:43:32 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8OKhWvY029022; Tue, 24 Sep 2002 16:43:32 -0400 (EDT) Date: Tue, 24 Sep 2002 16:43:31 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: debug messages In-Reply-To: Your message of Tue, 24 Sep 2002 16:40:23 EDT Cc: bug-mm@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 94 > > 0.91 doesn't print all the stupid messages and it doesn't say "0 != 0" > > I like the stupid messages because when I lose a message I have the > filename right on my screen for easy cut-n-paste. > You still get the filename message, just not all the other verbose progress messages. And of course you get error messages if there actually is an error. > > use-editor-always totally bypasses parse() > > Hmm, I'm not ready to commit to emacs for all messages. Too slow. > It's not that bad, I'm getting used to it. But if you're not using this and still losing messages (with 0.91) and I am using it and never losing messages, that's a good hint. - Frank P.S. I just built MM on OpenBSD (which failed previously) -- turns out that OpenBSD and NetBSD cc do not define "unix", which ccmd depends on. From fdc@columbia.edu Tue Sep 24 11:52:27 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8OKqKgL029949; Tue, 24 Sep 2002 16:52:20 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8OKqKgc029948; Tue, 24 Sep 2002 16:52:20 -0400 (EDT) Date: Tue, 24 Sep 2002 16:52:20 EDT From: Frank da Cruz To: Melissa Metz Cc: bug-mm@columbia.edu Subject: Re: debug messages In-Reply-To: Your message of Tue, 24 Sep 2002 16:46:48 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 95 > Okay, where do I find 0.91? > Solaris 2.5.1 Binary: ~fdc/bin.solaris/mm Other binaries: ~kermit/mm/binaries/mm-0.91-* Doc: ~kermit/mm/release-0.91.txt Source: ~kermit/mm/mm-ccmd-0.91.tar.gz Edit histories: ~kermit/mm/notes-klh.txt ~kermit/mm/notes-fdc.txt This is the version I'd like to see replace the current one at CU and on the FTP site. - Frank From fdc@columbia.edu Tue Sep 24 12:15:07 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8OLF7gL001991 for ; Tue, 24 Sep 2002 17:15:07 -0400 (EDT) Received: by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8OLF6Ho001990 for fdc; Tue, 24 Sep 2002 17:15:06 -0400 (EDT) Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail From: fdc@columbia.edu (Frank da Cruz) Newsgroups: alt.sys.pdp10 Subject: Re: New MM Take 2 Date: 24 Sep 2002 17:14:44 -0400 Organization: Columbia University Lines: 35 Message-ID: References: NNTP-Posting-Host: watsol.cc.columbia.edu X-Trace: newsmaster.cc.columbia.edu 1032902085 24802 128.59.39.139 (24 Sep 2002 21:14:45 GMT) X-Complaints-To: postmaster@columbia.edu NNTP-Posting-Date: 24 Sep 2002 21:14:45 GMT Xref: newsmaster.cc.columbia.edu alt.sys.pdp10:23161 Content-Type: text To: undisclosed-recipients:; Status: O X-Status: X-Keywords: X-UID: 96 In article , Baby Peanut wrote: : fdc@columbia.edu (Frank da Cruz) wrote in message : news:... : > OK, now it builds in Linux. Plus I also added a DOWNLOAD command : > (and SET/SHOW DOWNLOAD-FILTER) that works just like PRINT, but it : > downloads messages rather than prints them. : > : > I also cleaned stuff up and added a release-0.91.txt file that : > documents the new features. There's a new README.TXT at the : > top that tells what/where everything is, and the edit histories are : > separated into notes-xxx.txt files (xxx = klh, fdc). The mm/INSTALL : > file is updated. Help text is included for the new commands. : > : > Thanks to everybody who replied about the Linux difficulties -- it : > helped a lot. Now if anybody wants to try building on AIX, HP-UX, : > Tru64, {Free,Net,Open}BSD, I'm sure some fixes will be needed; if : > so please send them in! : : {Net,Open}BSD do not "#define unix" not even implicitly in the cpp. : Aha. OK now it builds OK on NetBSD and OpenBSD, thanks. I put up a new tarball here: ftp://kermit.columbia.edu/kermit/mm/mm-ccmd-0.91.tar.gz and added NetBSD and OpenBSD binaries to: ftp://kermit.columbia.edu/kermit/mm/binaries/ (FreeBSD was already working). Docs, etc, updated too: ftp://kermit.columbia.edu/kermit/mm/README.TXT - Frank From melissa@columbia.edu Mon Sep 30 06:41:54 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8UFfrL1024498; Mon, 30 Sep 2002 11:41:53 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8UFfrKc003639; Mon, 30 Sep 2002 11:41:53 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8UFfrSH003638; Mon, 30 Sep 2002 11:41:53 -0400 (EDT) Date: Mon, 30 Sep 2002 11:41:53 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: staffnews In-Reply-To: Your message of Fri, 20 Sep 2002 13:02:06 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 97 > I'll send something about MM as soon as I know what to say -- will it > be installed at CU? Yes, it will. --Melissa From melissa@columbia.edu Mon Sep 30 11:27:15 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8UKRAsB017543; Mon, 30 Sep 2002 16:27:10 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8UKRAKc008402; Mon, 30 Sep 2002 16:27:10 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8UKRAg8008401; Mon, 30 Sep 2002 16:27:10 -0400 (EDT) Date: Mon, 30 Sep 2002 16:27:09 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz , bug-mm@columbia.edu, unixsys@columbia.edu, kermites@columbia.edu Subject: Re: MM 0.91 ready to go In-Reply-To: Your message of Fri, 20 Sep 2002 12:57:34 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 98 > I propose renaming the old MM FTP directory to something else and > moving the new one to ftp://kermit.columbia.edu/mm/, OK? Okay. > Also I'd suggest installing the new MM watsol, the Cunixes, and > Newcunix. I already installed it on watsun (leaving the previous > one behind as /usr/local/bin/mm-0.91-patched. This would be fine. The binary should probably go in /opt/ACISmm/bin/mm, with the old copy in mm.old. We would remove the copies in /opt/ACISmisc/bin/mm*. If you get it into /opt/ACISmm/bin on watsol I can get it distributed to cunix and newcunix. I guess I could even announce it to acsc-ft, in case we have any users. --Melissa From melissa@columbia.edu Mon Sep 30 11:38:23 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8UKcJsB024209; Mon, 30 Sep 2002 16:38:19 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8UKcJKc008622; Mon, 30 Sep 2002 16:38:19 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8UKcJIP008621; Mon, 30 Sep 2002 16:38:19 -0400 (EDT) Date: Mon, 30 Sep 2002 16:38:19 EDT From: Melissa Metz To: Alan Crosswell Cc: Melissa Metz , Frank da Cruz , Melissa Metz , bug-mm@columbia.edu, unixsys@columbia.edu, kermites@columbia.edu Subject: Re: MM 0.91 ready to go In-Reply-To: Your message of Mon, 30 Sep 2002 16:29:44 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 99 > Every 10 years we need a new MM release:-) We had a Y2K release and a Y2K+1 release. That's twice already in this millenium. --Melissa From fdc@columbia.edu Mon Sep 30 11:39:53 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8UKdZNf015795; Mon, 30 Sep 2002 16:39:35 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8UKdZJA015794; Mon, 30 Sep 2002 16:39:35 -0400 (EDT) Date: Mon, 30 Sep 2002 16:39:34 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM 0.91 ready to go In-Reply-To: Your message of Mon, 30 Sep 2002 16:27:09 EDT Cc: bug-mm@columbia.edu, unixsys@columbia.edu, kermites@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 100 > > I propose renaming the old MM FTP directory to something else and > > moving the new one to ftp://kermit.columbia.edu/mm/, OK? > > Okay. > Done. The old MM directory is now ~ftp/mm-0.91/. > > Also I'd suggest installing the new MM watsol, the Cunixes, and > > Newcunix. I already installed it on watsun (leaving the previous > > one behind as /usr/local/bin/mm-0.91-patched. > > This would be fine. The binary should probably go in > /opt/ACISmm/bin/mm, with the old copy in mm.old. We would remove the > copies in /opt/ACISmisc/bin/mm*. If you get it... > You mean me? (If you want me to do it, I'll be glad to.) I have separate binaries for the different Solaris versions, or do you just want to put the Solaris 2.5.1 binary everywhere? > ... into /opt/ACISmm/bin > on watsol I can get it distributed to cunix and newcunix. I guess I > could even announce it to acsc-ft, in case we have any users. > Thanks! - Frank From melissa@columbia.edu Tue Oct 1 05:57:09 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g91Euum2029369; Tue, 1 Oct 2002 10:56:56 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g91EuuKc025345; Tue, 1 Oct 2002 10:56:56 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g91EuuEN025344; Tue, 1 Oct 2002 10:56:56 -0400 (EDT) Date: Tue, 1 Oct 2002 10:56:56 EDT From: Melissa Metz To: Joseph Brennan Cc: Alan Crosswell , Melissa Metz , Frank da Cruz , bug-mm@columbia.edu, unixsys@columbia.edu, kermites@columbia.edu Subject: Re: MM 0.91 ready to go In-Reply-To: Your message of Tue, 01 Oct 2002 08:10:04 -0400 Message-ID: Status: O X-Status: X-Keywords: X-UID: 101 > Following the name scheme of 0.90, this new one should be 0.102. I believe we just numbered them sequentially. I think. I remember it was a challenge to get 0.90 out in December of 1990 so it would match... --Melissa From melissa@columbia.edu Tue Oct 1 06:06:32 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g91F6WsB021721; Tue, 1 Oct 2002 11:06:32 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g91F6VKc025516; Tue, 1 Oct 2002 11:06:31 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g91F6VlR025515; Tue, 1 Oct 2002 11:06:31 -0400 (EDT) Date: Tue, 1 Oct 2002 11:06:31 EDT From: Melissa Metz To: Frank da Cruz Subject: Re: MM 0.91 ready to go In-Reply-To: Your message of Mon, 30 Sep 2002 16:39:34 EDT Cc: melissa@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 102 > > The binary should probably go in /opt/ACISmm/bin/mm, with the old > > copy in mm.old. > I have separate binaries for the different Solaris versions, or do you > just want to put the Solaris 2.5.1 binary everywhere? If you remind me one more time :-) where the real definitive binary is for 2.5.1 I will put that everywhere (because I am not sure how to do it otherwise). (Not sure if there is a separate Columbia build vs the one in the ftp tree.) If it works for me (broccoli is Sol 2.8) it should be fine for everyone else. Fuat was very excited to hear that a Linux binary was available. He is all set to install it at work so he doesn't have to use pine all the time. --Melissa From fdc@columbia.edu Tue Oct 1 06:13:07 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g91FD0Nf023262; Tue, 1 Oct 2002 11:13:00 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g91FCwUI023261; Tue, 1 Oct 2002 11:12:58 -0400 (EDT) Date: Tue, 1 Oct 2002 11:12:58 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM 0.91 ready to go In-Reply-To: Your message of Tue, 1 Oct 2002 11:06:31 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 103 > > I have separate binaries for the different Solaris versions, or do you > > just want to put the Solaris 2.5.1 binary everywhere? > > If you remind me one more time :-) where the real definitive binary is > for 2.5.1... /pub/ftp/mm/binaries: -rwxr-xr-x 1 fdc 595950 Sep 20 10:56 mm-0.91-i386-freebsd-4.4 -rwxr-xr-x 1 fdc 603338 Sep 20 10:26 mm-0.91-i386-linux-rh7.1 -rwxr-xr-x 1 fdc 563401 Sep 24 17:05 mm-0.91-i386-netbsd-1.5.2 -rwxr-xr-x 1 fdc 831258 Sep 24 16:37 mm-0.91-i386-openbsd-3.0 -rwxr-xr-x 1 fdc 1084452 Sep 20 11:13 mm-0.91-i386-solaris-8 -rwxr-xr-x 1 fdc 968072 Sep 20 10:16 mm-0.91-sparc-solaris-2.5.1 -rwxr-xr-x 1 fdc 1189236 Sep 20 10:24 mm-0.91-sparc-solaris-9 -rwxr-xr-x 1 fdc 909312 Sep 20 10:40 mm-0.91-sparc-sunos-4.1.3 > I will put that everywhere (because I am not sure how to do > it otherwise). (Not sure if there is a separate Columbia build vs the > one in the ftp tree.) If it works for me (broccoli is Sol 2.8) it > should be fine for everyone else. > I've been using mm-0.91-sparc-solaris-2.5.1 on watsol all this time, but give it a spin on Solaris 8 and 9 before unleashing it. > Fuat was very excited to hear that a Linux binary was available. He > is all set to install it at work so he doesn't have to use pine all > the time. > I still didn't figure out the movemail part. When I ran it on the FTP machine, it found all sorts of strange mail that had been waiting for me locally. The deal is, on each platform we're supposed to install EMACS movemail in /usr/local/mm/bin/? - Frank From melissa@columbia.edu Tue Oct 1 07:20:26 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g91GKPsB019575; Tue, 1 Oct 2002 12:20:25 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g91GKPKc026631; Tue, 1 Oct 2002 12:20:25 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g91GKPoR026630; Tue, 1 Oct 2002 12:20:25 -0400 (EDT) Date: Tue, 1 Oct 2002 12:20:25 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: MM 0.91 ready to go In-Reply-To: Your message of Tue, 1 Oct 2002 11:12:58 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 104 > I've been using mm-0.91-sparc-solaris-2.5.1 on watsol all this time, but > give it a spin on Solaris 8 and 9 before unleashing it. I'm going to have to say there are very few MM users on Sol 8 or 9. It may be just me. Since we consider the 2.5.1 version "tested" I will go ahead and install that on cunix and watsol (2.5.1 hosts) and it will probably end up on the 2.8 hosts as well. > I still didn't figure out the movemail part. When I ran it on the FTP > machine, it found all sorts of strange mail that had been waiting for me > locally. The deal is, on each platform we're supposed to install EMACS > movemail in /usr/local/mm/bin/? Yes, we just swipe movemail from emacs. MM has a movemail-path setting, so it could really be put anywhere. But emacs is generally installed in a version-number directory, so putting it in /usr/local/mm/bin helps keep it from getting lost between emacs versions. > I still didn't figure out the movemail part. When I ran it on the FTP > machine, it found all sorts of strange mail that had been waiting for me > locally. The deal is, on each platform we're supposed to install EMACS > movemail in /usr/local/mm/bin/? movemail's job is to move the mail from the spool directory to the user's home directory. I have used it in simple file mode, where it opens the file, copies the mail and nulls out the original, and as a POP client, where it can get mail from a remote site. For the latter behavior, you have to indicate it should use POP by setting the spool-file variable to have a hostname in it or something. (Fuat says he can't get emacs movemail working for him anyway, because of the firewalling and secure POP at his work. But he is happy to have MM for examining archived mail.) --Melissa From melissa@columbia.edu Tue Oct 1 07:49:28 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g91GnBNk004601; Tue, 1 Oct 2002 12:49:11 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g91GnBKc027122; Tue, 1 Oct 2002 12:49:11 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g91GnBEr027121; Tue, 1 Oct 2002 12:49:11 -0400 (EDT) Date: Tue, 1 Oct 2002 12:49:11 EDT From: Melissa Metz To: acsc-ft@columbia.edu Cc: unixsys@columbia.edu, fdc@columbia.edu Subject: new MM up Message-ID: Status: O X-Status: X-Keywords: X-UID: 105 Frank has generated a new version of MM, which I just installed on cunix, watsol, and various other hosts. Changes are described in: ftp://ftp.columbia.edu/mm/release-0.91.txt and shortly in staffnews. To summarize: attempts to fix the truncated-message problem, 8-bit compatibility, and a new DOWNLOAD command. Users, such as they are, should not see any new problems. But if there are any we can back out to /opt/ACISmm/bin/mm.old. (I also moved MM from /opt/ACISmisc to /opt/ACISmm.) --Melissa From fdc@columbia.edu Wed Oct 2 06:04:24 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g92F4NTr012305; Wed, 2 Oct 2002 11:04:23 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g92F4MtE012304; Wed, 2 Oct 2002 11:04:22 -0400 (EDT) Date: Wed, 2 Oct 2002 11:04:22 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: new MM up In-Reply-To: Your message of Wed, 2 Oct 2002 10:58:36 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 106 > It was brought to my attention yesterday evening (around 7-8pm) that the > new MM was only executable by staff. I fixed it at that time. > See, regular people use it after all :-) From fdc@columbia.edu Wed Oct 2 06:59:01 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g92FwwTr020393; Wed, 2 Oct 2002 11:58:58 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g92FwwPY020392; Wed, 2 Oct 2002 11:58:58 -0400 (EDT) Date: Wed, 2 Oct 2002 11:58:58 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: new MM up In-Reply-To: Your message of Wed, 2 Oct 2002 11:51:32 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 107 > P.S. You forgot to decrement the patch number in the version number: > Columbia MM, version 0.91.0(134) > > 134 -> 1, or maybe 0. > Oops, I thought that was the edit number (like in a DEC-20 version number). OK, next time. I'm in another real-life crunch now, but if I get back to MM another thing I want to do is make "forward" load the forwarded message into the editor so you don't have to edit twice. - Frank From melissa@columbia.edu Wed Oct 2 09:12:43 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g92IChpw016048; Wed, 2 Oct 2002 14:12:43 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g92ICgKc014026; Wed, 2 Oct 2002 14:12:42 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g92ICgQb014025; Wed, 2 Oct 2002 14:12:42 -0400 (EDT) Date: Wed, 2 Oct 2002 14:12:42 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: new MM up In-Reply-To: Your message of Wed, 2 Oct 2002 11:58:58 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 108 > make "forward" load the forwarded message > into the editor so you don't have to edit twice. The reason we don't load it is: if you don't go into the editor, and just type into the text box, you want your text above the forwarded message, not below it. Similarly, if you start typing as soon as you get into emacs your text would go at the bottom. --Melissa From lindaw@columbia.edu Wed Oct 2 13:17:44 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g92MHeTr007198; Wed, 2 Oct 2002 18:17:40 -0400 (EDT) Received: (from lindaw@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g92MHd1A007187; Wed, 2 Oct 2002 18:17:39 -0400 (EDT) Date: Wed, 2 Oct 2002 18:17:39 EDT From: Linda Wallinger To: Frank da Cruz Cc: Lynn Rohrs , bug-mm@columbia.edu Subject: Re: mm In-Reply-To: Your message of Wed, 2 Oct 2002 17:57:03 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 109 > > thanks for fixing the infamous mm bug. it drove me crazy! i noticed > > earlier today that it saves the draft now all the time and just read > > in staffnews that you fixed it. i haven't needed the backup of the > > draft yet, and if your impression holds true that it hardly ever > > breaks now, i won't very often but this is a huge thing. > > > Hurray, another MM fan. Well the truncations might still happen but > if they do, not only can you get the temp file back, but you can switch > to "set use-editor-always" and then it never happens -- at least not to > me since I started doing that about 3 weeks ago. > > - Frank > Yes, thanks, Frank! I just had occasion to use a saved temp file today. /Linda From fdc@columbia.edu Thu Oct 3 04:47:47 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g93DljTr026492; Thu, 3 Oct 2002 09:47:45 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g93Dljik026491; Thu, 3 Oct 2002 09:47:45 -0400 (EDT) Date: Thu, 3 Oct 2002 9:47:45 EDT From: Frank da Cruz To: Linda Wallinger Cc: bug-mm@columbia.edu, melissa@columbia.edu Subject: Re: new MM In-Reply-To: Your message of Wed, 2 Oct 2002 18:48:18 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 110 > I have to say I did not pay the closest attention to conversations on the > new MM, but I see that it removes the Content-Type of the original > message when a message is remailed. For example, I remailed myself a > message that came in with Content-Type: text/html, and it was removed > in the remailed version. Was that intentional? > Yes, I hate HTML mail. (No, just kidding!) > Since I often remail > html-encoded messages to my test account for reading with a GUI email > app, this is unfortunate (for me). > Nothing like a real release to shake the bugs out! I added a command to let the user specify a character set in the Content-type header. Evidently this affects the headers in the remailed message, don't ask me how. But I'll look into it. Thanks for the report. Meanwhile, depending on what you have on your desktop that you're accessing MM with, you might be able to use Plan B to read GUI mail: download /filename:xxx.eml - Frank From brennan@columbia.edu Fri Oct 4 05:13:57 2002 Flags: 000000000011 Return-Path: Received: from dynamic-31-218.dyn.columbia.edu (dynamic-31-218.dyn.columbia.edu [128.59.31.218]) (user=brennan mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g94EDvTS002220 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 4 Oct 2002 10:13:57 -0400 (EDT) Date: Fri, 04 Oct 2002 10:14:01 -0400 From: Joseph Brennan To: melissa@columbia.edu, fdc@columbia.edu Subject: Case 145124 (Low) assigned to AcIS Postmaster (fwd) Message-ID: <72531645.1033726441@dynamic-31-218.dyn.columbia.edu> X-Mailer: Mulberry/2.1.0 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Status: O X-Status: X-Keywords: X-UID: 111 Date: Fri, 4 Oct 2002 7:38:42 EDT From: David Magier To: consultant@columbia.edu Subject: email/editing weirdness When using mm to send mail, I often hit ^E to launch the editor (emacs) to edit the document. Then when I close the editor, I come back to the mm prompt and send the letter. But suddently, for the last two days, at the point of closing the editor, I get the message: "Temp file kept: /u/4/m/magier/.mm-outgoing.19375" etc. I've confirmed that MM *is* sending the message, but I can't understand why the editor (or is it MM?) is starting to fill my directory with loads of temp files. Of course I can "clean" them away, but I'd like to understand what's happening. Please advise. thanks. Is it intended that users have to keep clearing away the .mm-outgoing* files as written above? That'll get old fast. Joe From fdc@columbia.edu Fri Oct 4 05:19:41 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g94EJdTr027771; Fri, 4 Oct 2002 10:19:39 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g94EJYHg027769; Fri, 4 Oct 2002 10:19:34 -0400 (EDT) Date: Fri, 4 Oct 2002 10:19:33 EDT From: Frank da Cruz To: Joseph Brennan Cc: melissa@columbia.edu, bug-mm@columbia.edu Subject: Re: Case 145124 (Low) assigned to AcIS Postmaster (fwd) In-Reply-To: Your message of Fri, 04 Oct 2002 10:14:01 -0400 Message-ID: Status: O X-Status: X-Keywords: X-UID: 112 > When using mm to send mail, I often hit ^E to launch the editor (emacs) > to edit the document. Then when I close the editor, I come back to the > mm prompt and send the letter. But suddently, for the last two days, at > the point of closing the editor, I get the message: "Temp file kept: > /u/4/m/magier/.mm-outgoing.19375" etc. I've confirmed that MM *is* > sending the message, but I can't understand why the editor (or is it > MM?) is starting to fill my directory with loads of temp files. Of > course I can "clean" them away, but I'd like to understand what's > happening. Please advise. thanks. > > Is it intended that users have to keep clearing away the .mm-outgoing* > files as written above? That'll get old fast. > Aha, real users using MM after all! You can tell them: A new mini-release of MM was installed that keeps the file you saved >From EMACS as a backup in case "something happens" before you send the message. Previously there was no way to get it back, e.g. if it was truncated on its way from EMACS back to MM due to NFS peculiarities, as happened often to some people. The temp file is deleted automatically (a) each time you start the editor again, and (b) when you exit MM. - Frank From melissa@columbia.edu Fri Oct 4 05:35:19 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g94EZIYd011560; Fri, 4 Oct 2002 10:35:18 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g94EZIKc000992; Fri, 4 Oct 2002 10:35:18 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g94EZIDG000991; Fri, 4 Oct 2002 10:35:18 -0400 (EDT) Date: Fri, 4 Oct 2002 10:35:18 EDT From: Melissa Metz To: Joseph Brennan Cc: melissa@columbia.edu, fdc@columbia.edu Subject: Re: Case 145124 (Low) assigned to AcIS Postmaster (fwd) In-Reply-To: Your message of Fri, 04 Oct 2002 10:14:01 -0400 Message-ID: Status: O X-Status: X-Keywords: X-UID: 113 > But suddently, for the last two days, ... !! Almost as if someone installed a new version (and announced it). > Is it intended that users have to keep clearing away the .mm-outgoing* > files as written above? That'll get old fast. It keeps the files as long as you are in MM, but attempts to clean them up when you exit MM. -rw------- 1 melissa sy 457 Oct 4 10:07 .mm-outgoing.477 $ jobs [1]+ 29520 Stopped (user) emacs -nw (wd: ~/admin/use-send-spam) [2]- 477 Stopped (signal) mm (wd: ~/admin/use-send-spam) $ %2 mm (wd: ~/admin/use-send-spam) You have new mail in /mail/m/e/melissa. MM>bye $ ls -lt .mm-outgoing.477 ls: .mm-outgoing.477: No such file or directory Sometimes MM leaves the file around, though. It is not a new problem, though it does happen more with the new MM (which I have been running since July-August). I run MM every day, but don't have leftover files for every day. --Melissa -rw------- 1 melissa sy 460 Sep 27 13:38 .mm-outgoing.5640 -rw------- 1 melissa sy 361 Sep 23 13:37 .mm-outgoing.17473 -rw------- 1 melissa sy 478 Sep 22 22:40 .mm-outgoing.14244 -rw------- 1 melissa sy 431 Sep 21 13:38 .mm-outgoing.15910 -rw------- 1 melissa sy 1062 Sep 16 17:45 .mm-outgoing.3864 -rw------- 1 melissa sy 85 Sep 11 17:46 .mm-outgoing.28786 -rw------- 1 melissa sy 361 Sep 3 21:22 .mm-outgoing.6764 -rw------- 1 melissa sy 947 Sep 3 17:16 .mm-outgoing.1591 -rw------- 1 melissa sy 1026 Aug 30 15:20 .mm-outgoing.6492 -rw------- 1 melissa sy 600 Aug 29 16:18 .mm-outgoing.20105 -rw------- 1 melissa sy 409 Aug 28 18:01 .mm-outgoing.3100 -rw------- 1 melissa sy 694 Aug 28 16:49 .mm-outgoing.24156 -rw------- 1 melissa sy 491 Aug 12 17:38 .mm-outgoing.7413 -rw------- 1 melissa sy 332 Aug 9 16:40 .mm-outgoing.11248 -rw------- 1 melissa sy 257 Aug 7 21:05 .mm-outgoing.9960 -rw------- 1 melissa sy 281 Jul 24 17:04 .mm-outgoing.10892 -rw------- 1 melissa sy 1 Dec 11 2001 .mm-outgoing.25932 -rw------- 1 melissa sy 1 Nov 14 2001 .mm-outgoing.29416 -rw------- 1 melissa sy 185 Sep 11 2001 .mm-outgoing.12004 -rw------- 1 melissa sy 1 Sep 11 2001 .mm-outgoing.12004~ From melissa@columbia.edu Fri Oct 4 06:10:43 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g94FAgYd018908; Fri, 4 Oct 2002 11:10:42 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g94FAgKc001553; Fri, 4 Oct 2002 11:10:42 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g94FAg3P001552; Fri, 4 Oct 2002 11:10:42 -0400 (EDT) Date: Fri, 4 Oct 2002 11:10:42 EDT From: Melissa Metz To: Frank da Cruz Cc: Joseph Brennan , Melissa Metz , bug-mm@columbia.edu Subject: Re: Case 145124 (Low) assigned to AcIS Postmaster (fwd) In-Reply-To: Your message of Fri, 4 Oct 2002 10:44:26 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 114 > I might also add a command to clean up all .mm-blah temp files, and > run it by default when MM starts, or somesuch. I run two MMs at once... > I've been getting leftover files forever; I don't think there's anything > new here. If MM exits normally, it cleans its temp files; if not, not. I have more than I used to. And I almost never exit MM "badly". Not that I'm complaining... --Melissa From fdc@columbia.edu Sat Oct 5 08:57:03 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g95Hv1Tr029625; Sat, 5 Oct 2002 13:57:01 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g95Hv0PQ029617; Sat, 5 Oct 2002 13:57:00 -0400 (EDT) Date: Sat, 5 Oct 2002 13:57:00 EDT From: Frank da Cruz To: Linda Wallinger Cc: bug-mm@columbia.edu, melissa@columbia.edu Subject: Re: new MM In-Reply-To: Your message of Wed, 2 Oct 2002 18:48:18 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 115 > I have to say I did not pay the closest attention to conversations on the > new MM, but I see that it removes the Content-Type of the original > message when a message is remailed. For example, I remailed myself a > message that came in with Content-Type: text/html, and it was removed > in the remailed version. Was that intentional? Since I often remail > html-encoded messages to my test account for reading with a GUI email > app, this is unfortunate (for me). > Fixed. New Solaris 2.5.1 Sparc binary in: ftp://ftp.columbia.edu/mm/binaries/mm-0.91-sparc-solaris-2.5.1 The ftp site is updated with the new source code: ftp://ftp.columbia.edu/mm/mm-ccmd-0.91.tar (and .tar.Z and .tar.gz) Melissa, if you want to pull a quick switch on the binary...? - Frank P.S. I don't think I'm on the bug-mm list; could you pls add me? Thanks! From beecher@columbia.edu Tue Oct 8 07:34:47 2002 Flags: 000000000001 Return-Path: Received: from neb.cc.columbia.edu (neb.cc.columbia.edu [128.59.39.15]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g98GYZlc016563; Tue, 8 Oct 2002 12:34:35 -0400 (EDT) Received: from neb.cc.columbia.edu (localhost [127.0.0.1]) by neb.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g98GYZkm008828; Tue, 8 Oct 2002 12:34:35 -0400 (EDT) Received: (from beecher@localhost) by neb.cc.columbia.edu (8.12.3/8.12.3/Submit) id g98GYZk4008827; Tue, 8 Oct 2002 12:34:35 -0400 (EDT) Date: Tue, 8 Oct 2002 12:34:35 EDT From: Ben Beecher To: postmaster@columbia.edu Office: 710 Watson (212) 854-7439 Organization: Columbia University Subject: [Frank da Cruz : Re: mail date?] Cc: unix@columbia.edu, fdc@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 116 Joe, I have several messages in my mailbox with the wrong date in the From field. Attached below is a recent example. The From field says Sep-25 but the message was sent (using MM from my Solaris workstation) on Sep-30. I hope you can find the source of the problem. If you need more examples let me know. Hilary Ben ---------------------------------------- >From beecher@columbia.edu Wed Sep 25 19:17:49 2002 Flags: 000000000001 Return-Path: Received: from neb.cc.columbia.edu (neb.cc.columbia.edu [128.59.39.15]) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8UDHeog006515 for ; Mon, 30 Sep 2002 09:17:40 -0400 (EDT) Received: from neb.cc.columbia.edu (localhost [127.0.0.1]) by neb.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g8UDHekm007500 for ; Mon, 30 Sep 2002 09:17:40 -0400 (EDT) Received: (from beecher@localhost) by neb.cc.columbia.edu (8.12.3/8.12.3/Submit) id g8UDHejY007499 for unix; Mon, 30 Sep 2002 09:17:40 -0400 (EDT) Date: Mon, 30 Sep 2002 9:17:40 EDT From: Ben Beecher To: unix@columbia.edu Office: 710 Watson (212) 854-7439 Organization: Columbia University Subject: neb out today Message-ID: --------------- Frank reported this problem a while ago, but the headers were gone. Date: Mon, 26 Aug 2002 8:54:25 EDT From: Frank da Cruz To: Joseph Brennan Subject: Re: mail date? In-Reply-To: Your message of Mon, 26 Aug 2002 08:23:28 -0400 Cc: unix@columbia.edu Message-ID: > Let me see the complete headers of these, so I can match them to syslog. > Oops, long gone, sorry. > The Date: header is often put on by the mail client the sender is using. > I've seen mail from PCs and even servers that have their clock set crazy. > The Date headers were correct; the From lines were off. The mail was sent by MM or Rmail; the Date headers showed using watsol's system time, which was correct. > The From first line is written when the mail is written to spool. > Written by sendmail? OK, just something to keep an eye open for. Thanks - Frank From fdc@columbia.edu Tue Oct 8 08:00:15 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g98GxuIj022272; Tue, 8 Oct 2002 12:59:57 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g98GxuZU022270; Tue, 8 Oct 2002 12:59:56 -0400 (EDT) Date: Tue, 8 Oct 2002 12:59:56 EDT From: Frank da Cruz To: Ben Beecher Cc: postmaster@columbia.edu, unix@columbia.edu, bug-mm@columbia.edu Subject: Re: [Frank da Cruz : Re: mail date?] In-Reply-To: Your message of Tue, 8 Oct 2002 12:34:35 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 117 > I have several messages in my mailbox with the wrong date in the From > field. Attached below is a recent example. The From field says > Sep-25 but the message was sent (using MM from my Solaris workstation) > on Sep-30. I hope you can find the source of the problem. If you > need more examples let me know. > Quoting Melissa (Sept 18th): This is the creeping-DST bug. MM misinterprets the DST status of the message, so each time it writes out the file, you quit and restart MM, then read the file again, the time creeps +/- 1 hour. Maybe a difference in the DST or time() library or timezone setting or something? If you are restarting MM a lot (e.g. debugging), the message creeps 1 hour each time, and after 31 iterations 9/17 16:00 (GMT) becomes 9/16 09:00. We've fixed it many times. But DST is pretty slippery. I was definitely experiencing this at the time but then I fixed it; it totally stopped happening. Really. (Here we were talking about 1-hour increments.) This one is somewhat different. I sent a message to myself at 12:40. Looking at it in the spool, the time on the From line is right: From fdc@columbia.edu Tue Oct 8 12:40:15 2002 Return-Path: ... Date: Tue, 8 Oct 2002 12:40:12 EDT From: Frank da Cruz To: Frank da Cruz Subject: testing Message-ID: But when I read it in MM and write it out again: From fdc@columbia.edu Tue Oct 8 07:40:15 2002 Flags: 000000000000 Return-Path: ... From: Frank da Cruz To: Frank da Cruz Subject: testing Message-ID: Five hours off, which is our offset from GMT. OK, who adds the From line to the top? Since it does not include a timezone, MM interprets it as GMT and converts it to local time (but still without putting a timezone on it). I suspect the solution to this problem would be for whoever adds the From line to the top to specify the timezone. But if MM is going to rewrite the >From line (I still don't understand why it would do this) it probably should include a timezone. I'll add this to my list. - Frank From melissa@columbia.edu Tue Oct 8 10:02:05 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g98J21sc012706; Tue, 8 Oct 2002 15:02:01 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g98J21Kc024699; Tue, 8 Oct 2002 15:02:01 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g98J21CU024698; Tue, 8 Oct 2002 15:02:01 -0400 (EDT) Date: Tue, 8 Oct 2002 15:02:01 EDT From: Melissa Metz To: Frank da Cruz Cc: Ben Beecher , postmaster@columbia.edu, unix@columbia.edu, bug-mm@columbia.edu Subject: Re: [Frank da Cruz : Re: mail date?] In-Reply-To: Your message of Tue, 8 Oct 2002 12:59:56 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 118 I don't know if the format allows a timezone. Not a big deal if it isn't changed. MM rewrites the line because it is not stored as part of the message, it is part of the "envelope". However, it should be consistent about writing the time out in the "same timezone" it reads it in. > I'll add this to my list. Good answer :-). --Melissa From melissa@columbia.edu Tue Oct 8 10:02:05 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g98J21sc012706; Tue, 8 Oct 2002 15:02:01 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g98J21Kc024699; Tue, 8 Oct 2002 15:02:01 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g98J21CU024698; Tue, 8 Oct 2002 15:02:01 -0400 (EDT) Date: Tue, 8 Oct 2002 15:02:01 EDT From: Melissa Metz To: Frank da Cruz Cc: Ben Beecher , postmaster@columbia.edu, unix@columbia.edu, bug-mm@columbia.edu Subject: Re: [Frank da Cruz : Re: mail date?] In-Reply-To: Your message of Tue, 8 Oct 2002 12:59:56 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 119 I don't know if the format allows a timezone. Not a big deal if it isn't changed. MM rewrites the line because it is not stored as part of the message, it is part of the "envelope". However, it should be consistent about writing the time out in the "same timezone" it reads it in. > I'll add this to my list. Good answer :-). --Melissa From fdc@columbia.edu Tue Oct 8 10:59:47 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g98JxeIj014194; Tue, 8 Oct 2002 15:59:41 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g98JxeME014193; Tue, 8 Oct 2002 15:59:40 -0400 (EDT) Date: Tue, 8 Oct 2002 15:59:40 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: [Frank da Cruz : Re: mail date?] In-Reply-To: Your message of Tue, 8 Oct 2002 15:02:01 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 120 > I don't know if the format allows a timezone. > I still don't understand the From line. (I haven't looked at the code at all, thought I might save time by asking :-) Does MM add it when passes the message t Sendmail? Or does sendmail add it? Where is the "standard" that describes the format? Maybe it's always supposed to be in GMT, or include a GMT-relative offset? - Frank From melissa@columbia.edu Tue Oct 8 11:20:03 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g98KJrjV027654; Tue, 8 Oct 2002 16:19:53 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g98KJrKc026049; Tue, 8 Oct 2002 16:19:53 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id g98KJrio026048; Tue, 8 Oct 2002 16:19:53 -0400 (EDT) Date: Tue, 8 Oct 2002 16:19:53 EDT From: Melissa Metz To: Ben Beecher Cc: postmaster@columbia.edu, unix@columbia.edu, fdc@columbia.edu Subject: Re: [Frank da Cruz : Re: mail date?] In-Reply-To: Your message of Tue, 8 Oct 2002 12:34:35 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 121 > I have several messages in my mailbox with the wrong date in the From > field. You should be using MM's "mtxt" format instead of "mbox" format, which is much faster and has no From line. --Melissa From selsky@columbia.edu Tue Oct 8 20:24:41 2002 Flags: 000000000001 Return-Path: Received: from hazelnut.cc.columbia.edu (hazelnut.cc.columbia.edu [128.59.59.162]) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g990Oe0w006677 for ; Tue, 8 Oct 2002 20:24:40 -0400 (EDT) Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g990Oeqm006623 for ; Tue, 8 Oct 2002 20:24:40 -0400 (EDT) Received: (from selsky@localhost) by hazelnut.cc.columbia.edu (8.12.3/8.12.3/Submit) id g990Oe5V006622 for fdc@columbia.edu; Tue, 8 Oct 2002 20:24:40 -0400 (EDT) Date: Tue, 8 Oct 2002 20:24:40 -0400 From: Matt Selsky To: Frank da Cruz Subject: Re: [Frank da Cruz : Re: mail date?] Message-ID: <20021009002440.GA6517@columbia.edu> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Status: O X-Status: X-Keywords: X-UID: 122 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > ftp://kermit.columbia.edu/mm/mm-ccmd-0.91.tar [.Z, .gz] Thanks. When I tried building ccmd without specifying a target architecture, it started building but ran into problems immediately. It should require a target. The attached patch fixed the problem. --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Makefile.diff" --- ccmd/Makefile 2002/10/09 00:20:32 1.1 +++ ccmd/Makefile 2002/10/09 00:21:03 @@ -171,6 +171,9 @@ ALL = $(LIBRARY) $(PROGS) +usage: + @echo "Must be invoked with 'make '" + all: $(ALL) ############################################################# --0F1p//8PRICkK4MW-- From selsky@columbia.edu Tue Oct 8 20:24:41 2002 Flags: 000000000011 Return-Path: Received: from hazelnut.cc.columbia.edu (hazelnut.cc.columbia.edu [128.59.59.162]) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g990Oe0w006677 for ; Tue, 8 Oct 2002 20:24:40 -0400 (EDT) Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g990Oeqm006623 for ; Tue, 8 Oct 2002 20:24:40 -0400 (EDT) Received: (from selsky@localhost) by hazelnut.cc.columbia.edu (8.12.3/8.12.3/Submit) id g990Oe5V006622 for fdc@columbia.edu; Tue, 8 Oct 2002 20:24:40 -0400 (EDT) Date: Tue, 8 Oct 2002 20:24:40 -0400 From: Matt Selsky To: Frank da Cruz Subject: Re: [Frank da Cruz : Re: mail date?] Message-ID: <20021009002440.GA6517@columbia.edu> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Status: O X-Status: X-Keywords: X-UID: 123 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > ftp://kermit.columbia.edu/mm/mm-ccmd-0.91.tar [.Z, .gz] Thanks. When I tried building ccmd without specifying a target architecture, it started building but ran into problems immediately. It should require a target. The attached patch fixed the problem. --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="Makefile.diff" --- ccmd/Makefile 2002/10/09 00:20:32 1.1 +++ ccmd/Makefile 2002/10/09 00:21:03 @@ -171,6 +171,9 @@ ALL = $(LIBRARY) $(PROGS) +usage: + @echo "Must be invoked with 'make '" + all: $(ALL) ############################################################# --0F1p//8PRICkK4MW-- From lindaw@columbia.edu Thu Oct 10 12:14:57 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9AGEsIj014244; Thu, 10 Oct 2002 12:14:54 -0400 (EDT) Received: (from lindaw@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g9AGEs7Q014242; Thu, 10 Oct 2002 12:14:54 -0400 (EDT) Date: Thu, 10 Oct 2002 12:14:53 EDT From: Linda Wallinger To: Frank da Cruz Cc: Linda Wallinger , bug-mm@columbia.edu, melissa@columbia.edu Subject: Re: new MM In-Reply-To: Your message of Sat, 5 Oct 2002 13:57:00 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 124 > > I have to say I did not pay the closest attention to conversations on the > > new MM, but I see that it removes the Content-Type of the original > > message when a message is remailed. For example, I remailed myself a > > message that came in with Content-Type: text/html, and it was removed > > in the remailed version. Was that intentional? Since I often remail > > html-encoded messages to my test account for reading with a GUI email > > app, this is unfortunate (for me). > > > Fixed. New Solaris 2.5.1 Sparc binary in: > > ftp://ftp.columbia.edu/mm/binaries/mm-0.91-sparc-solaris-2.5.1 > > The ftp site is updated with the new source code: > > ftp://ftp.columbia.edu/mm/mm-ccmd-0.91.tar (and .tar.Z and .tar.gz) > > Melissa, if you want to pull a quick switch on the binary...? > > - Frank > > P.S. I don't think I'm on the bug-mm list; could you pls add me? Thanks! > Thanks! You were added to bug-mm. /Linda From fdc@columbia.edu Fri Oct 18 06:30:11 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9IFU9dH022022; Fri, 18 Oct 2002 11:30:09 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g9IFU9Tg022021; Fri, 18 Oct 2002 11:30:09 -0400 (EDT) Date: Fri, 18 Oct 2002 11:30:08 EDT From: Frank da Cruz To: pbp1@columbia.edu Cc: bug-mm@columbia.edu Subject: Re: temp files reappeared In-Reply-To: Your message of Fri, 18 Oct 2002 11:05:34 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 125 > FYI: For a while, MM was generating but not deleting temp files (I > have the temp file variable pointing to a directory in my own > account), but then it went back to its long-term behavior. Suddenly, > the permanent temp files are back. > They shouldn't be permanent. The change was to keep them around after exiting from EMACS so in case they were truncated somehow (which was a big problem -- at least for some people -- with the previous release) so you could get your editing back. The temp file is reused next time you enter EMACS in the same MM session, and it is deleted when you exit normally from MM. Are you exiting in some other way? - Frank From fdc@columbia.edu Fri Oct 18 06:51:44 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9IFpgdH023850; Fri, 18 Oct 2002 11:51:42 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g9IFpgO2023849; Fri, 18 Oct 2002 11:51:42 -0400 (EDT) Date: Fri, 18 Oct 2002 11:51:42 EDT From: Frank da Cruz To: pbp1@columbia.edu Subject: Re: temp files reappeared In-Reply-To: Your message of Fri, 18 Oct 2002 11:41:05 EDT Cc: bug-mm@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 126 > p.s. Is there a "MIME" compliant version/setting for MM? It would be a > convenience for the about 5% of my email that I get from MicroSoft users. > There was once an experimental version of MM that ran incoming MIME messages through metamail; I don't know what became of it. But that won't help you much with Word enclosures, spreadsheets, etc, except by decoding the files and saving them to disk. Another option is to have MM download the message to your PC, if you have one, and then (after first satisfying yourself that the message isn't a virus) feeding it to Outlook or whatever. For details, see: ftp://kermit.columbia.edu/mm/release-0.91.txt - Frank From fdc@columbia.edu Sun Oct 20 22:00:45 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id g9LH0gq5021581; Mon, 21 Oct 2002 13:00:42 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id g9LH0f0c021571; Mon, 21 Oct 2002 13:00:41 -0400 (EDT) Date: Mon, 21 Oct 2002 13:00:41 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM core dump In-Reply-To: Your message of Mon, 21 Oct 2002 9:48:37 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 127 > Ah, never mind, it isn't a space, it is a non-ascii character. Emacs > is giving me a hard time too. > > > Char: (04240, 2208, 0x8a0, ext 0xa0) point=39 of 205(19%) column 37 > EMACS is tricking you. I looked at mark.txt and it's really: Char: ? (0240, 160, 0xa0, ext 0xa0) The newer versions of EMACS mangle their buffers when they encounter 8-bit text, which drives me nuts. Anyway, it's Latin-1 No-Break-Space (aka  ). I also notice that bash and ksh don't like 8-bit keyboard chars much either. sh is OK with them. It doesn't matter what your stty settings are. Anyway, get used to this -- Microsoft mail clients put weird PC code page page characters even in plain-text email -- e.g. "smart quotes" (they actually call them that), weird apostrophes, etc. These can confuse the heck out of your terminal (xterm, kermit, whatever) even when you're just READING your mail, because they appear in the C1 control-character positions (0x80-0x9f). What's more, they lie about it and announce their charset as ISO-8859-1. But obviously MM should not dump core if you type NBSP into it... I'll add this to my list, but if somebody who is familiar with parse() looks at it first I won't mind :-) - Frank From melissa@columbia.edu Fri Nov 8 04:50:47 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gA8Eok5m000466 for ; Fri, 8 Nov 2002 09:50:46 -0500 (EST) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gA8EokKc012154 for ; Fri, 8 Nov 2002 09:50:46 -0500 (EST) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id gA8EokIN012153 for fdc; Fri, 8 Nov 2002 09:50:46 -0500 (EST) Resent-Message-Id: <200211081450.gA8EokIN012153@broccoli.cc.columbia.edu> Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gA88Vqfx023762 for ; Fri, 8 Nov 2002 03:31:52 -0500 (EST) Received: (from selsky@localhost) by hazelnut.cc.columbia.edu (8.12.3/8.12.3/Submit) id gA88Vqhc023761 for melissa@columbia.edu; Fri, 8 Nov 2002 03:31:52 -0500 (EST) Date: Fri, 8 Nov 2002 03:31:52 -0500 From: Matt Selsky To: Melissa Metz Subject: Fwd: *****SPAM***** Midnight Shift Report, Thursday Message-ID: <20021108083152.GE23183@columbia.edu> Content-Disposition: inline User-Agent: Mutt/1.4i Resent-To: fdc@columbia.edu Resent-Date: Fri, 8 Nov 2002 9:50:46 EST Resent-From: Melissa Metz Status: O X-Status: X-Keywords: X-UID: 128 Haha. Is it an MM bug that the date isn't in RFC 2822 format? ----- Forwarded message from George Rivera ----- Date: Fri, 8 Nov 2002 0:02:42 EST From: George Rivera To: Shift-Report@columbia.edu Subject: *****SPAM***** Midnight Shift Report, Thursday SPAM: -------------------- Start SpamAssassin results ---------------------- SPAM: This mail is probably spam. The original message has been altered SPAM: so you can recognise or block similar unwanted mail in future. SPAM: See http://spamassassin.org/tag/ for more details. SPAM: SPAM: Content analysis details: (5.20 hits, 5 required) SPAM: INVALID_DATE (1.5 points) Invalid Date: header (not RFC 2822) SPAM: FROM_ENDS_IN_NUMS (0.9 points) From: ends in numbers SPAM: SPAM_PHRASE_00_01 (0.8 points) BODY: Spam phrases score is 00 to 01 (low) SPAM: LINES_OF_YELLING_3 (0.3 points) BODY: 3 WHOLE LINES OF YELLING DETECTED SPAM: LINES_OF_YELLING_2 (0.2 points) BODY: 2 WHOLE LINES OF YELLING DETECTED SPAM: LINES_OF_YELLING (0.2 points) BODY: A WHOLE LINE OF YELLING DETECTED SPAM: UPPERCASE_25_50 (1.3 points) message body is 25-50% uppercase SPAM: SPAM: -------------------- End of SpamAssassin results --------------------- Thursday November.07,2002. ============================================================================================================== REGION SHUTDOWN ISSUED AT: REGION DOWN AT: CICSWEB0 22:00 22:00 CICSP3 22:00 22:01 CICSP2 21:04 21:04 CICSDEV1 23:00 23:00 CICSDEV4 17:00 17:01 CICSPROD 17:00 17:01 CICSTEST 21:02 21:03 CICSPRD4 17:00 17:03 M204APS 17:00 17:02 M204TCAR 19:00 19:02 M204TEST 19:00 19:02 M204PROD 20:00 20:02 POSTP3 22:02 POSTCICS 17:03 POSTMAPS 17:03 POSTM204PROD 20:03 DEV1 POSTED 23:01 Printed Output ============== 23:59 Output has been printed and no outstanding Special Forms in queue. HARDWARE PROBLEM ================ TAPE DRIVE 782 08:30 Tape drive down with equipment check error. DEVICE 3490 Call place to IBM; ref# 23-REETC. 12:30 John K. IBM/CE arrived at site. Reseated cable at tape control card causing- error. Device will be down due to parts. When parts arrive, please notify IBM service rep. 17:30 Parts have arrived and IBM has been notified. 17:40 IBM/CE called and will be in about 1 hour and a half. 18:25 Brent S. IBM/CE arrived at site. 19:45 IBM/CE replaces feeder ASM and tested tape drive. Tape drive up and running. LAB ALERTS ========== NONE MVS/NOTIS SYSTEM ================ No outstanding messages in system. I/O REPORT ========== NONE MISCELLANEOUS ============= NONE ACTIVITY IN MACHINE ROOM ======================== NONE ----- End forwarded message ----- From melissa@columbia.edu Fri Nov 8 04:54:28 2002 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gA8EsN5m003070; Fri, 8 Nov 2002 09:54:23 -0500 (EST) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gA8EsNKc012216; Fri, 8 Nov 2002 09:54:23 -0500 (EST) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id gA8EsM8W012215; Fri, 8 Nov 2002 09:54:22 -0500 (EST) Date: Fri, 8 Nov 2002 9:54:22 EST From: Melissa Metz To: Matt Selsky Cc: Melissa Metz , fdc@columbia.edu Subject: Re: Fwd: *****SPAM***** Midnight Shift Report, Thursday In-Reply-To: Your message of Fri, 8 Nov 2002 03:31:52 -0500 Message-ID: Status: O X-Status: X-Keywords: X-UID: 129 > Haha. Is it an MM bug that the date isn't in RFC 2822 format? Matt's message: > Date: Fri, 8 Nov 2002 03:31:52 -0500 Shift Report: > Date: Fri, 8 Nov 2002 0:02:42 EST (I checked the original message, and the Message-ID confirms this was >From MM.) So we're not allowed to use the common name for the timezone anymore? How non-human. Or the hour can't be "03"? > From: George Rivera > SPAM: FROM_ENDS_IN_NUMS (0.9 points) From: ends in numbers Spam Assassin doesn't like our usernames? > SPAM: LINES_OF_YELLING_3 (0.3 points) BODY: 3 WHOLE LINES OF YELLING DETECTED Hee hee hee. --Melissa From fdc@columbia.edu Fri Nov 8 05:13:04 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gA8FD1FP004784; Fri, 8 Nov 2002 10:13:01 -0500 (EST) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id gA8FD1Po004778; Fri, 8 Nov 2002 10:13:01 -0500 (EST) Date: Fri, 8 Nov 2002 10:13:00 EST From: Frank da Cruz To: Melissa Metz Cc: Matt Selsky , bug-mm@columbia.edu Subject: Re: Fwd: *****SPAM***** Midnight Shift Report, Thursday In-Reply-To: Your message of Fri, 8 Nov 2002 9:54:22 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 130 > > Haha. Is it an MM bug that the date isn't in RFC 2822 format? > > Matt's message: > > Date: Fri, 8 Nov 2002 03:31:52 -0500 > > Shift Report: > > Date: Fri, 8 Nov 2002 0:02:42 EST > > (I checked the original message, and the Message-ID confirms this was > from MM.) > > So we're not allowed to use the common name for the timezone anymore? > How non-human. Or the hour can't be "03"? > See: ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt In which the timezone is: zone = (( "+" / "-" ) 4DIGIT) / obs-zone Section 3.1 says: In some of the definitions, there will be nonterminals whose names start with "obs-". These "obs-" elements refer to tokens defined in the obsolete syntax in section 4. In all cases, these productions are to be ignored for the purposes of generating legal Internet messages and MUST NOT be used as part of such a message. However, when interpreting messages, these tokens MUST be honored as part of the legal syntax. In this sense, section 3 defines a grammar for generation of messages, with "obs-" elements that are to be ignored, while section 4 adds grammar for interpretation of messages. Thus it is wrong to reject messages containing the following timezones: "EST" / "EDT" / ; Eastern: - 5/ - 4 "CST" / "CDT" / ; Central: - 6/ - 5 "MST" / "MDT" / ; Mountain: - 7/ - 6 "PST" / "PDT" / ; Pacific: - 8/ - 7 as well as "GMT", "UT", or "A" thru "Z" (except "J"). But yes, MM should be fixed to not generate the old timezones. I'll add this to my list, along with figuring out what to do about the From line's timezone. But I probably won't be able to get to it any time soon. - Frank From rossman@columbia.edu Wed Nov 20 11:59:49 2002 Flags: 000000000011 Return-Path: Received: from columbia.edu (pcp02173130pcs.verona01.nj.comcast.net [68.36.173.167]) (user=rossman mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gAKLxkWS010311 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 20 Nov 2002 16:59:48 -0500 (EST) Date: Wed, 20 Nov 2002 16:59:46 -0500 Subject: mm (0.91) and OSX Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Ken Rossman To: fdc@columbia.edu From: Ken Rossman Content-Transfer-Encoding: 7bit Message-Id: <61E56DB1-FCD3-11D6-9240-00039384248C@columbia.edu> X-Mailer: Apple Mail (2.548) Status: O X-Status: X-Keywords: X-UID: 131 Hi Frank, Unless you will tell me that you know of someone else already working on a MacOS/X port of MM, I am undertaking it now myself... I just pulled down the recently posted 0.91 version of mm and friends (will it *ever* hit version 1???! :-) and am mucking with it. I've already hit up against a snag right out of the box... can't find the struct member "gr_name" which is supposed to be associated with struct grp in cmgrp.h. Any ideas? I am starting out by using "make bsd44" under MacOS/X, which I *think* ought to get me in the general neighborhood anyway... /K Ken Rossman rossman@columbia.edu 973-202-0974 From rossman@columbia.edu Wed Nov 20 12:08:25 2002 Flags: 000000000011 Return-Path: Received: from columbia.edu (pcp02173130pcs.verona01.nj.comcast.net [68.36.173.167]) (user=rossman mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gAKM8AWS017083 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 20 Nov 2002 17:08:24 -0500 (EST) Date: Wed, 20 Nov 2002 17:08:10 -0500 Subject: Re: mm (0.91) and OSX Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Ken Rossman To: Frank da Cruz From: Ken Rossman In-Reply-To: Message-Id: <8E3D6514-FCD4-11D6-9240-00039384248C@columbia.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Status: O X-Status: X-Keywords: X-UID: 132 Hi Frank, >> Unless you will tell me that you know of someone else already working >> on a MacOS/X port of MM, I am undertaking it now myself... >> > Hey, go for it... It should be hard, since it already works on > OpenBSD, NetBSD, and FreeBSD, which are very similar to Mac OS X. I take it you meant it *shouldn't* be hard... and I agree. >> I am starting out by using "make bsd44" under MacOS/X, which I *think* >> ought to get me in the general neighborhood anyway... >> > You need to -Dunix as in the netbsd and openbsd targets. Maybe you can > just use that target, or mix and match stuff from it and the bsd44 one. I wanted to ultimately create a new target for MacOSX (10.2) -- not sure exactly what to name it either, but I'll work that out. Apparently, compiling this under Jaguar (MacOS 10.2) may not be the same as making it work under 10.1.5 and earlier -- in fact probably not. I'm not plan- ning on going backwards in the MacOS revisions, though... > I don't have any time for this right now, but let me know how it > goes... I understand... anyway, I'll start building a new target for OSX, and try mixing and matching. More later, /Ken From fdc@columbia.edu Wed Nov 20 12:12:14 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gAKMCDSb008552; Wed, 20 Nov 2002 17:12:13 -0500 (EST) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id gAKMCDlw008551; Wed, 20 Nov 2002 17:12:13 -0500 (EST) Date: Wed, 20 Nov 2002 17:12:12 EST From: Frank da Cruz To: Ken Rossman Subject: Re: mm (0.91) and OSX In-Reply-To: Your message of Wed, 20 Nov 2002 17:08:10 -0500 Message-ID: Status: O X-Status: X-Keywords: X-UID: 133 > I take it you meant it *shouldn't* be hard... and I agree. > I can never send email or post netnews any more without at least one typo that reverses the meaning. It's a disease. > I wanted to ultimately create a new target for MacOSX (10.2) -- not sure > exactly what to name it either, but I'll work that out. Apparently, > compiling this under Jaguar (MacOS 10.2) may not be the same as making > it work under 10.1.5 and earlier -- in fact probably not. I'm not plan- > ning on going backwards in the MacOS revisions, though... > The Kermit builds for the various versions are not very different, mainly just in curses-related things. 10.2 is getting almost like the other BSDs. The Kermit target for this is called macosx102, in case you want to be compatible. - Frank From rossman@columbia.edu Wed Nov 20 14:36:41 2002 Flags: 000000000001 Return-Path: Received: from columbia.edu (pcp02173130pcs.verona01.nj.comcast.net [68.36.173.167]) (user=rossman mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gAL0aeWS019620 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 20 Nov 2002 19:36:41 -0500 (EST) Date: Wed, 20 Nov 2002 19:36:40 -0500 Subject: Re: mm (0.91) and OSX Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Ken Rossman To: Frank da Cruz From: Ken Rossman In-Reply-To: Message-Id: <4D312EA5-FCE9-11D6-9240-00039384248C@columbia.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Status: O X-Status: X-Keywords: X-UID: 134 >> I take it you meant it *shouldn't* be hard... and I agree. >> > I can never send email or post netnews any more without at least one > typo that reverses the meaning. It's a disease. I understand! :) >> I wanted to ultimately create a new target for MacOSX (10.2) -- not >> sure >> exactly what to name it either, but I'll work that out. Apparently, >> compiling this under Jaguar (MacOS 10.2) may not be the same as making >> it work under 10.1.5 and earlier -- in fact probably not. I'm not >> plan- >> ning on going backwards in the MacOS revisions, though... >> > The Kermit builds for the various versions are not very different, > mainly > just in curses-related things. I already fixed the curses dependencies (ncursees works)... > 10.2 is getting almost like the other BSDs. Which is a good thing. > The Kermit target for this is called macosx102, in case you want to be > compatible. So someone already came up with that as a standard? I started out using that, but then backed off to just macosx. I see that it really should be macosx102, though -- who knows how different it will be as MacOS/X progresses. I'm hitting up against a missing macro, I think, right now, called, simply, "number". I'll see if I can run that down. CCMD already compiles completely cleanly after the curses thing got fixed. /Ken From fn@panix.com Wed Dec 4 12:00:41 2002 Flags: 000000000011 Return-Path: Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gB4M0eQ8023815 for ; Wed, 4 Dec 2002 17:00:41 -0500 (EST) Received: from panix1.panix.com (panix1.panix.com [166.84.1.1]) by mail3.panix.com (Postfix) with ESMTP id 457D498197 for ; Wed, 4 Dec 2002 17:00:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by panix1.panix.com (8.11.6/8.8.8/PanixN1.0) with ESMTP id gB4M0eI21411 for ; Wed, 4 Dec 2002 17:00:40 -0500 (EST) Date: Wed, 4 Dec 2002 17:00:40 -0500 (EST) From: Felicia Neff To: fdc@columbia.edu Subject: mm feature request Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 135 Is there any chance that maildir or imap support could be added to mm? I know mm development isn't all that active, but I thought I would ask. Thanks -- Felicia Neff ~~~~~~~~~~~~~~ fn@panix.com Panix Staff From fdc@columbia.edu Wed Dec 4 12:06:35 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gB4M6YmL022873; Wed, 4 Dec 2002 17:06:35 -0500 (EST) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id gB4M6YLg022872; Wed, 4 Dec 2002 17:06:34 -0500 (EST) Date: Wed, 4 Dec 2002 17:06:34 EST From: Frank da Cruz To: Felicia Neff Subject: Re: mm feature request In-Reply-To: Your message of Wed, 4 Dec 2002 17:00:40 -0500 (EST) Message-ID: Status: O X-Status: X-Keywords: X-UID: 136 > Is there any chance that maildir or imap support could be added to mm? I > know mm development isn't all that active, but I thought I would ask. > The trick for for using mm with Imap is to install a version of movemail that does it in the directory where mm looks for it. I plan to try figuring this out for Linux as soon as I get chance but so far that's all I can tell you. Supposedly the movemail that comes with GNU EMACS does the trick? To actually integrate Imap into mm itself... This might be a good project for Mark Crispin :-) He's responsible for Imap, and he was also the primary author/maintainer of the original DEC-20 MM for many years... Failing that, anybody who wants to, is able to, and has the time is welcome to work on it. - Frank From ron@isri.unlv.edu Tue Dec 10 12:34:13 2002 Flags: 000000000001 Return-Path: Received: from homebase.isri.unlv.edu (homebase.isri.unlv.edu [131.216.20.105]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBAMYC6w004481 for ; Tue, 10 Dec 2002 17:34:13 -0500 (EST) Received: from wiggins.isri.unlv.edu (wiggins.isri.unlv.edu [131.216.20.115]) by homebase.isri.unlv.edu (Postfix) with ESMTP id 467F52E6B9; Tue, 10 Dec 2002 14:34:10 -0800 (PST) To: Frank da Cruz Cc: ron@isri.unlv.edu Subject: MM/ccmd continuation line patch Date: Tue, 10 Dec 2002 14:34:10 -0800 From: Ron Young Message-Id: <20021210223410.467F52E6B9@homebase.isri.unlv.edu> Status: O X-Status: X-Keywords: X-UID: 137 Dear Frank: I have attached a diff listing that fixes a minor bug with continuation line processing. I have also added the ability to display a "secondary" prompt (on each continuation line). The diffs are relative to mm-ccmd-0.91. Please consider them for inclusion in the distributed version. -ron P.S. Do you know if anyone is working on adding windows NT/2k support (specifically for ccmd)? I am using ccmd as my CLI processor for a custom information retrevial system, and I would very much like to include windows support. Just from a quick test, it looks like ccmd will work under cygwin with a hybrid linux/msdos configuration. =============================================================================== Ron Young, Sr. Software Design Engineer & System Admin. (702) 895-1070 (voice) Information Science Research Institute (702) 895-1183 (fax) University of Nevada, Las Vegas (UNLV/ISRI) ron@isri.unlv.edu Box 454021, Las Vegas, NV 89154 diff -c -r ../ccmd-dist/ccmd.c ./ccmd.c *** ../ccmd-dist/ccmd.c 2002-09-17 07:34:06.000000000 -0700 --- ./ccmd.c 2002-12-10 13:45:59.000000000 -0800 *************** *** 26,31 **** --- 26,32 ---- NULL, /* output to console */ NULL, /* error output */ NULL, /* no prompt set yet */ + NULL, /* no continuation prompt set yet */ NULL, /* no command line buffer yet */ NULL, /* no characters to parse */ 0, /* size of nonexistent command buffer */ *************** *** 345,350 **** --- 346,381 ---- } + /* subprompt + ** + ** Purpose: + ** Initializes a prompt string to be issued to a user after he enters a + ** continuation character (the variable cmcont contains the continuation + ** character). + ** + ** Input arguments: + ** prompt - The prompt string to be issued. The string must be preserved + ** throughout the parsing of the command line, as it will be referenced + ** whenever the command line must be redisplayed (after a help request, + ** when the user types ^R, etc.). In other words, do not pass + ** a pointer to dynamic storage that may be deallocated before parsing + ** is complete. + ** + ** Output arguments: none + ** + ** Returns: Standard return code. + **/ + + int + subprompt(p) + char *p; + { + int ret; + cmcsb._cmrty2 = p; /* save pointer to subprompt string */ + return(CMxOK); /* return success */ + } + + /* parse ** diff -c -r ../ccmd-dist/ccmd.guide ./ccmd.guide *** ../ccmd-dist/ccmd.guide 1990-12-18 10:40:58.000000000 -0800 --- ./ccmd.guide 2002-12-10 14:12:13.000000000 -0800 *************** *** 234,239 **** --- 234,240 ---- FILE * _cmoj; /* file for command output */ FILE * _cmej; /* file for error output */ char * _cmrty; /* pointer to prompt string */ + char * _cmrty2; /* pointer to continuation prompt string */ int * _cmbfp; /* pointer to beginning of user input */ int * _cmptr; /* pointer to beg of next field to parse */ int _cmcnt; /* # of chars in buffer past _cmptr */ *************** *** 747,756 **** anything. Then, if you enter the function and the pointer is non-NULL, you will know you have to free the storage. ! f) prompt(str) char *str; ! This sets up the string that will be used for prompting. It is generally done before the first parse of a command, inside a command parsing loop. --- 748,757 ---- anything. Then, if you enter the function and the pointer is non-NULL, you will know you have to free the storage. ! f) prompt(str) and subprompt(str) char *str; ! This sets up the string(s) that will be used for prompting. It is generally done before the first parse of a command, inside a command parsing loop. *************** *** 760,765 **** --- 761,772 ---- In addition, if cmseti() has not been done it will be automatically called. + subprompt() is used to set the secondary prompt that is displayed for + a command continued on a secord (or later) line. if subprompt() has + not been called, the secondary prompt defaults to the continuation + character, followed by the primary prompt. + + g) fdbchn (fdb1, [ fdbn, ] ... NULL) fdb fdb1, fdbn; diff -c -r ../ccmd-dist/ccmd.h ./ccmd.h *** ../ccmd-dist/ccmd.h 2000-12-06 20:59:44.000000000 -0800 --- ./ccmd.h 2002-12-10 13:47:07.000000000 -0800 *************** *** 95,100 **** --- 95,101 ---- FILE * _cmoj; /* file for command output */ FILE * _cmej; /* file for error output */ char * _cmrty; /* pointer to prompt string */ + char * _cmrty2; /* pointer to continuation prompt string */ int * _cmbfp; /* pointer to beginning of user input */ int * _cmptr; /* pointer to beg of next field to parse */ int _cmcnt; /* # of chars in buffer past _cmptr */ diff -c -r ../ccmd-dist/stdact.c ./stdact.c *** ../ccmd-dist/stdact.c 2002-02-20 00:53:28.000000000 -0800 --- ./stdact.c 2002-12-10 14:00:10.000000000 -0800 *************** *** 340,358 **** int ret; int *end; /* end of current input */ - if (!deferred) - return(CMxDFR); - if (cmcsb._cminc > 0) { /* is there unparsed input? */ end = cmcsb._cmcur - 1; /* point to last char */ if ((*end & CC_QCH) == cmcont) { /* last char continuation char? */ /* (fails if quoted) */ *end |= CC_CSK; /* make it conditionally skipped */ ret = cmsti1(NEWLINE,CC_SKP); /* and stuff a skipped newline */ return(ret); /* no wakeup */ } } if (cmcsb._cmflg & CM_CMT) { /* if inside a comment */ cmcsb._cmflg &= ~CM_CMT; /* then turn off the comment */ } --- 340,368 ---- int ret; int *end; /* end of current input */ if (cmcsb._cminc > 0) { /* is there unparsed input? */ end = cmcsb._cmcur - 1; /* point to last char */ if ((*end & CC_QCH) == cmcont) { /* last char continuation char? */ /* (fails if quoted) */ *end |= CC_CSK; /* make it conditionally skipped */ ret = cmsti1(NEWLINE,CC_SKP); /* and stuff a skipped newline */ + if (cmcsb._cmrty2 != NULL) + { + cmxputs(cmcsb._cmrty2); /* print secondary prompt if any */ + } + else + { + cmxputc(cmcont); /* make secondard prompt: prefix */ + cmxputs(cmcsb._cmrty); /* continuation character to front */ + } /* of primary prompt */ + return(ret); /* no wakeup */ } } + if (!deferred) + return(CMxDFR); + if (cmcsb._cmflg & CM_CMT) { /* if inside a comment */ cmcsb._cmflg &= ~CM_CMT; /* then turn off the comment */ } *************** *** 569,575 **** cmcsb._cmcol = 0; if (cp1 == cmcsb._cmbfp) { /* killed prompt line? */ cmxputs(cmcsb._cmrty); /* then reprompt */ ! } cmcsb._cmcur = cp1; cmcsb._cmcur = disp_forward_char(cp2 - cp1); --- 579,593 ---- cmcsb._cmcol = 0; if (cp1 == cmcsb._cmbfp) { /* killed prompt line? */ cmxputs(cmcsb._cmrty); /* then reprompt */ ! } else if (cmcsb._cmrty2 != NULL) /* do we have a secondary prompt? */ ! { ! cmxputs(cmcsb._cmrty2); /* yes, print it */ ! } ! else ! { ! cmxputc(cmcont); /* no, build one, prefix cont. char */ ! cmxputs(cmcsb._cmrty); /* in front of primary prompt */ ! } cmcsb._cmcur = cp1; cmcsb._cmcur = disp_forward_char(cp2 - cp1); From fdc@columbia.edu Wed Dec 11 08:16:21 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBBIGJmL022597; Wed, 11 Dec 2002 13:16:19 -0500 (EST) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id gBBIGILM022596; Wed, 11 Dec 2002 13:16:18 -0500 (EST) Date: Wed, 11 Dec 2002 13:16:18 EST From: Frank da Cruz To: Mark Crispin Cc: AMartin.MA.UltraNet@RCN.Com Subject: Re: [Fwd: UTF-9, UTF-18, UTF-36] In-Reply-To: Your message of Wed, 11 Dec 2002 10:08:08 -0800 (PST) Message-ID: Status: O X-Status: X-Keywords: X-UID: 138 > > Mark probably knows more about this than I do, but I recall hearing when I > > was at NTT in Tokyo in 1987 that DEC-20s were popular in Japan because > > applications could use larger byte sizes > > I think that this was more for AI stuff than character sets. > I lost touch with Murakami-san years ago. I knew some guys at KEK too, but they didn't use TOPS-20. > This is indeed intended to be a spec that some bored person could > actually grab and run with. I'm that bored person. The goal at > the other end is TOPS-20 Pine and a completely modernized > mailsystem. > Ironically I'm going to have to get MM working on Linux one of these days. I have it compiling and running (and as you may have seen I found a way to make it handle 8-bit mail and added the ability to generate MIME headers indentifying the character set). The part I haven't figured out yet is how to make it get my incoming mail (either I can NFS-mount the University-wide mail spool tree, or I can find and configure a version of movemail that understands IMAP -- or I can trick you into adding IMAP directly to C-MM, since you're bored :-) > Since my focus is on application support, I'm not going to worry > about kernel support for Unicode until much, much later. I don't > think that we really need Unicode filenames. > Actually all this stuff is way too much for me. The debates about filenames and Internet host names versus normalization and spoofing... Things will only get worse once this stuff is unleashed on the world. And things are bad enough already! - Frank From fdc@columbia.edu Wed Dec 11 12:11:08 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBBMB5mL010972; Wed, 11 Dec 2002 17:11:05 -0500 (EST) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id gBBMB5xw010971; Wed, 11 Dec 2002 17:11:05 -0500 (EST) Date: Wed, 11 Dec 2002 17:11:05 EST From: Frank da Cruz To: Melissa Metz Cc: bug-mm@columbia.edu, postmaster@columbia.edu Subject: MM lockfile Message-ID: Status: O X-Status: X-Keywords: X-UID: 139 Stale lock files seem to be the biggest complaint about MM any more, and it's a rather frequent one. Do you have any idea what might be done in MM itself to improve the situation? Usually the situation is that user A was logged into host B and was disconnected but MM never received a SIGHUP. User reconnects, but now gets host C. Even if the user knew how to use ps and kill, it wouldn't do any good in this case. I haven't looked at the locking code at all but I expect that MM looks for a lockfile (as opposed to trying to put a kernel lock on the mail file, which would be kind of useless in NFS?)... In that case, maybe there could just be an option to override, for when the user knows the lock is invalid. EMACS does this. Does it sound right for MM? - Frank From fdc@columbia.edu Fri Dec 27 07:47:33 2002 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBRHlTe1008263; Fri, 27 Dec 2002 12:47:29 -0500 (EST) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id gBRHlTas008262; Fri, 27 Dec 2002 12:47:29 -0500 (EST) Date: Fri, 27 Dec 2002 12:47:29 EST From: Frank da Cruz To: Melissa Metz Subject: [Misha Harnick : please help] Cc: bug-mm@columbia.edu, postmaster@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 140 Can you suggest any function that could be added to MM itself to let the user override the lock? I know EMACS has something like this, and I assume Pine must have a way to do it too. The way it is now, users are helpless unless they know how to find the host where they were logged in, look for themselves in ps, and kill the abandoned MM process. I'll be glad to do the programming but if somebody already knows how Pine or EMACS handle locks, it would save me the research time. Thanks. - Frank Date: Fri, 27 Dec 2002 12:41:57 EST From: Misha Harnick To: bug-mm@columbia.edu Subject: please help Message-ID: ?Can't lock /u/2/h/harnick/mbox: file is busy True enough: I was kicked off in a dial-in envireonemtn. Please "unfreeze" me -- thanks, misah From melissa@columbia.edu Fri Dec 27 08:28:54 2002 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBRISrTK021428; Fri, 27 Dec 2002 13:28:53 -0500 (EST) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBRISrfB023431; Fri, 27 Dec 2002 13:28:53 -0500 (EST) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id gBRISrj6023430; Fri, 27 Dec 2002 13:28:53 -0500 (EST) Date: Fri, 27 Dec 2002 13:28:53 EST From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz , bug-mm@columbia.edu, postmaster@columbia.edu Subject: Re: [Misha Harnick : please help] In-Reply-To: Your message of Fri, 27 Dec 2002 12:47:29 EST Message-ID: Status: O X-Status: X-Keywords: X-UID: 141 consultant usually helps them with this. I think Joe Brennan may have written a script to search for and kill the offending process. If the process cannot be found, we move the mail file out of the way and make a new copy (i.e. new inode). Then it is no longer locked. --Melissa From melissa@columbia.edu Sat Jan 4 16:50:41 2003 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0DKo37p022223; Mon, 13 Jan 2003 15:50:03 -0500 (EST) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0DKo3fB017205; Mon, 13 Jan 2003 15:50:03 -0500 (EST) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id h0DKo3ms017198; Mon, 13 Jan 2003 15:50:03 -0500 (EST) Date: Mon, 13 Jan 2003 15:50:02 EST From: Melissa Metz To: unixsys@columbia.edu, postmaster@columbia.edu, fdc@columbia.edu Subject: new mm.conf up Message-ID: Status: O X-Status: X-Keywords: X-UID: 142 I'm installing a new version of /opt/ACISmm/lib/mm.conf. This has three "newcunix compatibility" settings: set print-filter /opt/local/bin/print set mmail-path /opt/local/lib/mmail.el set movemail-path /opt/local/bin/movemail I used ldist and I'm about to run "./opium.pl -p ACISmm". I confirmed that the above /opt/local files exist on old cunix and point to the right versions. --Melissa From benno@columbia.edu Sun Jan 26 03:37:44 2003 Flags: 000000000011 Return-Path: Received: from [192.168.0.162] (user-0cev0du.cable.mindspring.com [24.239.129.190]) (user=benno mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0REbdUP014044 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 27 Jan 2003 09:37:40 -0500 (EST) Date: Mon, 27 Jan 2003 09:38:15 -0500 From: Benn Oshrin To: Frank da Cruz , Matt Selsky cc: Melissa Metz , unixsys@columbia.edu, postmaster@columbia.edu Subject: Re: new mm.conf up Message-ID: <2147483647.1043660295@[192.168.0.162]> In-Reply-To: References: X-Mailer: Mulberry/3.0.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Status: O X-Status: X-Keywords: X-UID: 143 Frank da Cruz wrote on Sunday, 26 January 2003 1:20 QM -0500: ] I know how to do it, I simply question whether it's a good idea. ] The file system should not be changed in a way that breaks applications. ] Why would you put an mm.conf in a directory that MM doesn't look in? Basically, /usr/local on our SunOS and Solaris 2.5 hosts became a cesspool of unmanageable software droppings. Beginning with Solaris 2.7, we began package based installation of software to facilitate updating and removal. As you know, Solaris packages are installed under /opt. Software configuration files should either be installed with the package or in a version independent location under /etc. As I hope you would agree, software distributions shouldn't enforce their own expectations about where files are to be installed, but should provide reasonable defaults that can be overridden at compilation, installation, and/or run times. If the standard installation of mm defaults to /usr/local/lib/mm, that's fine, but there's no reason we shouldn't then be able to override that location to fit with our standard filesystem layout. Since mm is installed at the system level, there is no reason we can't install a version with the correct (for us) path, eliminating the need to leave a symlink behind. We use the absence of a /usr/local directory as one method to verify that software is installed correctly, leaving an unneeded /usr/local/lib/mm/mm.conf -> wherever link behind would make such verification less obvious. -Benn- From selsky@columbia.edu Tue Jan 28 15:08:18 2003 Flags: 000000000001 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0T17ifx017522; Tue, 28 Jan 2003 20:07:44 -0500 (EST) Received: (from selsky@localhost) by hazelnut.cc.columbia.edu (8.12.3/8.12.3/Submit) id h0T17iUl017521; Tue, 28 Jan 2003 20:07:44 -0500 (EST) Date: Tue, 28 Jan 2003 20:07:44 -0500 From: Matt Selsky To: Frank da Cruz Cc: Benn Oshrin , Melissa Metz , unixsys@columbia.edu, postmaster@columbia.edu Subject: Re: new mm.conf up Message-ID: <20030129010744.GA17394@columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Status: O X-Status: X-Keywords: X-UID: 144 > OK, I made a new MM binary for Solaris/Sparc 2.5.1 with the new paths; you > can find it and the other binaries (like movemail -- is this the one you use?) > here: > > /pub/ftp/kermit/mm/cu/binaries/solaris-2.5.1-sparc/ > > It works fine on Watsol, Cunix, and Newcunix. The modified Makefile and > config.h are in > > /pub/ftp/kermit/mm/cu/src/ Thanks. This new version has been made available on cunix/newcunix. The old version still exists as /opt/ACISmm/bin/mm.old From owner-outage-report@columbia.edu Wed Jan 29 08:10:56 2003 Flags: 000000000001 Return-Path: Received: from maillist1.cc.columbia.edu (localhost [127.0.0.1]) by maillist1.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0TIAf3b017207 for ; Wed, 29 Jan 2003 13:10:41 -0500 (EST) Received: by maillist1.cc.columbia.edu (8.12.3/8.12.3/Submit) id h0TIAfO0017206 for outage-report-outgoing; Wed, 29 Jan 2003 13:10:41 -0500 (EST) Received: from dewberry.cc.columbia.edu (dewberry.cc.columbia.edu [128.59.59.68]) by maillist1.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0TIAd3b017197 for ; Wed, 29 Jan 2003 13:10:39 -0500 (EST) Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0TIAYH9004432 for ; Wed, 29 Jan 2003 13:10:34 -0500 (EST) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0TIAYfB021566 for ; Wed, 29 Jan 2003 13:10:34 -0500 (EST) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.3/8.12.3/Submit) id h0TIAYC7021565 for outage-report; Wed, 29 Jan 2003 13:10:34 -0500 (EST) Date: Wed, 29 Jan 2003 13:10:33 EST From: Melissa Metz To: outage-report@columbia.edu Subject: MM not getting new mail Message-ID: Sender: owner-outage-report@columbia.edu Precedence: bulk Status: O X-Status: X-Keywords: X-UID: 145 For those few who still use MM, a new version was installed last night around 8pm, which apparently does not get new mail for most users (though of course it works for those who were testing it). The old version was put back in place at around 1pm today. The fix we were installing was to make MM work better on newcunix... Melissa Metz Manager, Computing Systems From fdc@columbia.edu Wed Jan 29 13:30:29 2003 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0TNUQJH027517; Wed, 29 Jan 2003 18:30:26 -0500 (EST) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.3/8.12.3/Submit) id h0TNUPXA027516; Wed, 29 Jan 2003 18:30:25 -0500 (EST) Sender: Frank da Cruz Date: Wed, 29 Jan 2003 18:30:25 EST From: Kermit Software Support To: Peter Kay Subject: Re: your mail In-Reply-To: Your message of Wed, 29 Jan 103 18:22:41 EST Cc: kermit-support@columbia.edu Reply-To: kermit-support@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 146 > After some research, I have found that mm at Rutgers University > is *not* Y2K compliant...but now I can agitate for an update! > Go for it. It's my full-time mail client, and lots of other people at Columbia and elsewhere use it too. The "bug-mm@columbia.edu" address still works. - Frank From brennan@columbia.edu Thu Jan 30 05:42:54 2003 Flags: 000000000001 Return-Path: Received: from dynamic-31-218.dyn.columbia.edu (dynamic-31-218.dyn.columbia.edu [128.59.31.218]) (user=brennan mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0UFgq4x018018 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 30 Jan 2003 10:42:53 -0500 (EST) Date: Thu, 30 Jan 2003 10:42:53 -0500 From: Joseph Brennan Reply-To: Postmaster To: jca10@columbia.edu, BUG-MM@columbia.edu cc: postmaster@columbia.edu Subject: Re: send problem in MM Message-ID: <71868807.1043923372@dynamic-31-218.dyn.columbia.edu> In-Reply-To: <1043924221.3e3904fdc051d@cubmail.cc.columbia.edu> References: <1043924221.3e3904fdc051d@cubmail.cc.columbia.edu> X-Mailer: Mulberry/2.2.1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Status: O X-Status: X-Keywords: X-UID: 147 Fixed this morning. Sorry. Joseph Brennan Columbia University in the City of New York postmaster@columbia.edu Academic Technologies Group --On Thursday, January 30, 2003 05:57 -0500 jca10@columbia.edu wrote: > several attempts to send from MM apparently failed > please see sample session below: > > > MM>s > To: jca10 > cc: > Subject: test > Message (End with CTRL/D or ESC > Use CTRL/B to insert a file, CTRL/E to enter editor, CTRL/F to run > text > through a filter, CTRL/K to redisplay message, CTRL/L to clear > screen and > redisplay, CTRL/N to abort, CTRL/P to run a program and insert > output.): > test > S>s > jca10... Queued > MM>WARNING: RunAsGid for MSP ignored, check group ids (egid=25, want= > 31) > can not write to queue directory /var/spool/clientmqueue/ (RunAsGid= > 0, required= > 25): Permission denied > > MM> > From fdc@columbia.edu Fri Mar 14 11:19:07 2003 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.8/8.12.3) with ESMTP id h2ELJ3B9023798; Fri, 14 Mar 2003 16:19:03 -0500 (EST) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.8/8.12.3/Submit) id h2ELJ2PI023795; Fri, 14 Mar 2003 16:19:02 -0500 (EST) Date: Fri, 14 Mar 2003 16:19:02 -0500 (EST) Message-Id: <200303142119.h2ELJ2PI023795@watsol.cc.columbia.edu> From: Frank da Cruz To: Melissa Metz cc: bug-mm@columbia.edu, unix@columbia.edu Subject: Revisiting MM on Newcunix Status: O X-Status: X-Keywords: X-UID: 148 Let's see, where did we leave this... You guys moved mm.conf to /opt/ACISmm/lib/mm.conf (Jan 13). Of course MM did not know to look there, therefore MM on Newcunix didn't work (can't load new mail, can't start EMACS right, and probably can't print). On Jan 27th I built a version of MM that looked in the new place for mm.conf but then newcunix MM users started reporting problems which evidently had something to do with splitmail(?) and at that point, as I recall, we tabled the whole issue. Now with sesame available I'd like to get back to this. Currently: . MM works OK on watsol, where: mm.conf is in /opt/ACISmm/lib, which includes: set mmail-path /opt/local/lib/mmail.el set movemail-path /opt/local/bin/movemail (these are symlinks into /opt/ACISmm/...) However, strings | grep conf on the mm binary shows that it's not looking at /opt/ACISmm/lib, but rather /usr/local/lib/mm/mm.conf, which doesn't even specify mmail- or movemail-paths, thereby making mm default to /usr/local/lib for mmail.el and /usr/local/bin for movemail. . MM does NOT work on newcunix (e.g. walnut), where: mm.conf is in /opt/ACISmm/lib, which includes: set mmail-path /opt/local/lib/mmail.el set movemail-path /opt/local/bin/movemail (these too are symlinks into /opt/ACISmm/...) Same deal as on watsol, except in this case /usr/local/lib/mm/mm.conf does not exist, so mm doesn't read mm.conf, so never finds its movemail or EMACS files. On sesame, the /opt/ACISmm tree doesn't exist. However, /opt/local/bin/mm is a symlink to /hmt/opt/ACISmisc/bin/mm. Thus you can start mm, but its files are someplace it would never guess to look. Is this a mistake? Why should /opt/ACISblah not be top level on sesame? (I assume you're just not done setting it up yet?) Assuming /opt/ACISmm will be top-level on sesame, then it seems to me the mm.conf issue is easily fixed by putting back what I did on Jan 27th, i.e. making Cunix/Watsol/Newcunix MM look in /opt/ACISmm/lib/ for mm.conf, and then making sure each computer has a copy of it. They can all be the same; e.g.: set mail-file ~/mbox set mail-directory ~ set suspend-on-quit yes set suspend-on-exit yes set autowrap-column -7 set fast-init-file yes set crt-filter /usr/ucb/more -d set print-filter /opt/ACISmisc/bin/print set mmail-path /opt/ACISmm/lib/mmail.el set movemail-path /opt/ACISmm/bin/movemail and then for backwards compatibility on hosts that still have /usr/local trees, make symlinks: /opt/local/bin/print => /opt/ACISmisc/bin/print /opt/local/lib/mmail.el => /opt/ACISmm/lib/mmail.el /opt/local/bin/movemail => /opt/ACISmm/bin/movemail Then same MM binary can run on watsol, cunix, newcunix, and sesame, and no host needs to have a /usr/local tree (at least not for MM's sake). All this is assuming you've cleared up whatever the problem was with splitmail, which you'd need to do anyway, right? So can we set things up like this on all the Solarises? Or do you want me to: . Make different MM binaries and/or mm.conf files for different layouts? . Make MM do a getenv() for MM_CONF to find its conf file? In the latter case you'd need to add a definition for MM_CONF to the Solaris startup. - Frank From fdc@columbia.edu Tue Apr 1 12:39:41 2003 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h31MdePr016327; Tue, 1 Apr 2003 17:39:40 -0500 (EST) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.8/8.12.8/Submit) id h31MdeFk016326; Tue, 1 Apr 2003 17:39:40 -0500 (EST) Date: Tue, 1 Apr 2003 17:39:39 EST From: Frank da Cruz To: cyoung@plan9.bell-labs.com In-Reply-To: Your message of Tue, 1 Apr 2003 17:27:49 -0500 Message-ID: Status: O X-Status: X-Keywords: X-UID: 149 > Is this address still active? I'm interested in finding > out about the CCMD library, and this is one of the few > links that seems to talk about this. > Yes, this would be the place. For the current release, look in: ftp://kermit.columbia.edu/mm It's in mm-ccmd-0.91.tar. - Frank From Howie.Kaye@morganstanley.com Wed Apr 9 12:00:17 2003 Flags: 000000000001 Return-Path: Received: from pivsbh2.ms.com (pivsbh2.ms.com [199.89.64.104]) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h39L0GEn014070 for ; Wed, 9 Apr 2003 17:00:16 -0400 (EDT) Received: from pivsbh2.ms.com (localhost [127.0.0.1]) by localhost.ms.com (Postfix) with SMTP id 36C881EA23 for ; Wed, 9 Apr 2003 17:00:16 -0400 (EDT) Received: from ny37im01.ms.com (unknown [144.14.31.40]) by pivsbh2.ms.com (internal Postfix) with ESMTP id 1EE6F1E9D4 for ; Wed, 9 Apr 2003 17:00:16 -0400 (EDT) Received: from morganstanley.com (dynamic-144-14-35-190 [144.14.35.190]) by ny37im01.ms.com (Sendmail MTA Hub) with ESMTP id h39L0FS29115 for ; Wed, 9 Apr 2003 17:00:15 -0400 (EDT) Message-ID: <3E9489DE.8040306@morganstanley.com> Date: Wed, 09 Apr 2003 17:00:14 -0400 From: Howard Kaye Organization: Morgan Stanley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Frank da Cruz Subject: Re: [Howard Kaye : Re: CCMD library sources?] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: O X-Status: X-Keywords: X-UID: 150 Hi Frank. We just recently got a query about CCMD. I guess some things never die. Howie Frank da Cruz wrote: >>>Can you put the ccmd files back up, in /www/data/ftp? >>> >> >>I did that one the first day. But I see now that all the subdirectories >>execpt kermit have disappeared. How do you suppose that happened? >> > > I guess it remains a mystery. > > I put everything back (again) just now: > > [/www/data/ftp] ls -l > drwxrwxr-x 3 fdc kermit 4096 Mar 27 12:26 ccmd > drwxrwxr-x 43 fdc kermit 4096 Apr 9 16:08 kermit > drwxrwxr-x 5 fdc kermit 4096 Mar 27 12:23 mm > drwxrwxr-x 10 fdc kermit 4096 Mar 27 12:25 packet-drivers > drwxrwxr-x 2 fdc kermit 4096 Mar 27 12:25 pcfonts > [/www/data/ftp] > > Let's see if they stay put this time. > > Howie, note that all the updated stuff is in the mm directory. I don't > think I bothered trying to keep the ccmd directory in sync. > > - Frank -- This communication is intended for the addressee(s) and may contain confidential and legally privileged information. We do not waive confidentiality or privilege by mistransmission. If you have received this communication in error, any use, dissemination, printing or copying is strictly prohibited; please destroy all electronic and paper copies and notify the sender immediately. From fdc@columbia.edu Tue Apr 15 09:24:47 2003 Flags: 000000000001 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h3FINinp017473; Tue, 15 Apr 2003 14:23:44 -0400 (EDT) Received: (from fdc@localhost) by hazelnut.cc.columbia.edu (8.12.8/8.12.8/Submit) id h3FINiEX017472; Tue, 15 Apr 2003 14:23:44 -0400 (EDT) Date: Tue, 15 Apr 2003 14:23:44 EDT From: Frank da Cruz To: Melissa Metz Cc: Benn Oshrin , postmaster@columbia.edu, unixsys@columbia.edu, kermites@columbia.edu Subject: Re: Mail from watsol In-Reply-To: Your message of Tue, 15 Apr 2003 14:14:57 EDT Message-ID: Status: O X-Status: X-Keywords: X-UID: 151 > I don't believe there are a lot of people not using newcunix because > they don't know how to run MM. > I meant, they don't know how to tell MM how to find its config files (Terry, library people, ...) Anyway, a few months ago I made an MM binary that looked in the right place and was supposed to work uniformly on Cunix, Newcunix, and Watsol, but then something went wrong (splitmail?) I had to back off. Is it safe now to back off the backing off? - Frank From melissa@columbia.edu Mon Apr 28 07:27:44 2003 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h3SGRf2S007023; Mon, 28 Apr 2003 12:27:41 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.8/8.12.3) with ESMTP id h3SGRerS008476; Mon, 28 Apr 2003 12:27:40 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.8/8.12.8/Submit) id h3SGReX9008475; Mon, 28 Apr 2003 12:27:40 -0400 (EDT) Date: Mon, 28 Apr 2003 12:27:40 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz , Joseph Brennan , Robert Cartolano , Maurice Matiz , Vace Kundakci , AcISmgrs Subject: Re: Better spam filtering next week In-Reply-To: Your message of Mon, 28 Apr 2003 12:10:47 EDT Message-ID: X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Status: O X-Status: X-Keywords: X-UID: 152 > > What good is it if your mail is delivered but I don't read it because I > > got 300 messages this morning, and yours is lost in the spam? Maybe > > you can go through 200 spam messages in no time, but without spam > > filtering I can't do it. Even with MM. I think you missed my point: I don't need help with MM, I *have* spam filtering -- Spam Assassin in my procmailrc. My point is that we need spam filtering. And we need the bulk of the users to get their spam filtered without the excess cost of checking what their spam comfort level is. > Maybe if I ever get another chance to work on MM, I can parse the spam > score and let the user set a threshhold for spam, and an action to take > when the score passes the threshhold (delete, move, copy, remail, etc). We're putting this functionality into a web page that will generate a procmailrc, which will work for all mail clients. And besides, MM already has the functionality. I delete many messages a day with "take ~/MAIL/junk.cmd", e.g. key spam uns sub "**SPAM**" key spam uns text "X-Spam-Score: " text "(*****" unk spam from columbia.edu del key spam --Melissa From fdc@columbia.edu Tue Apr 29 17:56:35 2003 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h3UCuY6P026530 for ; Wed, 30 Apr 2003 08:56:34 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.8/8.12.8/Submit) id h3UCuYc2026529 for Frank da Cruz ; Wed, 30 Apr 2003 08:56:34 -0400 (EDT) Date: Wed, 30 Apr 2003 8:56:33 EDT From: Frank da Cruz To: Frank da Cruz Subject: mm set dont-type-headers Message-ID: Status: O X-Status: X-Keywords: X-UID: 153 Expand buffer size or max count for this, we need a lot more these days. From rossman@columbia.edu Wed Jun 11 07:44:30 2003 Flags: 000000000011 Return-Path: Received: from columbia.edu (pcp02173691pcs.verona01.nj.comcast.net [68.36.175.216]) (user=rossman mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5BGiSvd011961 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 11 Jun 2003 12:44:29 -0400 (EDT) Date: Wed, 11 Jun 2003 12:44:28 -0400 Subject: mm, ccmd and MacOSX Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Ken Rossman To: Frank da Cruz From: Ken Rossman Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Status: O X-Status: X-Keywords: X-UID: 154 Hi Frank, Melissa tells me that you are the only on there still poking and prodding at mm/ccmd anymore... every once in awhile I run across a real need for some of the things that mm could do with a mail file without breaking a sweat, and wish it were ported to OSX. Since I am using OSX a lot lately (probably my most favorite OS to date), every once in awhile I undertake to get the thing ported over. I'm back in that mode again now, but before I go much further, I wanted to get a status update (if any) on where something like this might already be. I don't suppose you know of anyone else working on such a port, do you? I remember at one point I had CCMD ported and working just fine. At that point, I should have sent back the code I had to you, but since that time, I've lost that code, and a download of a fresh source base yields many problems. I wish I knew what I had done previously... Anyway, since I'm back at it again, any info you might be able to send my way on this (in your free time, of course :) would be much appreciated. Thanks, /K From fdc@columbia.edu Wed Jun 11 07:50:02 2003 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h5BGo0fn025537; Wed, 11 Jun 2003 12:50:00 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.8/8.12.8/Submit) id h5BGo0oc025536; Wed, 11 Jun 2003 12:50:00 -0400 (EDT) Date: Wed, 11 Jun 2003 12:49:59 EDT From: Frank da Cruz To: Ken Rossman Subject: Re: mm, ccmd and MacOSX In-Reply-To: Your message of Wed, 11 Jun 2003 12:44:28 -0400 Message-ID: Status: O X-Status: X-Keywords: X-UID: 155 > Melissa tells me that you are the only on there still poking and prodding > at mm/ccmd anymore... every once in awhile I run across a real need for > some of the things that mm could do with a mail file without breaking a > sweat, and wish it were ported to OSX. Since I am using OSX a lot lately > (probably my most favorite OS to date), every once in awhile I undertake > to get the thing ported over. > Well I have MM working on FreeBSD so it should also work on Mac OS X. > I remember at one point I had CCMD ported and working just fine. At that > point, I should have sent back the code I had to you, but since that time, > I've lost that code, and a download of a fresh source base yields many > problems. I wish I knew what I had done previously... > Where'd you download it from? ftp://kermit.columbia.edu/mm/mm-ccmd-0.91.tar.gz is the lastest. I haven't looked at it since last October, but for starters try unpacking the tarball and then doing "make bsd44". Let me know what happens. Good luck! - Frank From rossman@columbia.edu Wed Jun 11 11:24:31 2003 Flags: 000000000011 Return-Path: Received: from columbia.edu (pcp02173420pcs.verona01.nj.comcast.net [68.36.174.201]) (user=rossman mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5BKOTvd005000 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 11 Jun 2003 16:24:30 -0400 (EDT) Date: Wed, 11 Jun 2003 16:24:29 -0400 Subject: Re: mm, ccmd and MacOSX Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Ken Rossman To: Frank da Cruz From: Ken Rossman In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Status: O X-Status: X-Keywords: X-UID: 156 Hi Frank, > Well I have MM working on FreeBSD so it should also work on Mac OS X. Doesn't immediately compile with that option set (missing definitions from for some reason) but I'll track that down and fix it. >> I've lost that code, and a download of a fresh source base yields many >> problems. I wish I knew what I had done previously... > > Where'd you download it from? > > ftp://kermit.columbia.edu/mm/mm-ccmd-0.91.tar.gz Well, not there... I've just downloaded the above file instead, and have gotten a bit further. I am not sure now where I went -- some other Columbia anon FTP location, I think (so there may be other versions out there that you may not be aware of which are confusing the issue???) > I haven't looked at it since last October, but for starters try > unpacking > the tarball and then doing "make bsd44". Let me know what happens. Right now, with a "macosx102" make target defined (just another "alias" for bsd44 right now), I get the following types of errors for a CCMD compile: cmgrp.c: In function `grphelp': cmgrp.c:115: structure has no member named `gr_name' : cmusr.c: In function `usrhelp': cmusr.c:254: structure has no member named `pw_name' : filelist.c: In function `whoami': filelist.c:669: structure has no member named `pw_uid' : test.c: In function `user': test.c:589: structure has no member named `pw_name' test.c:589: structure has no member named `pw_passwd' test.c:590: structure has no member named `pw_uid' test.c:590: structure has no member named `pw_gid' test.c:590: structure has no member named `pw_gecos' test.c:590: structure has no member named `pw_dir' test.c:590: structure has no member named `pw_shell' : All of this, of course, is from /usr/include/grp.h, which is included in some places, but doesn't seem to be "seen" by the abovenamed source modules. I'm just doing something dumb probably or missing something fairly obvious. /K From fdc@columbia.edu Fri Jun 13 07:04:47 2003 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h5DG4jfn020871; Fri, 13 Jun 2003 12:04:45 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.8/8.12.8/Submit) id h5DG4jhc020870; Fri, 13 Jun 2003 12:04:45 -0400 (EDT) Date: Fri, 13 Jun 2003 12:04:45 EDT From: Frank da Cruz To: Ken Rossman Subject: Re: mm, ccmd and MacOSX In-Reply-To: Your message of Wed, 11 Jun 2003 18:37:26 -0400 Message-ID: Status: O X-Status: X-Keywords: X-UID: 157 > I found all of that out already (sorry I didn't mention pwd.h before -- it > really is both grp.h and pwd.h that were "missing"). They ARE included in > the aforementioned cmfnc.h, but I don't see right away why some builds seem > to find these files OK, and this one does not. The files do exist under OSX > (under /usr/include), and the struct members that the compiler complains > about do exist in those structs. So again, that's why I think this is > probably something fairly obvious that I am overlooking. > No doubt some fascist #if[n]def in the header file that prevents the definitions from taking effect if or unless some strict-buzzword-compliance oath has been taken. - Frank From brennan@columbia.edu Mon Jul 14 10:48:59 2003 Flags: 000000000001 Return-Path: Received: from dynamic-31-218.dyn.columbia.edu (dynamic-31-218.dyn.columbia.edu [128.59.31.218]) (user=brennan mech=PLAIN bits=0) by clover.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6EJmve9003259 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 14 Jul 2003 15:48:58 -0400 (EDT) Date: Mon, 14 Jul 2003 15:49:01 -0400 From: Joseph Brennan Reply-To: Postmaster To: Misha Harnick , lindaw@columbia.edu cc: bug-mm@columbia.edu, consultant@columbia.edu, postmaster@columbia.edu Subject: Re: my files Message-ID: <15498415.1058197741@dynamic-31-218.dyn.columbia.edu> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 158 --On Monday, July 14, 2003 15:43 -0400 Misha Harnick wrote: > This is crazy: I have been dleeting files the whole wekeend: ssudenly, > though, ALL my disk is full, it is telling. AND -- it does NOT elt me > allow to delete anything from today (file too large, cannot write > anyting). > > Linda, this is maddening, and of course, as you knwo, even if one > manintains CUBmail, the maintenance from there does NOT carry over into > MM. What am I to do?/please help (mayeb give me additonal space so > that the deletes cano be done?)/thanks again,misha Pine is compatible with Cubmail. Hint hint. MM needs to write a backup copy of mbox. You always need room to hold two copies of mbox named mbox and mbox~. If you check quota when only one of them exists you get the wrong picture. Right now you have 5 megs free and need 8 megs to create mbox~ so you have a problem. MM cannot run. But I see some temp files I can remove... done. Joseph Brennan Columbia University in the City of New York postmaster@columbia.edu Academic Technologies Group From fdc@columbia.edu Mon Jul 21 09:55:19 2003 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h6LIt5ZT002742; Mon, 21 Jul 2003 14:55:05 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.8/8.12.8/Submit) id h6LIt55s002741; Mon, 21 Jul 2003 14:55:05 -0400 (EDT) Date: Mon, 21 Jul 2003 14:55:05 EDT From: Frank da Cruz To: "Vace Kundakci" Cc: "Alan Crosswell" , "Melissa Metz" , "AcISmgrs" Subject: Re: UpdateOnlineLearning71803 In-Reply-To: Your message of Mon, 21 Jul 2003 14:41:32 -0400 Message-ID: Status: O X-Status: X-Keywords: X-UID: 159 > All clients put X-mailer in the headers. > MM doesn't. Guess I'll add this to my list :-) Is it missing any other "required" headers? (I already added MIME-Version, Content-Type, and Content-Transfer-Encoding, but only when you specify a charset.) - Frank From brennan@columbia.edu Mon Jul 21 10:49:42 2003 Flags: 000000000001 Return-Path: Received: from dynamic-31-218.dyn.columbia.edu (dynamic-31-218.dyn.columbia.edu [128.59.31.218]) (user=brennan mech=PLAIN bits=0) by clover.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6LJnfe9027148 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 21 Jul 2003 15:49:41 -0400 (EDT) Date: Mon, 21 Jul 2003 15:49:43 -0400 From: Joseph Brennan To: Robert Cartolano , Frank da Cruz Subject: Re: UpdateOnlineLearning71803 Message-ID: <51878347.1058802583@dynamic-31-218.dyn.columbia.edu> In-Reply-To: <2147483647.1058802365@dyn-wireless-245-33.dyn.columbia.edu> References: <2147483647.1058802365@dyn-wireless-245-33.dyn.columbia.edu> X-Mailer: Mulberry/2.2.1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 160 >>> All clients put X-mailer in the headers. >>> >> MM doesn't. Guess I'll add this to my list :-) Is it missing any other >> "required" headers? (I already added MIME-Version, Content-Type, and >> Content-Transfer-Encoding, but only when you specify a charset.) >> >> - Frank > Some use User-Agent instead of X-Mailer. Joe From alan@columbia.edu Mon Jul 21 12:47:07 2003 Flags: 000000000001 Return-Path: Received: from columbia.edu (dynamic-41-187.dyn.columbia.edu [128.59.41.187]) (user=alan mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h6LLl5ss006246 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 21 Jul 2003 17:47:05 -0400 (EDT) Message-ID: <3F1C5F55.8010303@columbia.edu> Date: Mon, 21 Jul 2003 17:47:01 -0400 From: Alan Crosswell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank da Cruz CC: Vace Kundakci , Melissa Metz , AcISmgrs Subject: Re: UpdateOnlineLearning71803 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 161 X- is an eXtension header. It is by no means required nor standard in any way. /a Frank da Cruz wrote: >>All clients put X-mailer in the headers. >> > > MM doesn't. Guess I'll add this to my list :-) Is it missing any other > "required" headers? (I already added MIME-Version, Content-Type, and > Content-Transfer-Encoding, but only when you specify a charset.) > > - Frank From fdc@columbia.edu Tue Aug 12 05:44:40 2003 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h7CEiLZT026205; Tue, 12 Aug 2003 10:44:21 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.8/8.12.8/Submit) id h7CEiLws026204; Tue, 12 Aug 2003 10:44:21 -0400 (EDT) Date: Tue, 12 Aug 2003 10:44:21 EDT From: Frank da Cruz To: Postmaster Cc: bug-mm@columbia.edu, postmaster@columbia.edu, unixsys@columbia.edu Subject: Re: CUt-off : again In-Reply-To: Your message of Tue, 12 Aug 2003 10:27:58 -0400 Message-ID: Status: O X-Status: X-Keywords: X-UID: 162 > I think it's time to use something other than MM. Pine? Or a > PC mail program? > What's wrong with MM? It catches SIGHUP and cleans up, releases the lock, and exits if one comes. The problem is that when somebody's dialup connection hangs up, SIGHUP is never delivered. This is a problem with the terminal server, Solaris, or both, and it affects all applications, not just MM. Why would Pine not have the same problem? - Frank From fdc@columbia.edu Tue Aug 12 07:40:39 2003 Flags: 000000000001 Return-Path: Received: from watsol.cc.columbia.edu (localhost [127.0.0.1]) by watsol.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h7CGeTZT012623; Tue, 12 Aug 2003 12:40:29 -0400 (EDT) Received: (from fdc@localhost) by watsol.cc.columbia.edu (8.12.8/8.12.8/Submit) id h7CGeTJo012621; Tue, 12 Aug 2003 12:40:29 -0400 (EDT) Sender: Frank da Cruz Date: Tue, 12 Aug 2003 12:40:28 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: Mail from watsol In-Reply-To: Your message of Tue, 15 Apr 2003 16:12:14 EDT Cc: postmaster@columbia.edu, unixsys@columbia.edu, bug-mm@columbia.edu Message-ID: Status: O X-Status: X-Keywords: X-UID: 163 On Tue, 15 Apr 2003 16:12:14 EDT I wrote: > > Anyway, a few months ago I made an MM binary that looked in the right place > > and was supposed to work uniformly on Cunix, Newcunix, and Watsol, but then > > something went wrong (splitmail?) I had to back off. Is it safe now to > > back off the backing off? > > No, we can't back off backing off because we still don't understand > what went wrong. We know that users couldn't find their new mail > because the new MM was not respecting the splitmail configuration. As > I recall, it worked for me. (Normally I set my incoming mail to > /mail/m/e/melissa, but even when I set to /var/spool/mail/melissa I > got splitmail behavior. ???) This made it even stranger. > > Before we ask the MM-using librarians to get off cunix we will make > the new MM work. But that's not soon. Soon is watsol retiring, which > means someone has to show Terry how to use MM on newcunix. > Time to revisit this? I backed off the backing off -- which simply makes MM look for mm.conf in /opt/ACISmm/lib rather than /usr/local/lib/mm. I tested the resulting binary (built on watsol) on Watsol, Cunix, Newcunix, and Sesame, and it "works for me" (TM): . It notices, finds, and reads new mail. . It finds emacs.el. This change has absolutely nothing to do with splitmail, so I don't see how it could do any harm to replace the current binary with the new one: ~fdc/bin.solaris/mm It also has nothing to do with stale locks. Joe says: > Hardly anyone uses MM outside of a few of us. If she knew how to > kill processes it would be fine with me but she does not. > But with host pools, they don't even know what computer the process is on. It's simple when people use only one host, like Watsun or Watsol. If there were some kind of "onall" script that would hunt down and send SIGHUP to any mm process that that is owned by the user, I'm sure MM users would be glad to use it. I wrote something like this once: #!/bin/bash # Kills all my processes that are not running on this tty. function xxx { if [ $# -gt 0 ]; then echo kill -hup $* kill -hup $* sleep 2 else echo "(nothing to do...)" fi } x=`tty` if [ $HOST = 'watsun' ]; then t=`echo $x | sed -e 's|/dev/tty||1'` echo Before: sps -u $USER | grep -v User | grep -v processes xxx `sps -u $USER | grep -v User | grep -v busy | grep -v "$t" | cut -c12-17` echo echo "After..." sps -u $USER | grep -v User | grep -v processes else t=`echo $x | sed -e 's|/dev/||1'` echo Before: ps -u $USER | grep -v TIME xxx `ps -u $USER | grep -v TIME | grep -v "$t" | cut -c1-6` echo echo "After..." ps -u $USER | grep -v TIME fi Anyway I'm still curious why Pine doesn't have the stale lock problem. Maybe I could fix mm to do what Pine does. Also why SIGHUP is never delivered. I realize TCP/IP is supposed to withstand a nuclear attack, etc, but there's not much chance of delayed packets showing up after a phone connection hangs up, so the dialup servers should be closing their side of the connection, and Solaris should be sending SIGHUPs to all the processes on its side, right? - Frank From beebe@sunshine.math.utah.edu Thu Aug 21 14:48:06 2003 Flags: 000000000001 Return-Path: Received: from sunshine.math.utah.edu (sunshine.math.utah.edu [128.110.198.2]) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7PHm5e5007215 for ; Mon, 25 Aug 2003 13:48:05 -0400 (EDT) Received: from psi.math.utah.edu (IDENT:4zPg+El7Bb1mrWA1dcbmL5od8i0jAfx5@psi.math.utah.edu [128.110.198.32]) by sunshine.math.utah.edu (8.9.3p2/8.9.3) with ESMTP id LAA25713; Mon, 25 Aug 2003 11:48:03 -0600 (MDT) Received: (from beebe@localhost) by psi.math.utah.edu (8.9.3p2/8.9.3) id LAA25858; Mon, 25 Aug 2003 11:48:03 -0600 (MDT) Date: Mon, 25 Aug 2003 11:48:03 -0600 (MDT) From: "Nelson H. F. Beebe" To: Frank da Cruz Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: mm-0.91.0(142): build comments and 8-bit support questions In-Reply-To: Your message of Mon, 25 Aug 2003 12:12:33 EDT Message-ID: X-Spam-Score: 1.5 (*) UPPERCASE_25_50 X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 164 Attached below is a MIME-encoded .tar.gz file with $HOME/.procmailrc, $HOME/mail/BLACKLIST, and mail/bin/blacklist.awk. The former redirects several mailing lists into files that I only look at rather briefly, and only occasionally; more interesting list mail is redirected to my normal mailbox. Apart from creating a .procmailrc file, nothing special needs to be done on the part of the user. Filtering is immediate. I have logging turned on so that I can debug mistakes in my filters; they've been pretty good for a couple of months, so I may turn logging off. The one issue that we have here is that commands in .procmailrc need to be executed on the mail-handling machine, which requires a user account on that system. At our site, mailhost.math.utah.edu has very restricted logins, so the procmail solution only works for staff and a select few. Pieter Bowman has been working on this issue. His temporary solution is to have the /etc/ssh/sshd_config file set with an AllowUsers line for just systems staff; this prevents direct login with ssh, but doesn't prevent an end run like "xterm &" in the .procmailrc file. For now, we are proceeding with "security by obscurity", but that clearly cannot continue for long. After using procmail filters for nearly 6 months, I feel that they are much too complex for the average user: a simple filter error can result in misdirection of mail, or even loss, if /dev/null is used as a destination. With grep used for the blacklist scan, and a blacklist file of about 900 hostname patterns, each incoming message was taking tens of seconds of CPU time on the mail host. I replaced grep with an awk program run by mawk (generally the fastest of awk, gawk, mawk, and nawk); that gave an 11x to 20x speedup over grep. What should happen, of course, is that blacklist patterns should be loaded at daemon startup, and their regexp's immediately compiled. Then incoming mail for all users should get filtered against the compiled patterns, with the addition of an X-Probable-SPAM header to the message. That way, user procmail filters could recognize the junk much more quickly. For folks who get mail directly at the campus-wide utah.edu address, that kind of thing is already in place. We haven't done so yet at the departmental level. Message-ID: <25829.1061833209@psi.math.utah.edu> Mime-Version: 1.0 Subject: procmail.tar.gz Content-Type: multipart/mixed; boundary="-" This is a MIME encoded message. Decode it with "munpack" or any other MIME reading software. Mpack/munpack is available via anonymous FTP in ftp.andrew.cmu.edu:pub/mpack/ --- Content-Type: application/octet-stream; name="procmail.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="procmail.tar.gz" Content-MD5: FiyrCQv8lXFLMXLiaZ62+g== H4sIAPVJSj8CA+xc3XIbx5XWNZ+i7ajKkkoAAYqWHCZKSFGUwpiUtCQVr0srV/XM9Mw00dM9 7h+CQJy3Se3dViUvsFWbvdmXyTvsOT0DgJw5Q9tVSi62FiUDYH/9c/r0+e+Bx7U1acWlsum9 f9RrMp1Mnk4m9yaTyfTLp8/wE77tNJ+T6dOnz3bvTZ4925nAl+kUvk93pl/u3mOTe/+EV3Ce W8buJUIk4o5+0C3P7/2fe/3iF79g22HbLbYjA7bHG3l4zF5ZyV6JhO18xaaTvenu3s4u25lM nmzhqKNMepYs2BuhnNHsd2P2asxe4CTs13Gu/Yr7chw8L8ciC7/ZiqOef4JXnOiilI7BP86A Ym/8ohbM5M2fcQPMpVbWnnnDePAGiJEpV2rBrMikFamP00idmkrqgsUhUkNvJ2puuRexKTHX wo0ZO1C+NKEomS/XANNCZHEWbTwT19L5x0x6x5r5jV2wGljAHlihYPUrgbScHhyfvDw+YzKH riwzwukvGlJQED2bSxix/ZCdvj+/aOYcIxp7vHmxB/sWTjQorgrc1sZWXDV9406qDeWPoUPK A4w4ZiW/EnEa6OBEZAwCF2/fnY92JiPnFwq2JpzjhVgxwVimpBbuVxu2XoLGxGl4XQududUQ F0k3ASYuud9MAMx7IwARljmAVYYsXABdcZJcKhgZR3C9YCb2g7UKyys2t9Lf3MOKhi9cHMeU SWcuTjOXSkV+1FZcCQ2MFc7bkEau8zQFEik2VrAXdnBygmyUei0M24/G/trf2HMdPBIpKnyz opUc9l7L65ZvOR6CZw9WPFhv3z18zOY4iAOnYINzHU+n4aBNSyDQxXOoKthWexismXQzCTDx VF7j6UYqgLAswKaa40QKIz9SY22ovTT6MXAzYxw0k1npZm6zFeQpzhNFncdxDQdLnAFEEtVK I0XjT6ewn1b1D1SzX81B9ODolJkDKwW7qWYezQPIB0dubG21Wvf8/u/enh5txwNorEiwmoH1 WrMnE0koCmTQB1nVxnqu/Wcft07evn51fHL0/H470fZqwFiZIvLwD0dnL96eHz1fwKlA74MX 5xdnB4cXz8HkfOLtn7bWx9UilVHxUxEP3e1tbe1N9rYese/OQ3IJJmhv/OiwFOmMJUGC4gGt DiV1ay3oKaKjiI4QRblvyD0XaFnACjb8BR69PQNb4Pxeu8b0uwn77pU1FSzCZ0Hxii/4fmk8 suXD+COs0Ol1VqudJ0/3uVHjPvhCLM2VFJ3Wc5kJa/K81xn8S6ftNU8siITrNJ8ICTvoNNr6 MuOLfWBB5moLjOgRlLhclLaznft/fHn06uD9ycWftm4YEhA0G1D70EahQzp8++5b9EW+sTEr 8whSmaDvyARYtNDY0EwoEFhwFFFk17Z85WCiWQOrDu8mTYNtVPLl0Yv3r38LL/Yde9TuaONx gVb0ufABXjf235uwdK8R96PTd2/PDs6+3WNnwNfgo644YIBae7Wtzpgfl6abfvQOifrkCpAh 6xwIfuQ/+AljQVpEhlHJioMrO7G1Hom6jXLMvIWITqbtuTghwAFUFQQH4PvV4qaUPzg8/OHC PERpOrg4+tfRyT5O4IS9GgctR6UAKVWJsMU4E/0xF6kr96vrcTG/KWUbXFQ8dSNwXODrPGxo v9BhbGzR7wlAXYwy8HBqP36nu1W6GCGB+2lq0/EcfJzCCKzfEYhPTSb228/+bD+0J4+dG2eF +x7u48V1ya87yiaTitD3dy9fsW+MVdmqfSNkr6wQGM/1kXfW4Df2GiRXI8P7Xc4Pd3a+eT3d 7SMpr32wojm7cZ3lS6PFTco2XeOR9JsrAUmA0b6PvLl4PUoBEdcECEvBmf2UdQGEKfrtTqlQ jCpRwZ4JulwNUu1HfQAmG4EbU6KCmMhQQ7EHmiASoYGlkkkjhLcMYs/zrL6xg8NTdl5DPHce qoqDsRuxxlzxtIoytzYe0DBy0LMxGu2MG3kFF6MzTli5zQSxx9DwkI5gV/suaAeB5Tib3RjY YLdGtpIq5kLMRlLnJh7aekhsvznglnaxAkyg2Cjr7Y3eAAeIvSWtsM1WblpPtDG3Tbdbk2yO 4OjsDLz22REY/QuWw3bYtrjGqGa7NJXYhux7d3s+n2+nhRwlUt/Ym7XGjqzAvhRPji/mqLug 3D5+6ZLVNt8IJyA2RcsLLjJjGA6j2U0hKgYX1AYW7IHUYAB5hr4zEzkPCoLzNy8fRrRxfcDi PTYXsiih+/PnbPqQ8SyLvtXBCjEOB5tvcbbJQ/ACPi1/hbkWOtdcat4E3mmoQhsrNsPAh9cG hAJaHse+oMyQ36JviXOgd8GIOmZ/jUPf5B3o1c0V7Kt14hBVQKrpoaH1QuMtImb6Pb/i3zRM VAsI0oGFMivgXQtPdGXHOgNLbjHhnjslPLgK0PyFQ7vTZf8lDKCO7YQnJiYUC3b0fZA1mgX2 ayX2RRvlKJ6ICPCimfM3m0nVevBIrAYPyN2b04N37MHBydHZxQ/v370EpxlFuuS6gIx5PaOu eD0g/mqhr1E/9p1c8WRDCGADw0wtIol32YhVn4EpQNF+TOmgeXjw2tTfOR56UQd0Jrw1GNh7 CFKN8fsZt3OJ53vHhuxmUJcqnLYlzbqFTlsn5HiV8NsWKcIUSdeVutxv5ey2AQRkdGkgg+Kq ZwY3svDgw9/++vHD3/4M//3l44f/+O+/f3zY7/Rf//6f//PXP//l75vJ0Q2MZqCbvDd3S9iB 9eydBWVkB4XQ6aIDn2LW/OgcQvCREzNzvxuVOAOJ9s7O6LIeP7rfp4hnaH5QsaXo+U12wCAa g7DyPonMRYIOhgBf/mGPWI0dnJ8fn18cvDk86mPJzVxnQ99nn33Wb0SWnHI7E57GzrkipkoE D17mQbFCWkitrRQ6o+InSBRMvx1yAl5fWFnDQUibQyZOxBmHJp31W4/AjtpovCHbXJhARGLX KXCSIa/7YB60XtyJtSfRh8tQgeQOjD0+Yk/HEyzepWUf/T2vucbMTnEHIubE9YLVMkU3TGz8 ayWW46N++wmH/IFdgHWw7JBbb8H4E6ScCD/GGkd7KsQCJwZIaVwiFbE25bzo+785+Br+sStp gwMH6zGSBsX2gohET8HxFzjyxHBNBOJCf5Bq+pGgBxKZpvKKzjOzoSD6nF+cHR9enHy7ffj2 zavjl0dvLo4PiF7BgvqjxepjFxbyaHZemjl7AXaSOKb3Z69hXgwg2I1VTgY7Hr/5l/fHZ9/2 8WALdJMQDKlFH/0WxehE5gIctAuW67R3is8//PbjC1l8CR8UJCD0nNmfC6K6WCxtmgDEPfrA R8uPP+GNUbbuAhzzDCckTMqZ2GNxj7yGLKOtp5G9LrCIW90s4tzGX0L2JJWjwdMFSiSNx+Wz u0Yf1LXFCKyPfiPTGQRiIJGQ3zt+JWzHxSSKp7MYYBK+LzpueJt1R6UGTmXIMeEogkcJiMD4 0fM+8PrFzpPpDkKdRfRAeIWFguvFctO9bRgISjDHa0vNI57BgLuio17nOybFXNj9tClvdKUY HSPcF2Eh7BcOsnuZCSqY/aRVpFeYDayLqFhB2mNcqbacjvayNBArxeQDJEhq9uLk4PDrE3DU kC401TssQDVgLKa3hTSsOe2tbxtOwQyCT2bTCZtO93ae7O18GS/R9sCiNGnD6PrzC7P3+WMc n4qYQlyYWMFp7oWaW5P2ticmULAasEiD014wFBX2QIyL8WOmRAFJS4VJVVtlfRynaMuYsYFB htSCmDthACXcw0huW/lb1f1+29xqADuAQjyoz1df9uK3c3BIwsL3f4sD8AWtZ2gnR7ih5i/w i3r0DqTjVscfmCjAorIRZF6jnN3/Y1tY/9P2msu364qUsmIHXI4D1+Js8fKsCmnJco61NDjM +Wx1ndSK3M/Y1U/aUbOb7eDsNt43qG1IpLfjuqOrjcg8/5za4uedvePQzR5hjjuN1ae4/0VG bOj5B97/7+4O3P8/3dl98gzv/yeTL58+ne4+wfv/ncmT/7///2e8PnyHUcF050mBRVcQtFiH 0Ln58N0Yka11B6xq8CaT7WFk89M7miGfv928M0011b1tp/o7H7IFOWa3XDnuy7oDDay+bkbX 3cEgh9AhpvO9lZ483SGbn02pVZ48IzsXhmxWIveQepJYW615ggiB72ZoXMWSxHJARmEG2HJJ svyrCVb9SOSXX/1ylwL4FF6/xCkhSjQkzRyIVopEuEqMLdyigiBBGshe0XRDz2zW6ZjEZp5i nNHDpCf3y1MNDrQmoZX3uwOkIaHqMipD74wBuxYpPao0qdFOSJoLWeAapyzMFbwnpgsvQA7J gZAZpnxzS9lBwfMh08owAu6pWErKRKePRKCtUsG7n3fwywXW4Ba8NKSo8plMeEMdnGMHUzwB 4vDEHGk9OF6c+QGo4PZKlEGoq4EOMmkqpwSkvFDkCanK8uDSkh7mOd5x4XKuy6ZKovTFQ+Ad SHO9lCujs+yhBQhM6jbZRBdfSq5xuOzSauhDtTnOo1W32Y+MvnGUPRSvLKMO9bkCZ5BlMsX0 bmA0Dz8NpeZOsChlB4ZCGz5JJEP1UzpQ02NRc7M5agoMmoYgMzysisW0AbAGxaNZ7bKcPjgn IYGukoEzcLSD5c6ZFG+lM285nK5dS1LPCjoPcawAmmlbiDCaGMUH7agLoHToI1Kus4XzxtJb 9Apng4QaN2pDF60p++19IunJPMmPgA+04fT08eB1CJiAYdsXKNKuQNd4hg+JYcGOHAdd7Mr1 ImHLDr7Q5DklO0kK09KHm/CssFbRkFRckaY14TrP3UyCuTK0LUi44XrtNrrBC+hd5gguQLtd JAFvtoalKUmHbElTMRZ6yKIlQilnQqwI9Ld7N6hFOhOEdUtEc0NntMhomlr3Nox0HV+Sz+tA OtVEFrkxfgCqjc4GIAtKahaJuaZxMIL4RBMJKrlcwnHRmMGLbZJhKoiS3gMgK9Uo+9DC6BUl 1NlDKlvgMcg6XmR1V10LI4Qq9udgmisM2sv5kAWCWFBkQyqdgAjoki/5AEjqcxLt2TBNVnqu NQRR9GAzRyWKCkhPD+FCKw+UKtBCFNRMDG4ygIKU0rvUUiFVErBORA9c1HyQkpSDbumCGgjx o7BGV3wxgA6JCTgJrnam9Cgd0zP3feCNoe3JbsrrGdf0YDto1gHLWv9G7tLjs0y4Hrh1uaRD kjRZh40gi91NiZwPGkW08LaJVJZdxI7oxYTVhBKmJWwyhSiV3iWgyngvTDIc2ID5FjYPAxPg o9Wc9KyAaS5bBtPowJT1M8IagG5AJAQia+k0GXAFfppmTmkGyLf4PDvEzgHUk1SEtAyY+NAC BJ5iSa4n/aJ1a12nmMrloMxdZhCdVXxQ6hTpJ8GBpjNoBXmUhR4eLK8prqqQNCWJ/iZUuNS8 NtFk2U6qmALCbaS1m0+kmmaWUaHSAxEyNKTc0WSYyg2cHiBYnlkVKKhdmyaaJyGwxotIjeoh Lih8KJte1cwgbuN4tTuAKzDm9FEZmzRiT2zTWmEG0u/UuMrURlHpW7ybsyBuuaDnDY3CgAPx 2KPSMU/u9przhQWrw2lljaFGv7lOQ0EqDf78xaebQKOf76cW4n7IhAWdI6dusNV4HqtZ0bF3 w+bUY4QqutsLCQchihqedhUSInyTgQ3ABDD4VajaXRkQ2m8tIPJDfSdykYjh4w5uEDQuDM7q BT5VSTIe4fnakcLhdg4gwyviwoJ3hPyRDBOhhzOSRjyHxiYrlbQvxz74THuUrN7xZ5xOorM0 J0xQltaj+CMIUskzMlbNxGjOPe2vMsHzGjJUMwS6EH+rQ8MKi61XTqt1rVbqXp/4OP2AU8gG fG0mhihCs+1al0AYKugwm9NBEz5fcR2DDF+imdSj1OV0xyswd6Q9y4piDsEGCclLcItqnW8S HWpMGmiHnF3mM7LdpM3hRLPcLZ5npmiM4Nx1geFoLbNgEnQOIj2AVnO5pCFxN0baPUCGBxkP KWSs7ZUdS5OFZCB5RESR0Xa2oCv3YpS2WTcBFUZlNFLLwegCNeqK2q0YLUeQl5BnKfCSeXBG bn2pGgvSn7UF6WlvgMRIt4i2B8EOi0XSKEqnOApORii6qijSWjWpXn+hLMWnrwa3l8kcZJLW 9vbnn98H4+n6DzpIvPsfMLBCJrEiR2MVmemI5hF8NLEq0IsqJ4qgsyam494XcqBfSGcLiO3p ZFRU0wlJwJB+3gT6ufEKreZ0ezf2BLfIB5ap+QDBNRyHydOB0ofQ0Rat69pdF4U/bEgN8DdG Z2kHrLm3ZCqDxSRPlITik82ikqk1EJWE+LM6crytwP4WgsYGKgXCLYUnV/VGF9H+JLITNYlw l3UVwZovKT+PQE1TBw6yoULzK9TISnaC7OaZS3LsBiH8A9580fu+bk6ha3XFEhTRBkkmF4Jw NDkHWXFBXtExfPPQxxCvEAX/NQwvB1xpnum1n+0xOheoN/gLKl7VhAblovGZV4GoaeZSVYmB PJ1eN1bKfEfFcsg1DJG95sabSkBEYNfaXHeXg6hzJqhKaA5ZQSbxZ08kIVaI3QFrihhfBW29 /eE9QskHBw6exW1sjKX8oQ6FMglXbiOxxBlsepfERPGH9wNYmA3RB+15f52QDapH+wSvwKfr SElq8FLW9JI30J6ytOjqtzgEbqqR0IXidOUacO2lsFjJAx0bigBX3QbKEiuYxALK3dBjHnlw ZDaVz9Mb+XG8VOvmx/gId0InwQX+GCzhIIHUmgXWETWtegV3WNlcxP9nBN3BkwQXQge8ohPz oRiwEAaLU2IIVKYYqMQUwg3m7IXwNZfZrqmlbn1Wj1H0oRWxMFWmg/l+UU7j/ZICbpXGOtL0 FpK7VE2mP5ahFXKpZAFpuZgpWlCKS2yu+UyvL17hz06GXlQ7E5IMOisodDESGZlIDQXkhbll gALvwqaga350UlBQJruw3NNRHj6+87/tXUuT3La19lb6FV0TL6TYHfWMpXGcxLfqKlbZXliu SsV3o6tUgSS6ieEDEAF2Nyfl/PacA7AfQ36n5aSSLFLDzUzzA0AQBA7OG23Hsqzeu9EPJZKw pWNJxZfCtO10GrUpZSLAlwrzppvO9tHI03i4NjfCTA9Ono29avIkbM/rxci7oiXuOm5FUzeL TY9q0SZSE+uLoVatsdNRmVRHqh0EtDDLvFPrIMA6EvJpDwmQVOcJ6oTmGglxbvC2l41IsUQw DfGJA35RnelSerCu2MOhjiF9042/FFQiNMEif/vF7SsIm2pQVY+hGKioWu4v7qwRXHNKXvMS T1Da6mRwnm5MHM6KK7WbymI5jmhZy7lt/B5IDqUNGbb/RmQPVjMBOSekAbLvgzQSEgTac9hx 7SKytYJXShnfR08ngN1ipq/E4kPpo1a2wV+2b1Tb7wWI/ZgzQ5tugQv4Uhoks1zHyBqMYYpr spxmE3FEFUZpD7JQFWqy+oI91+QfxF4WWq/NHveyaJQPJ3v7rNkCzACzNtFCjvTmZtNGZ4hl boXeVLbCmiFDLAbYIwznyYDl2fNXXM2E2tN2X8zA3ju9F1+bquWCZGHatdqPY51UNtKXbteW 9hKsTDcHWu2rGWDaQpQZTMsGoYCb5NxSrM8Zo0ckbs6w0Gho4woiylPUdMKwh1KXtvcSau41 3LBNtMlNjVHG7oXirkbiiHGdaXovimAmrgPMw5kuKnuST9LUAGKisDV/nncbNSig4jHB67yn /Wg4hqXPC9S1oK4zYRdH4yxPwaTATg2CQGOYfMT4ElTxTmXGY9XlHceIQkCbOncYCQIzeKeJ 6R5Q/+5qdx039ca2ksPC3dk0fwik0G1xYd/ZQaJ0d12A9qm7PjPmoFmb9qNv4erl1Br0feES qVS0q2Y6qDHVD5o5lQqigqzS2OWwStrY6pptSjsFxKWqXPZRJc/Powk0UW1UpjBKNOlX5mhR mnPHlQnRJjnlOSozEBO4gQEYVXWyaYEWkw9g0AruaMQBBVXFhEWJN5hygTHO/jiE6H24ABxH AjoJEVZVZXfqINwBXq7qBhfil86m3fQHWq51cdxzZoOxU3eq1qZdyl6TnOdCfNlx+5/uxrVy uKlw3GPmINvtUVsxs4p3qgsDrue609ybLul6k5caOkvXzNdYQP3ZB4G9FPLBC7rd2sS1Np2U tWm8AdxCbT70prgpcFNbbTwPcS08aoedGWoaegsBS1wGJKiEkCA+LO9si8lYbbu4jGcvYHvj jWqVNA/ZL/wk/sznGeMqE94w0scZpYq2G/rolTj1+r7CYtUhBAJNhyHH4u8JQI86B6UmoRaw ueUJ5sUF2Kisg7NaUC/Trs4JyDBk6uWGKAx2+GH4esWBRyMnxjfsei14ijB6s1qtxE/KBSQv /JjLpxP5RYZHXxNYVTaqJPQCyIlbWxGUNHIM3iFHagYacycgjh2UpfZOO0jj5yjdpo+xim4+ sPrF+yBw5sD8R6vSh0Z0GT6UYwG8AUv9YCnAt9vMRXPY/R1woD+UifUtG3KaPSwxZVrH20LU U0PbsbUZhmrknEjbv9qp0OMq7T0kmxcdhWJiKwEIVddL02pQKWmIRFiazO6ZanI0/LkOdyoH NLk3glMdZ2EksbDpI3dKjFbUUQolO+2t4HhKKEetYXV6ozdK+ngpbQoP6W6H6+4lipVMx1il +BGwLWrB+emUqRSjnK5NF9LW3thCdVEIn9rrG2uPUhyo5gnh5NkYDYk7H0lpN4O1J9GJuE6k 5Y15Qi5GHTZ2gK4fjaO1I5gqGmcEnrPpOH1IzVlyYEV/zY7NpVjdX//2Mv7yMiwym4LSPd0G DXFhF9VCOOKnobGhat7JO1Xwt1+w2MMZZFKkF/78wWdudf0yeQoQpxRO+rR5x7aFx/T9sMQR fR9ermCQeDO0WGfSDCTpQze6dhmwSrRVBt8+p03TMSLUqsZ2Qs2+hSaRVpFgcofr4JXZqp4p emX0FhiZWiX4/bf5yHjOu6BJMjCqHHNeICa01ezld5mGUxn2J5DhoBwebdbnOaFrITrHRoIu 1NUK7zoEGaxQIeTg1Iee6MfeoHq/BINtYjUkI5dchtLqwToowu6T4HYBAn3ZsRgprJX2mCcy GvcubT1UNHBCrbNJMStxvyXGEPcwkiNPxGQkfxO2kpZSoSQLDYGANWstp9vCnrWtDURoN5wa DMI+Jl/ghABaKBCEhc3tVjJNCHVsujAbdr2N1lncTC1/52BF75x212G3sXbIJe4ZGzbt2qD8 CbZsho21RSswGbbKVNGLsmk0JkzZUo5LjNoq1F6jRMUISetSSHZy9fNOYuqOroC+BPufdbqN oU8geoSxpBMaQ9bQW3bF0ublMjN1sdVj9PeUe6HZScwEHvtuY+BitR3H7QUdjf5YlxE39KYu hAXtVD5ahFKBKUPtFGuueuTfRdCGg7WXgjzi2Lq2tQJUqE0vuGcSiicTn1yxsa2jdSzl0Uge oY02kgbGEdtRG1m17fIzqjLnIF1u/ABdHhzRRI5EBRyxo02o61R2sP2AKeJK4oXowdLcJib0 ZS8Ask7dcWRzpCjT2eaM11CvSxSSN8bRjgQUpqmAF5y+mMAKwYOcUFyYhDa/j7utTQWmVMxZ 6lGOa9bDMuMMBgIKX9E6ccCs8wGzrsk6Hmx1g9ExomVqC2eg3yQtklTxDHezvqYM0jHChdc4 R/DhdgSGhQF2hGb/ei/VbBRmwZ0g5zoacnYP1NDs5ro8atWj69bUBkJLtzF94yV3FzYRammi dEaw2McIgWVkOLCejgpsiWHObV3rjb5U5IJLIZe4ME0PocF4hXeWdvkBv/I5NFcHMW5DoIlA UhoKChw58wZbTl064WBrB41jGKmATyIVqtvT3iEQ6s7uDWTtnB9GX7spw+Dw0LMHGq/wHe+/ KfdAC4r4cqeFGdnnYHd2u1L5uHvlaq1vYKIpN/TtnUEv/yFPrqtwe/vQGbi3feg1bUK4ytj5 +YNQaZrLpoJbDe+CSuBkuhS+m1c7wQuLedyloFNgLAxqkwyZCHauHnq/NfgFO13oQWedsDlw mOh6LVFCogv59fXRgBozI02JRxcTJV6yKvKr+wp+TlokAnHorG2gRN/1rZB3o0OJYLzS2dDX y5NpE/TQ024VMKPnOWeCkDSCMN9jXZ1PXpgNdgLwzDFD6u7VIG0nPjecCxSvNZ/jUNKzjLho W/CayC9e/wQNtgdqdq9rdtJJQqRQdT+wMaOH+4IvVafZqgbfn2SzzGAR2ZdW+498yNK6te3O LMKokFnjT22aJiXoQpDvg3VYo+GFRApn9+fEk/Xmygl5lz6mVGec5N7l4KTa+L6XOhq0Fxx5 fdWXS650N70/ZALh97Vp1krCoNhEvEcXct2F9G0wvmXvYAEuVE6MRoM/bJymKp/eDY7Vkl8J bqq+zUA6D08UK1p9p2yhtySlUCexTEDoP3gfy46cHza3MDgkuhkoZzCf5p2praShJbBdm1ZI WeQ5ZBECQWWdTSkhEbheR3ENs/zM1OelXv9Cn3cuXlusHGRMVDcewn5aO7s/CugkI+JpE/rC 2Jdf3dyIyiLfGx9VmXPK2pP0WagC5ecYdWiVwaEjBBPfijWkRIWCMDN2mbSCB976NS3IQ7Tv 9POfHy/zEAqqbEyLOcqgzE4Jtaoo9Ndhep89ZUSLJMM7g9WqNLP9MagWEPUQ3XZmnyFolQsz iq1LonDPoNESwidDCNXqTMUxnkoihBwMYVMfX4akXKyEWcnfgLDeJ9kfffYgdbHrlDihOcX8 Da7mw8X76JusIa8cSmXWqjGR4Zp/sVIX9FEGYtq9pEELFz5cqWNeCk4CI3z3mJmRqNI6Gcfa zZi5Zd4V4/Nk/Jwq2kLycaFlCvQLoYXG5GCrwWLAJQbzF5DB8EBRQpvadMijudZrSZcWXPC3 H3Ot40JffrQQC/aj1JL5IsbvzUrwyYvs94P3pNDptrhe4Riv0JmY5AxnheRTf61EKryQ/yz0 LfuCiVOHSHbcI0dpB0XX9dHHbFKxP0VvzRrt25fEMAQ25ElRPSzQYGrP8cYxkct0/vWt7zM+ fyXjelk/cEoGaRn2Vp4vvSuOIY5s9E0peAT+sXfyWhc0zun2jAT0PuWuxuPh5ehuxmIuJdt3 uSZWfwPFiK3eKB+jwL0Q7b0Vvc0u5JO7BMWIXSEb+raJR2JAaIyoyOAWu7WmRl6NWxt0yxkL EdnacebTmMN5Wo0qMMHqcndc1m4ys2jQlhcpDBUYLUFrM0Oi9xh6kYcR+XNqQjh2KDsAswHf cSj7OE/BfNxpOb3kTtd076B7gpXZoIGfSvzeXvJQ29FKL/smw0NA4qtgSySo1l4wnRJH1AoL kmNKCgyQwJSbFmfc3pkg0qudtQWxHCXGuroQd96IpkklZPqNB70LLxkanUNSscOuWek2+7XU 8WACU2zRtIqlgtat0V5DrdF+WWs4uHuVcllPNUp7Wnltp/HAH7OnK+G+WOGfAuZZLR+iU73B Q3Q6WicUrIkHYC88dS1Umtq6BtXgVyMZFAVdDiTa2J1Tgplg0H45njswmz+EEdKoTty6BitN aXad8hKww4ECQ8/RqMvE9RicKeVeOagF+Yfvs2IXPoCzXRQY6Yj7jXLUlKm4Ny6zggH4Xohe vbeWE/9jvfa9F5z173cKhMsR3fBnP84UZsD78MFnfBCK+0A1Q3Xy8x+7sx8nP6xP/tuveP7P 7Nihf8P5P7fS+T+rm1e3rz5ZfXn7xRe3X75avbql8i8fz//5D13/0iPV/sSHN6vFcSrFk9D4 NGen2A2tjec0RyVPPGS5ZZxP6fKBGLZ0UpknOdbxQdG2Hc9s5rOcYx2+OzYUz2LmmAm+Fw/9 UosxdWQ639kWOh4AbdaLNSdWSKc3W2qxIw5IH+qsafb3nR7LXz//fFGbKp3sfDiejE/oOr7Q Mr7Q0v/meLrbn3XME8eHtO34YDY+AzGUxvOJ0tfX/L43q0UMsTwcSUZF2sW3b3+KJ5bFNvjM 6mY4O14uPiV28avVasEJp4lJOT3zJ/ZNj4e0PUHnjJ2dLsYNPRsPd+Oa368fHGIXz5TzOny+ +PS7H3948+LhYWBcQHnfN7pIh2+/u75Z/qC6JScWfP+vO4zv9Ztvv3/75K9Pn/BJavTBnp16 8PXXi6ur50+fPDm7tXjz9v++/9OPb99dcZ+v3i+uJv2+Si29fU1lV+n/HTuELZ49I4GbVW2L P5yG4fnifxar56kY9eEJd+DT1eJvixd/ebf4//D+15++4A4wnHN2o7bX9JOz9S3Oiv7qN7/G BV+/++yzt6/fU1eCJUZFd1RjfNrP6U9ek4x/eucRjD4Si6tv3rz+6dvfxXe5+pz/UG+vXhR6 +4LWjO46etefnz49DB51BjyHvtPD1mKxd1f89+r9OFo8B59VdP/694tq8Yev6Vm/X3z2WXU2 MrN2XlMbFTWRWnv9rnrP7YEuxkGNa5h69TkXfM5DxY1yq29aVoKkZUMLptBZv0lLPh7L6H8X h3X+/B/+989//O7NN8dXSUvmvCvznjxJx7kX/Kb8k4kIz5InPx8/ys9P37z95nw+jlW4y4fi cFzf/pi6BJ7L5WPda27/k8fr8Xq8Hq/H6/F6vB6vx+vxerwer8fr8Xq8Hq//3PV3T02nOACg AAA= ----- ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 110 LCB beebe@acm.org beebe@computer.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From beebe@sunshine.math.utah.edu Sat Aug 23 10:19:28 2003 Flags: 000000000011 Return-Path: Received: from sunshine.math.utah.edu (sunshine.math.utah.edu [128.110.198.2]) by blueberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7O0JQGC025198 for ; Sat, 23 Aug 2003 20:19:26 -0400 (EDT) Received: from psi.math.utah.edu (IDENT:EwCf8Xew+iovGZAKAWXGi7mrx20DevNV@psi.math.utah.edu [128.110.198.32]) by sunshine.math.utah.edu (8.9.3p2/8.9.3) with ESMTP id SAA00510; Sat, 23 Aug 2003 18:19:24 -0600 (MDT) Received: (from beebe@localhost) by psi.math.utah.edu (8.9.3p2/8.9.3) id SAA23618; Sat, 23 Aug 2003 18:19:24 -0600 (MDT) Date: Sat, 23 Aug 2003 18:19:24 -0600 (MDT) From: "Nelson H. F. Beebe" To: "Frank daCruz" Cc: beebe@math.utah.edu, sysstaff@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: mm-0.91.0(142): build comments and 8-bit support questions Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 165 Today, I downloaded the latest mm-ccmd-0.91.tar.gz file (dated 5-Oct-2002) and, with a couple of hiccups, built it on Solaris 2.8. gcc-3.x no longer supports varargs.h, so I switched to cc, but had to revert briefly to gcc for compiling set.c. I had to remove a spurious semicolon at line 508 of ccmd/cmfnc.h as well. I then proceeded to test its handling of 8-bit characters by doing a file insertion with Ctl-B ~/ch256.dat and mailing that to myself. That file has NUL deleted, but otherwise has sample characters from 1 to 255. The incoming message got truncated at the line beginning with character 128 decimal. I then made ~/ch255.dat with character 128 deleted, and tried again. All characters from 129 to 255 disappeared from the incoming message. As a separate test, I did Mail -s 'Test of mail with 255-char set' < ~/ch255.dat beebe Mail -s 'Test of mail with 256-char set' < ~/ch256.dat beebe All characters sent that way arrived safely in /var/spool/mail/beebe, showing that our basic mail system is 8-bit clean. Next, I recompiled mm/more.o with -DMETAMAIL and rebuilt mm. The result of this is that while the TYPE command displays an incoming message with an HTML attachment, the DISPLAY command shows nothing at all. Should I expect to be able to send/receive the full 256-character set with this version of mm? Should I expect attachments to be recognized, for both incoming and outgoing mail? ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 110 LCB beebe@acm.org beebe@computer.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From fdc@columbia.edu Sun Aug 24 07:34:15 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7OGY9aM029733 for ; Sun, 24 Aug 2003 12:34:10 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h7OGY90G014605; Sun, 24 Aug 2003 12:34:09 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.8/8.12.8/Submit) id h7OGY9na014604; Sun, 24 Aug 2003 12:34:09 -0400 (EDT) Date: Sun, 24 Aug 2003 12:34:09 EDT From: Frank da Cruz To: "Nelson H. F. Beebe" Subject: Re: mm-0.91.0(142): build comments and 8-bit support questions In-Reply-To: Your message of Sat, 23 Aug 2003 18:19:24 -0600 (MDT) Cc: sysstaff@math.utah.edu Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 166 > Today, I downloaded the latest mm-ccmd-0.91.tar.gz file (dated > 5-Oct-2002) and, with a couple of hiccups, built it on Solaris 2.8. > > gcc-3.x no longer supports varargs.h, so I switched to cc, but had to > revert briefly to gcc for compiling set.c. I had to remove a spurious > semicolon at line 508 of ccmd/cmfnc.h as well. > I don't think I've tried it with gcc on Solaris. Obviously it would be nice if it worked with both cc and gcc, but I don't have much time to mess with mm at the moment -- just for adding things to my to-do list. Even though MM is still my one-and-only mail client, and I was enormously pleased with how it held up under the recent storm -- It took in about 50,000 emails since Wednesday without a hiccup, and it let me move bad mail to archives that could be used by our postmaster for analysis with a simple command file: ftp://kermit.columbia.edu/pub/mm/spam.cmd See: http://www.columbia.edu/kermit/safe.html#umail Anyway, if you have diffs to make build with gcc that don't keep it from building with cc on Solaris, please send 'em! > I then proceeded to test its handling of 8-bit characters by > doing a file insertion with > > Ctl-B ~/ch256.dat > > and mailing that to myself. That file has NUL deleted, but otherwise > has sample characters from 1 to 255. > > The incoming message got truncated at the line beginning with > character 128 decimal. > 8-bit characters work only when you: set use-editor-always true Otherwise the message text enters "ccmd world" of the parser and gets its 8th bits stripped. I don't think there is any way to fix this. The people (who worked for me!) who wrote the code originally used the 8th bit as some kind of flag, and this is buried so deep in the ccmd code that changing would break everything else. Obviously this was before I got interested in character sets! (Circa 1983-84.) > Should I expect to be able to send/receive the full 256-character set > with this version of mm? > I do it all day, every day. UTF-8, Latin-1, KOI-8, you name it. Did you read: ftp://kermit.columbia.edu/pub/mm/release-0.91.txt > Should I expect attachments to be recognized, for both incoming > and outgoing mail? > No. You can build with metamail support if you want, but I don't do that. I find it worse than useless. If I really need to bust out attachments, I save the message to a file and either run it thru metamail by hand, or else download to Windows, as described in the release notes -- that is, after eyeballing to make sure it can't possibly contain a virus. - Frank From beebe@sunshine.math.utah.edu Sun Aug 24 17:54:39 2003 Flags: 000000000001 Return-Path: Received: from sunshine.math.utah.edu (sunshine.math.utah.edu [128.110.198.2]) by blueberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7PCsaGC014591 for ; Mon, 25 Aug 2003 08:54:36 -0400 (EDT) Received: from psi.math.utah.edu (IDENT:K+7eJgB8Rvtn6SnDvtMC1SxjoucPlsab@psi.math.utah.edu [128.110.198.32]) by sunshine.math.utah.edu (8.9.3p2/8.9.3) with ESMTP id GAA14979; Mon, 25 Aug 2003 06:54:35 -0600 (MDT) Received: (from beebe@localhost) by psi.math.utah.edu (8.9.3p2/8.9.3) id GAA06491; Mon, 25 Aug 2003 06:54:35 -0600 (MDT) Date: Mon, 25 Aug 2003 06:54:35 -0600 (MDT) From: "Nelson H. F. Beebe" To: Frank da Cruz Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: mm-0.91.0(142): build comments and 8-bit support questions In-Reply-To: Your message of Sun, 24 Aug 2003 12:34:09 EDT Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 167 Thanks for the comments on the 8-bit issues in ccmd and mm. I'd noticed with our old mm that I could sometimes use 8-bit characters, and sometimes not; the use-editor-always flag was not something that I'd figured out to explain that. In March/April 1996, I spent a few weeks working on mm and ccmd, trying to clean up things to allow porting to other platforms. The use of the high bit in each character was not something that I found could be readily removed, so I too gave up on that. Thanks also for your spam filter; it looks like a much-expanded version of what I use here, so I'll adapt it. Since the beginning of March, I've been using procmail filters to do a lot of prefiltering, and spam redirection. If you use procmail on your system (it sits between incoming mail and delivery to /var/spool/mail/username), I'll be happy to send my stuff on to you. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 110 LCB beebe@acm.org beebe@computer.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From terry@imtsg18.epfl.ch Wed Aug 27 18:48:54 2003 Flags: 000000000011 Return-Path: Received: from imtsg14.epfl.ch (imtsg14.epfl.ch [128.178.45.228]) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7S8mqeH008625 for ; Thu, 28 Aug 2003 04:48:53 -0400 (EDT) Received: from imtsg18.epfl.ch (imtsg18.epfl.ch [128.178.45.230]) by imtsg14.epfl.ch (8.8.8/8.8.8) with ESMTP id KAA14985 for ; Thu, 28 Aug 2003 10:48:51 +0200 (CEST) Received: (from terry@localhost) by imtsg18.epfl.ch (8.8.8/8.8.8) id KAA13187 for fdc@columbia.edu; Thu, 28 Aug 2003 10:48:51 +0200 (CEST) Sender: Terry Fong Date: Thu, 28 Aug 2003 10:48:50 CEST From: terry@imtsg14.epfl.ch Reply-To: terry@imtsg14.epfl.ch To: fdc@columbia.edu Subject: thanks for mm-0.91 Message-ID: X-Spam-Score: 1 (*) NO_REAL_NAME X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 168 Hi Frank, Just wanted to thank you for updating mm! I've been using mm for more than 10 years and I'm glad to know that at least one other person in the world still uses it. Two days ago, after getting fed up for the 1000000th time with the "truncating edit problem" I was incredibly happy to discover your update. Thanks very much and keep up the good work! Cheers, Terry From terry@imtsg18.epfl.ch Thu Aug 28 05:15:54 2003 Flags: 000000000001 Return-Path: Received: from imtsg14.epfl.ch (imtsg14.epfl.ch [128.178.45.228]) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7SJFnd3009921 for ; Thu, 28 Aug 2003 15:15:49 -0400 (EDT) Received: from imtsg18.epfl.ch (imtsg18.epfl.ch [128.178.45.230]) by imtsg14.epfl.ch (8.8.8/8.8.8) with ESMTP id VAA22868 for ; Thu, 28 Aug 2003 21:15:48 +0200 (CEST) Received: (from terry@localhost) by imtsg18.epfl.ch (8.8.8/8.8.8) id VAA14560 for Frank da Cruz ; Thu, 28 Aug 2003 21:15:47 +0200 (CEST) Sender: Terry Fong Date: Thu, 28 Aug 2003 21:15:46 CEST From: terry@imtsg14.epfl.ch Reply-To: terry@imtsg14.epfl.ch To: Frank da Cruz Subject: Re: thanks for mm-0.91 In-Reply-To: Your message of Thu, 28 Aug 2003 11:14:17 EDT Message-ID: X-Spam-Score: 1 (*) NO_REAL_NAME X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 169 >> Two days ago, after getting fed up for the 1000000th time with the >> "truncating edit problem" I was incredibly happy to discover your >> update. Thanks very much and keep up the good work! >> > So this happened to you on Solaris? On an NFS-mounted disk? IRIX 6.x with NFS... -t From fdc@columbia.edu Thu Aug 28 06:14:18 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7SFEIsp028734 for ; Thu, 28 Aug 2003 11:14:18 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.8/8.12.8) with ESMTP id h7SFEH0G012028; Thu, 28 Aug 2003 11:14:17 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.8/8.12.8/Submit) id h7SFEHJt012027; Thu, 28 Aug 2003 11:14:17 -0400 (EDT) Date: Thu, 28 Aug 2003 11:14:17 EDT From: Frank da Cruz To: terry@imtsg14.epfl.ch Subject: Re: thanks for mm-0.91 In-Reply-To: Your message of Thu, 28 Aug 2003 10:48:50 CEST Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 170 > Just wanted to thank you for updating mm! I've been using mm for more than 10 > years and I'm glad to know that at least one other person in the world still > uses it. > Actually quite a few do, but don't like to admit it. > Two days ago, after getting fed up for the 1000000th time with the > "truncating edit problem" I was incredibly happy to discover your > update. Thanks very much and keep up the good work! > So this happened to you on Solaris? On an NFS-mounted disk? Anyway, you're welcome -- I could not live (well, work) without it. As you can see here: http://www.columbia.edu/kermit/safe.html :-) - Frank From melissa@columbia.edu Tue Oct 7 16:08:30 2003 Flags: 000000000011 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h98L8T1n006545; Wed, 8 Oct 2003 17:08:29 -0400 (EDT) Received: (from melissa@localhost) by hazelnut.cc.columbia.edu (8.12.10/8.12.8/Submit) id h98L8TVP006544; Wed, 8 Oct 2003 17:08:29 -0400 (EDT) Date: Wed, 8 Oct 2003 17:08:28 EDT From: Melissa Metz To: fdc@columbia.edu Cc: melissa@columbia.edu Subject: MM date creeping Message-ID: Status: O X-Status: X-Keywords: X-UID: 171 I noticed Arthur's MM is creeping the dates of his messages backwards, so a message he received August 25 is now labeled August 8. !! He is running the installed version: Compiled by fdc@watsol on 5 Oct 2002 1:39pm I am apparently running the version in ~melissa/scripts: Compiled by fdc@watsol on 19 Sep 2002 11:33am sigh. I think once I get the new pine up we will have to take another look at installing the new MM you had compiled more recently (the one that got the paths right but seemed to break for e.g. Edna). --Melissa From fdc@columbia.edu Thu Oct 9 07:44:24 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by tepin.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99GiNml023028 for ; Thu, 9 Oct 2003 12:44:23 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99GiMnS015098; Thu, 9 Oct 2003 12:44:22 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h99GiLAa015095; Thu, 9 Oct 2003 12:44:21 -0400 (EDT) Date: Thu, 9 Oct 2003 12:44:21 -0400 (EDT) Message-Id: <200310091644.h99GiLAa015095@sesame.cc.columbia.edu> From: Frank da Cruz To: Mark Crispin Subject: mbox format X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 172 I was about to start working on a small fix to MM regarding "date drift" when mail files are stored in mbox format. The silly "From " line at the start of a message contains a date, but no timezone indication. Apparently the various MUAs, MTAs, MDAs, etc, conflict as to whether the the date/time should be local or UTC/GMT and this causes trouble, at least in MM. I spent a couple hours trying to find a definitive specification of mbox format without success. RFC 822 mentions that there should be an envelope, but its format is "site dependent". RFC 976 waves its hands. Various Unixes have "man mbox" pages that conflict with each other, etc. Is mbox format specified anywhere? Thanks. - Frank From mrc@CAC.Washington.EDU Thu Oct 9 08:26:54 2003 Flags: 000000000011 Return-Path: Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by marionberry.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99HQq1a007242 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 9 Oct 2003 13:26:53 -0400 (EDT) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h99HQoMk029818 for ; Thu, 9 Oct 2003 10:26:50 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h99HQnAI028219 for ; Thu, 9 Oct 2003 10:26:50 -0700 Date: Thu, 9 Oct 2003 10:26:49 -0700 (PDT) From: Mark Crispin To: Frank da Cruz Subject: Re: mbox format In-Reply-To: <200310091644.h99GiLAa015095@sesame.cc.columbia.edu> Message-ID: References: <200310091644.h99GiLAa015095@sesame.cc.columbia.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 173 On Thu, 9 Oct 2003, Frank da Cruz wrote: > I was about to start working on a small fix to MM regarding "date drift" > when mail files are stored in mbox format. The silly "From " line at the > start of a message contains a date, but no timezone indication. Some "From " lines. Here, from c-client sources, is the full story: /* You are not expected to understand this macro, but read the next page if * you are not faint of heart. * * Known formats to the VALID macro are: * From user Wed Dec 2 05:53 1992 * BSD From user Wed Dec 2 05:53:22 1992 * SysV From user Wed Dec 2 05:53 PST 1992 * rn From user Wed Dec 2 05:53:22 PST 1992 * From user Wed Dec 2 05:53 -0700 1992 * emacs From user Wed Dec 2 05:53:22 -0700 1992 * From user Wed Dec 2 05:53 1992 PST * From user Wed Dec 2 05:53:22 1992 PST * From user Wed Dec 2 05:53 1992 -0700 * Solaris From user Wed Dec 2 05:53:22 1992 -0700 * * Plus all of the above with `` remote from xxx'' after it. Thank you very * much, smail and Solaris, for making my life considerably more complicated. */ > I spent a couple hours trying to find a definitive specification of mbox > format without success. > Is mbox format specified anywhere? RFCs wouldn't say anything about local file formats. POSIX might, but I wouldn't trust it. Why not just make Columbia MM use my c-client library? Or, put another way, to finish the "MS" program (name intentional) that I wrote which uses CCMD and c-client? Then you'll get IMAP, POP3, and NNTP support for free, along with lots of local mailbox formats. By the way, could you do me a favor and investigate the bboard.tops-20@cs.columbia.edu email address for me? This address is on the TOPS-20 list, and recently several list members got hit by SWEN junk that indicated that these addresses came from a TOPS-20 list posting. So something is leaking TOPS-20 list mail to netnews, and I suspect that this is the leak. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From fdc@columbia.edu Thu Oct 9 08:33:40 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by tepin.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99HXdml006480 for ; Thu, 9 Oct 2003 13:33:39 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99HXcnS021027; Thu, 9 Oct 2003 13:33:38 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h99HXcs1021026; Thu, 9 Oct 2003 13:33:38 -0400 (EDT) Date: Thu, 9 Oct 2003 13:33:38 EDT From: Frank da Cruz To: Mark Crispin Subject: Re: mbox format In-Reply-To: Your message of Thu, 9 Oct 2003 10:26:49 -0700 (PDT) Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 174 > Some "From " lines. Here, from c-client sources, is the full story: > Yuk. OK, now at least I know what I'm dealing with. > Why not just make Columbia MM use my c-client library? Or, put another > way, to finish the "MS" program (name intentional) that I wrote which uses > CCMD and c-client? > > Then you'll get IMAP, POP3, and NNTP support for free, along with lots of > local mailbox formats. > I don't think I knew about MS. Of course nowadays I tend to forget a lot of things... I'll add this to my list of big projects so I'll remember next time :-) But today I just need (and have time) to fix one little bug. Thanks! > By the way, could you do me a favor and investigate the > bboard.tops-20@cs.columbia.edu email address for me? > Yes, I'll do this and get back to you. - Frank From fdc@columbia.edu Thu Oct 9 17:10:16 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by dewberry.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99LAF0u005581; Thu, 9 Oct 2003 17:10:15 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99LAEnS017792; Thu, 9 Oct 2003 17:10:14 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h99LAElD017787; Thu, 9 Oct 2003 17:10:14 -0400 (EDT) Date: Thu, 9 Oct 2003 17:10:14 EDT From: Frank da Cruz To: Melissa Metz cc: bug-mm@columbia.edu Subject: Re: MM date creeping In-Reply-To: Your message of Wed, 8 Oct 2003 17:08:28 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 175 > I noticed Arthur's MM is creeping the dates of his messages backwards, > so a message he received August 25 is now labeled August 8. !! > I fixed this today. The first date creeping problem was because of daylight savings time. It was (most recently) fixed a year ago. This date creeping problem was due to the timestamp in the mbox-format envelope being read in as local time but written out in GMT, which in turn was due to #ifdefs not picking up the right stuff in Solaris. Here's the tarball with the fix: ~kermit/mm/mm-ccmd-0.91-20031009.tar.gz I built and tested it on Solaris 2.5.1 and Solaris 9. You can find the Solaris 2.5.1 binary here: ~fdc/bin.solaris/mm - Frank From fdc@columbia.edu Wed Oct 8 08:38:54 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by tepin.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99Dcrml025089; Thu, 9 Oct 2003 09:38:53 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h99DcrnS022534; Thu, 9 Oct 2003 09:38:53 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h99Dcr0g022533; Thu, 9 Oct 2003 09:38:53 -0400 (EDT) Date: Thu, 9 Oct 2003 9:38:53 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM date creeping In-Reply-To: Your message of Wed, 8 Oct 2003 17:08:28 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 176 > I noticed Arthur's MM is creeping the dates of his messages backwards, > so a message he received August 25 is now labeled August 8. !! > > He is running the installed version: > > Compiled by fdc@watsol on 5 Oct 2002 1:39pm > > I am apparently running the version in ~melissa/scripts: > > Compiled by fdc@watsol on 19 Sep 2002 11:33am > > sigh. > > I think once I get the new pine up we will have to take another look > at installing the new MM you had compiled more recently (the one that > got the paths right but seemed to break for e.g. Edna). > I thought the trouble with Edna was in the mailsplit code, not in MM? The date-creep business might still need some work. I think the problem is that the top "From " (envelope) line has the time in GMT but the code the reads and rewrites it interprets it in local time. Aside from that, I've been running it all this time, even through the 16,000-spams-per-day period; it has been fine on watsol, sesame, newcunix, etc. The current code is in ~kermit/mm/. It's from 5 Oct 2002; build it with "make solaris-cu". I still have a to-do list but nothing urgent. If I get time today I'll look again at the date-creep business. - Frank From fdc@columbia.edu Thu Oct 16 13:31:49 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by tepin.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9GHVnEI026839; Thu, 16 Oct 2003 13:31:49 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9GHVmnS018726; Thu, 16 Oct 2003 13:31:48 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h9GHVmT8018725; Thu, 16 Oct 2003 13:31:48 -0400 (EDT) Date: Thu, 16 Oct 2003 13:31:48 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM date creeping In-Reply-To: Your message of Thu, 16 Oct 2003 8:34:49 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 177 > Thanks for taking care of this. I'm just getting to look at it today. > Did you have a Sol 9 binary? I'm trying to retire Sol 2.5.1 this > month :-). I figure I'll put up the new version as mm.test and see if > Edna can read her mail (she was a splitmail victim last time). > ~fdc/bin.solaris/mm-0.91-153-solaris-9 - Frank From melissa@columbia.edu Thu Oct 16 18:08:48 2003 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9GM8mO3006921; Thu, 16 Oct 2003 18:08:48 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.3) with ESMTP id h9GM8lBl015411; Thu, 16 Oct 2003 18:08:47 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id h9GM8l6P015410; Thu, 16 Oct 2003 18:08:47 -0400 (EDT) Date: Thu, 16 Oct 2003 18:08:47 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: MM date creeping In-Reply-To: Your message of Thu, 16 Oct 2003 13:31:48 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 178 > > Thanks for taking care of this. I'm just getting to look at it today. > > Did you have a Sol 9 binary? I'm trying to retire Sol 2.5.1 this > > month :-). I figure I'll put up the new version as mm.test and see if > > Edna can read her mail (she was a splitmail victim last time). > > > ~fdc/bin.solaris/mm-0.91-153-solaris-9 > > - Frank > Thanks, I'll try this tomorrow. --Melissa From melissa@columbia.edu Fri Oct 17 10:34:59 2003 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9HEYwO3013610; Fri, 17 Oct 2003 10:34:58 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.3) with ESMTP id h9HEYwBl026195; Fri, 17 Oct 2003 10:34:58 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id h9HEYwD6026194; Fri, 17 Oct 2003 10:34:58 -0400 (EDT) Date: Fri, 17 Oct 2003 10:34:58 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: MM date creeping In-Reply-To: Your message of Thu, 16 Oct 2003 13:31:48 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 179 > > Thanks for taking care of this. I'm just getting to look at it today. > > Did you have a Sol 9 binary? I'm trying to retire Sol 2.5.1 this > > month :-). I figure I'll put up the new version as mm.test and see if > > Edna can read her mail (she was a splitmail victim last time). > > > ~fdc/bin.solaris/mm-0.91-153-solaris-9 > > - Frank > Thanks, I installed this as mm.new, available on newcunix. My test account, tc2039, cannot find new mail. Do you think it is compiled with .splitmail? We could put a wrapper around mm to set the incoming-mail variable, but it looks like it would have to edit the user's .mminit file (mm ignores the $SPOOL environment variable). --Melissa From fdc@columbia.edu Fri Oct 17 10:47:09 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by tepin.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9HEl4EI009182; Fri, 17 Oct 2003 10:47:04 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9HEl2nS012632; Fri, 17 Oct 2003 10:47:03 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h9HEkw4E012628; Fri, 17 Oct 2003 10:46:58 -0400 (EDT) Date: Fri, 17 Oct 2003 10:46:58 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM date creeping In-Reply-To: Your message of Fri, 17 Oct 2003 10:34:58 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 180 > Thanks, I installed this as mm.new, available on newcunix. > > My test account, tc2039, cannot find new mail. Do you think it is > compiled with .splitmail? > Does anything need to be done to make that happen? I didn't do anything special. But it's working for me and the other Kermites. You would think it would work for all or none, but not some??? > We could put a wrapper around mm to set the incoming-mail variable, > but it looks like it would have to edit the user's .mminit file (mm > ignores the $SPOOL environment variable). > I thought the idea of splitmail was that it would be invisible to applications. If you need special code in MM, just tell me what it should do and I'll add it. Or linked with a special library??? Maybe the required library is not on sesame, where I built the Solaris 9 version. Does the Solaris 2.5.1 version work? ~fdc/bin.solaris/mm-0.91-152-solaris-2.5.1 - Frank From melissa@columbia.edu Fri Oct 17 11:46:25 2003 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9HFkOO3008519; Fri, 17 Oct 2003 11:46:24 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.3) with ESMTP id h9HFkOBl027564; Fri, 17 Oct 2003 11:46:24 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id h9HFkO3c027563; Fri, 17 Oct 2003 11:46:24 -0400 (EDT) Date: Fri, 17 Oct 2003 11:46:24 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: MM date creeping In-Reply-To: Your message of Fri, 17 Oct 2003 10:46:58 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 181 > > Thanks, I installed this as mm.new, available on newcunix. > > > > My test account, tc2039, cannot find new mail. Do you think it is > > compiled with .splitmail? > > > Does anything need to be done to make that happen? I didn't do anything > special. But it's working for me and the other Kermites. You would think > it would work for all or none, but not some??? What is your incoming-mail variable set to? > > We could put a wrapper around mm to set the incoming-mail variable, > > but it looks like it would have to edit the user's .mminit file (mm > > ignores the $SPOOL environment variable). > > > I thought the idea of splitmail was that it would be invisible to > applications. If you need special code in MM, just tell me what it should > do and I'll add it. > > Or linked with a special library??? Maybe the required library is not > on sesame, where I built the Solaris 9 version. It needs to be linked with the splitmail libc. I'm not sure if we have that for Sol 9. I think it was hard to make. I guess I thought you already knew about it. I'll see if I can dig up the code. > Does the Solaris 2.5.1 > version work? > > ~fdc/bin.solaris/mm-0.91-152-solaris-2.5.1 Nope, doesn't work. --Melissa From fdc@columbia.edu Fri Oct 17 12:33:50 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by tepin.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9HGXnEI006863; Fri, 17 Oct 2003 12:33:49 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9HGXnnS025661; Fri, 17 Oct 2003 12:33:49 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h9HGXndV025660; Fri, 17 Oct 2003 12:33:49 -0400 (EDT) Date: Fri, 17 Oct 2003 12:33:48 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM date creeping In-Reply-To: Your message of Fri, 17 Oct 2003 11:46:24 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 182 > What is your incoming-mail variable set to? > MM>show incoming-mail set incoming-mail /var/spool/mail/f/d/fdc ~/mbox MM> Guess that's why it works for me! I don't even remember putting it there... > It needs to be linked with the splitmail libc. I'm not sure if we > have that for Sol 9. I think it was hard to make. I guess I thought > you already knew about it. I'll see if I can dig up the code. > OK, I now I get it. Since we are building a Columbia-specific version anyway, maybe I can just add code to initialize the incoming-mail value automatically, CU style. Obviously this would only work on Columbia hosts, but at this point, who cares. It's always /var/spool/mail///, right? Another idea would be to do this only if a certain environment variable was set. Come to think of it, this might not be a bad idea anyway. This way applications could activate Columbia-specific code at runtime. How do Pine, mail, Mail, mailx, etc, find mail? I guess Pine uses IMAP. The others (checking....) aha, they don't. - Frank From fdc@columbia.edu Fri Oct 17 15:24:17 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9HJOG9b003965; Fri, 17 Oct 2003 15:24:16 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9HJOGnS016702; Fri, 17 Oct 2003 15:24:16 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h9HJOGBe016701; Fri, 17 Oct 2003 15:24:16 -0400 (EDT) Date: Fri, 17 Oct 2003 15:24:16 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM date creeping In-Reply-To: Your message of Fri, 17 Oct 2003 12:40:31 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 183 > Right, you don't need the old libc code :-). > > You do splitmail handling if /var/spool/.splitmail exists. > OK, done. In the pathological case of a single-char user ID, I use /var/spool/mail/a/a/a (or whatever) as the spool file. The new Solaris 9 binary is here: ~fdc/bin.solaris/mm-0.91-154-solaris-9 Corresponding sources are here: ftp://kermit.columbia.edu/kermit/mm/mm-ccmd-0.91-20031017.tar.gz The change was just a couple lines in new_mail(): newmail.c. - Frank From melissa@columbia.edu Mon Oct 20 10:41:55 2003 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by blueberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9KEfYHm025044; Mon, 20 Oct 2003 10:41:34 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.3) with ESMTP id h9KEfYBl027363; Mon, 20 Oct 2003 10:41:34 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id h9KEfYQo027361; Mon, 20 Oct 2003 10:41:34 -0400 (EDT) Date: Mon, 20 Oct 2003 10:41:34 EDT From: Melissa Metz To: unixsys@columbia.edu CC: fdc@columbia.edu, jill@columbia.edu Subject: new MM installed Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 184 I installed a new version of MM today, which fixes two issues. The previous version was creeping dates, so if you look at the header of your oldest message it won't match the internal time of the message. Last time we installed a new MM, it didn't understand splitmail (spools in /var/spool/mail/m/e/melissa); the new version does it internally instead of counting on the funky libc hack. I installed it on newcunix only so far. I will try to run opium later to get it everywhere if there are no problems. Problems to me and Frank. Backout to /master/opt/ACISmm/bin/mm.old on oregano. --Melissa To un-creep the dates, make sure your MM is Friday's version: MM> version ... Compiled by fdc@sesame on 17 Oct 2003 3:11pm Instructions for correcting ~/mbox: MM>set incoming-mail /tmp/nosuchfile MM>copy /babyl ~/mail.babyl all MM>get ~/mail.babyl MM>suspend $ mv ~/mbox ~/mbox.save $ fg MM>move /mbox ~/mbox all MM>expunge MM>get Or ~/mail/mail.txt: MM>set incoming-mail /tmp/nosuchfile MM>copy /babyl ~/mail.babyl all MM>get ~/mail.babyl MM>suspend $ mv ~/mail/mail.txt{,.save} $ fg MM>move /mtxt ~/mail/mail.txt all MM>expunge MM>get From melissa@columbia.edu Mon Oct 20 10:49:09 2003 Flags: 000000000011 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by blueberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9KEn8Hm028318; Mon, 20 Oct 2003 10:49:08 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.3) with ESMTP id h9KEn8Bl027510; Mon, 20 Oct 2003 10:49:08 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id h9KEn8Z7027507; Mon, 20 Oct 2003 10:49:08 -0400 (EDT) Date: Mon, 20 Oct 2003 10:49:07 EDT From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: MM date creeping In-Reply-To: Your message of Fri, 17 Oct 2003 15:24:16 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 185 > > Right, you don't need the old libc code :-). > > > > You do splitmail handling if /var/spool/.splitmail exists. > > > OK, done. In the pathological case of a single-char user ID, I use > /var/spool/mail/a/a/a (or whatever) as the spool file. The new Solaris 9 > binary is here: > > ~fdc/bin.solaris/mm-0.91-154-solaris-9 > > Corresponding sources are here: > > ftp://kermit.columbia.edu/kermit/mm/mm-ccmd-0.91-20031017.tar.gz > > The change was just a couple lines in new_mail(): newmail.c. > > - Frank > I think we have no single-character users, so we should have few problems there :-). Thanks, looks good. I tested it and installed it. Dates don't creep and my test user can read his new mail. (The copyright still says 2002.) --Melissa From fdc@columbia.edu Mon Oct 20 11:12:54 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9KFCrLe021735; Mon, 20 Oct 2003 11:12:53 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9KFCrnS020713; Mon, 20 Oct 2003 11:12:53 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h9KFCrcI020712; Mon, 20 Oct 2003 11:12:53 -0400 (EDT) Date: Mon, 20 Oct 2003 11:12:53 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: new MM installed In-Reply-To: Your message of Mon, 20 Oct 2003 10:49:49 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 186 > Actually, I installed a Sol 9 binary. Is there any way to ensure it > doesn't go to Sol 2.5 hosts next time opium is run? > In ~fdc/bin.solaris: -rwxrwxr-x 1 staff 1184524 Oct 20 11:08 mm* -rwxrwxr-x 1 staff 978060 Oct 20 11:05 mm-0.91-155-solaris-2.5.1* lrwxrwxrwx 1 staff 2 Oct 20 11:10 mm-0.91-156-solaris-9 -> mm* The current version of MM, binaries for Sol 2.5.1 and 9, and copyright date fixed (I didn't bother trying to finagle the version number to make it the same for both builds). - Frank From selsky@columbia.edu Mon Oct 20 11:33:24 2003 Flags: 000000000001 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9KFXD1n023105; Mon, 20 Oct 2003 11:33:14 -0400 (EDT) Received: (from selsky@localhost) by hazelnut.cc.columbia.edu (8.12.10/8.12.8/Submit) id h9KFXDxs023099; Mon, 20 Oct 2003 11:33:13 -0400 (EDT) Date: Mon, 20 Oct 2003 11:33:13 -0400 From: Matt Selsky To: Melissa Metz Cc: unixsys@columbia.edu, fdc@columbia.edu, jill@columbia.edu Subject: Re: new MM installed Message-ID: <20031020153313.GE22401@columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Status: O X-Status: X-Keywords: X-UID: 187 Make a new package /master/opt/opt29/ACISmm and put the sol9 binaries there. On Mon, Oct 20, 2003 at 10:49:49AM -0400, Melissa Metz wrote: > > Actually, I installed a Sol 9 binary. Is there any way to ensure it > doesn't go to Sol 2.5 hosts next time opium is run? > > --Melissa > > > I installed a new version of MM today, which fixes two issues. The > > previous version was creeping dates, so if you look at the header of > > your oldest message it won't match the internal time of the message. > > > > Last time we installed a new MM, it didn't understand splitmail > > (spools in /var/spool/mail/m/e/melissa); the new version does it > > internally instead of counting on the funky libc hack. > > > > I installed it on newcunix only so far. I will try to run opium later > > to get it everywhere if there are no problems. > > > > Problems to me and Frank. Backout to /master/opt/ACISmm/bin/mm.old on > > oregano. > > > > --Melissa > > > > To un-creep the dates, make sure your MM is Friday's version: > > > > MM> version > > ... > > Compiled by fdc@sesame on 17 Oct 2003 3:11pm > > > > Instructions for correcting ~/mbox: > > > > MM>set incoming-mail /tmp/nosuchfile > > MM>copy /babyl ~/mail.babyl all > > MM>get ~/mail.babyl > > MM>suspend > > $ mv ~/mbox ~/mbox.save > > $ fg > > MM>move /mbox ~/mbox all > > MM>expunge > > MM>get > > > > Or ~/mail/mail.txt: > > > > MM>set incoming-mail /tmp/nosuchfile > > MM>copy /babyl ~/mail.babyl all > > MM>get ~/mail.babyl > > MM>suspend > > $ mv ~/mail/mail.txt{,.save} > > $ fg > > MM>move /mtxt ~/mail/mail.txt all > > MM>expunge > > MM>get > > From melissa@columbia.edu Mon Oct 20 11:41:41 2003 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by dewberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9KFfUad029546; Mon, 20 Oct 2003 11:41:30 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.3) with ESMTP id h9KFfTBl028322; Mon, 20 Oct 2003 11:41:29 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id h9KFfTNw028321; Mon, 20 Oct 2003 11:41:29 -0400 (EDT) Date: Mon, 20 Oct 2003 11:41:29 EDT From: Melissa Metz To: Melissa Metz Cc: Melissa Metz , unixsys@columbia.edu, fdc@columbia.edu, jill@columbia.edu Subject: Re: new MM installed In-Reply-To: Your message of Mon, 20 Oct 2003 10:49:49 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 188 I backed out the Sol 9 binary for old cunix (which all get it off chinchin): oregano# cd /master/opt/ACISmm/bin oregano# mv mm mm.new ; mv mm.old mm oregano# ldist /master/opt/ACISmm/bin/mm Because newcunix hosts keep ACISmm local, I had rdist'd to them and they still have it until opium runs. sigh. oregano# rdist -c /opt/ACISmm/bin/mm `ourhosts -solfhstimeshare -rdist`: --Melissa > > Actually, I installed a Sol 9 binary. Is there any way to ensure it > doesn't go to Sol 2.5 hosts next time opium is run? > > --Melissa > > > I installed a new version of MM today, which fixes two issues. The > > previous version was creeping dates, so if you look at the header of > > your oldest message it won't match the internal time of the message. > > > > Last time we installed a new MM, it didn't understand splitmail > > (spools in /var/spool/mail/m/e/melissa); the new version does it > > internally instead of counting on the funky libc hack. > > > > I installed it on newcunix only so far. I will try to run opium later > > to get it everywhere if there are no problems. > > > > Problems to me and Frank. Backout to /master/opt/ACISmm/bin/mm.old on > > oregano. > > > > --Melissa > > > > To un-creep the dates, make sure your MM is Friday's version: > > > > MM> version > > ... > > Compiled by fdc@sesame on 17 Oct 2003 3:11pm > > > > Instructions for correcting ~/mbox: > > > > MM>set incoming-mail /tmp/nosuchfile > > MM>copy /babyl ~/mail.babyl all > > MM>get ~/mail.babyl > > MM>suspend > > $ mv ~/mbox ~/mbox.save > > $ fg > > MM>move /mbox ~/mbox all > > MM>expunge > > MM>get > > > > Or ~/mail/mail.txt: > > > > MM>set incoming-mail /tmp/nosuchfile > > MM>copy /babyl ~/mail.babyl all > > MM>get ~/mail.babyl > > MM>suspend > > $ mv ~/mail/mail.txt{,.save} > > $ fg > > MM>move /mtxt ~/mail/mail.txt all > > MM>expunge > > MM>get > > > From selsky@columbia.edu Mon Oct 20 12:22:23 2003 Flags: 000000000001 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9KGMD1n025495; Mon, 20 Oct 2003 12:22:13 -0400 (EDT) Received: (from selsky@localhost) by hazelnut.cc.columbia.edu (8.12.10/8.12.8/Submit) id h9KGMDV9025494; Mon, 20 Oct 2003 12:22:13 -0400 (EDT) Date: Mon, 20 Oct 2003 12:22:12 -0400 From: Matt Selsky To: Melissa Metz Cc: unixsys@columbia.edu, fdc@columbia.edu, jill@columbia.edu Subject: Re: new MM installed Message-ID: <20031020162212.GJ22401@columbia.edu> References: <20031020153313.GE22401@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031020153313.GE22401@columbia.edu> User-Agent: Mutt/1.4.1i Status: O X-Status: X-Keywords: X-UID: 189 I've made a sol9 ACISmm package and I am pushing that out now. On Mon, Oct 20, 2003 at 11:33:13AM -0400, Matt Selsky wrote: > Make a new package /master/opt/opt29/ACISmm and put the sol9 binaries > there. > > On Mon, Oct 20, 2003 at 10:49:49AM -0400, Melissa Metz wrote: > > > > Actually, I installed a Sol 9 binary. Is there any way to ensure it > > doesn't go to Sol 2.5 hosts next time opium is run? > > > > --Melissa > > > > > I installed a new version of MM today, which fixes two issues. The > > > previous version was creeping dates, so if you look at the header of > > > your oldest message it won't match the internal time of the message. > > > > > > Last time we installed a new MM, it didn't understand splitmail > > > (spools in /var/spool/mail/m/e/melissa); the new version does it > > > internally instead of counting on the funky libc hack. > > > > > > I installed it on newcunix only so far. I will try to run opium later > > > to get it everywhere if there are no problems. > > > > > > Problems to me and Frank. Backout to /master/opt/ACISmm/bin/mm.old on > > > oregano. > > > > > > --Melissa > > > > > > To un-creep the dates, make sure your MM is Friday's version: > > > > > > MM> version > > > ... > > > Compiled by fdc@sesame on 17 Oct 2003 3:11pm > > > > > > Instructions for correcting ~/mbox: > > > > > > MM>set incoming-mail /tmp/nosuchfile > > > MM>copy /babyl ~/mail.babyl all > > > MM>get ~/mail.babyl > > > MM>suspend > > > $ mv ~/mbox ~/mbox.save > > > $ fg > > > MM>move /mbox ~/mbox all > > > MM>expunge > > > MM>get > > > > > > Or ~/mail/mail.txt: > > > > > > MM>set incoming-mail /tmp/nosuchfile > > > MM>copy /babyl ~/mail.babyl all > > > MM>get ~/mail.babyl > > > MM>suspend > > > $ mv ~/mail/mail.txt{,.save} > > > $ fg > > > MM>move /mtxt ~/mail/mail.txt all > > > MM>expunge > > > MM>get > > > From melissa@columbia.edu Thu Oct 23 15:44:11 2003 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by blueberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9NJhb7i025137; Thu, 23 Oct 2003 15:43:39 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.3) with ESMTP id h9NJhbBl007339; Thu, 23 Oct 2003 15:43:37 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id h9NJhbtQ007338; Thu, 23 Oct 2003 15:43:37 -0400 (EDT) Date: Thu, 23 Oct 2003 15:43:37 EDT From: Melissa Metz To: Frank da Cruz Cc: Eric Weaver , unixsys@columbia.edu Subject: Re: Something wrong with sesame? In-Reply-To: Your message of Thu, 23 Oct 2003 14:46:33 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 190 > > > Started mm this morning and it just sat there forever. Works fine on > > > newcunix, so it's not MM. "truss mm" says: > > > > > > stat("/p/kd/fdc/MAIL/mail.txt", 0xFFBFF640) = 0 > > > open("/p/kd/fdc/MAIL/mail.txt", O_RDWR) = 4 > > > fstat(4, 0xFFBFF640) = 0 > > > fcntl(4, F_SETLK, 0xFFBFF390) (sleeping...) > > > > > > So it's waiting forever for a lock? Never saw this before... > > > > For what it's worth... The same symptom happened to me on papaya this > > morning. I've seen similar behaviour on other systems, too; tho I can't > > say on which it does/doesn't occur. Although I didn't check for the > > underlying cause, I can say that all the occurences have been since the > > recent deployment of a new MM. I had no such problems previous to that > > deployment. /Eric > > > Thanks, Eric. It's really hard to see how the new MM could be the culprit > -- I didn't touch any code in this area; only the way it finds the mail > spool and the way it rewrites the date in the envelope. Anyway, the code > is behaving normally -- requesting a lock on my personal mailbox. The > request never returns. I suspect it's an NFS glitch (I always say that :-) > > - Frank > My MM (on broccoli) also hung in the fcntl this morning. I killed it with a 9 and the next MM I started was fine. --Melissa From melissa@columbia.edu Thu Oct 23 15:44:50 2003 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9NJih7s022911; Thu, 23 Oct 2003 15:44:43 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.3) with ESMTP id h9NJihBl007361; Thu, 23 Oct 2003 15:44:43 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id h9NJihiB007360; Thu, 23 Oct 2003 15:44:43 -0400 (EDT) Date: Thu, 23 Oct 2003 15:44:43 EDT From: Melissa Metz To: Linda Wallinger Cc: Melissa Metz , brennan@columbia.edu, lynn@columbia.edu, lindaw@columbia.edu, fdc@columbia.edu, melissa@columbia.edu Subject: Re: MM date creeping In-Reply-To: Your message of Thu, 23 Oct 2003 14:51:56 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 191 Yes, it is since Monday (or maybe Tuesday). MM>version Columbia MM, version 0.91.0(156) Copyright (c) 1986, 2003 The Trustees of Columbia University in the City of New York Compiled by fdc@sesame on 20 Oct 2003 11:07am Report bugs to bug-mm --Melissa > Is the new MM available? I'm not sure if I missed something... > > /Linda > > > > > The current MM has been "creeping" dates backward. I am going to put > > up a new MM Frank has provided which doesn't creep them anymore. > > Currently it is called mm.new; I'm going to test it with Edna, who had > > trouble the last time we installed a new MM. > > > > Once you are running the new MM, here are the instructions for > > correcting the dates in your main mail file, assuming it is called > > ~/mbox (mine is ~/mail/mail.txt). > > > > MM>set incoming-mail /tmp/nosuchfile > > MM>copy /babyl ~/mail.babyl all > > MM>get ~/mail.babyl > > MM>suspend > > neva$ mv ~/mbox ~/mbox.save > > neva$ fg > > MM>copy /mbox ~/mbox all > > > > Alternately: > > > > MM>set incoming-mail /tmp/nosuchfile > > MM>copy /babyl ~/mail.babyl all > > MM>get ~/mail.babyl > > MM>suspend > > neva$ mv ~/mail/mail.txt{,.save} > > neva$ fg > > MM>copy /mtxt ~/mail/mail.txt all > > > > Not sure who to notify about this... The 61 MM users? > > > > --Melissa > > > From sky@columbia.edu Thu Oct 23 17:39:12 2003 Flags: 000000000011 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9NLdB1n025538; Thu, 23 Oct 2003 17:39:11 -0400 (EDT) Received: from localhost (sky@localhost) by hazelnut.cc.columbia.edu (8.12.10/8.12.8/Submit) with ESMTP id h9NLdB0T025534; Thu, 23 Oct 2003 17:39:11 -0400 (EDT) X-Authentication-Warning: hazelnut.cc.columbia.edu: sky owned process doing -bs Date: Thu, 23 Oct 2003 17:39:10 -0400 (EDT) From: Schuyler Duveen Sender: sky@columbia.edu To: Frank da Cruz , Melissa Metz Subject: mm feature request Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 192 I don't use MM :(, but I have a feature request, so that some upcoming Remedy integration will allow MM users to take advantage of it (especially Linda, as postmaster). Basically, it's to respect RFC-2822 wrt In-Reply-To: and References: header tags. It seems MM adheres to RFC-822's format. The important thing for Remedy is to include the Message-ID in the In-Reply-to: field, or at least, the References: field. Some email client examples: MM: In-Reply-To: Your message of Tue, 21 Oct 2003 09:26:27 -0400 (EDT) Pine, and seemingly most PC/Mac clients that I've tested: In-Reply-To: <000b01c398b5$c77964b0$e11f3b80@ACSCSupervisor> Emacs: In-reply-to: (message from Jeff Eldredge on Wed, 22 Oct 2003 09:56:25 -0400 (EDT)) This will help Remedy, as a BCC'd or CC'd recipient to automatically connect an email message with a Remedy ticket by correlating it with the replied-to message, and thus the ticket. Thanks in advance, if it doesn't seem like too much trouble. cheers, sky From fdc@columbia.edu Thu Oct 23 17:42:18 2003 Flags: 000000000005 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by tepin.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9NLgG3w016297; Thu, 23 Oct 2003 17:42:16 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9NLgGnS013422; Thu, 23 Oct 2003 17:42:16 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h9NLgGNN013421; Thu, 23 Oct 2003 17:42:16 -0400 (EDT) Date: Thu, 23 Oct 2003 17:42:16 EDT From: Frank da Cruz To: Schuyler Duveen Cc: Melissa Metz , bug-mm@columbia.edu Subject: Re: mm feature request In-Reply-To: Your message of Thu, 23 Oct 2003 17:39:10 -0400 (EDT) Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 193 > Basically, it's to respect RFC-2822 wrt In-Reply-To: and References: > header tags. It seems MM adheres to RFC-822's format. The important thing > for Remedy is to include the Message-ID in the In-Reply-to: field, or at > least, the References: field. > > Some email client examples: > MM: > In-Reply-To: Your message of Tue, 21 Oct 2003 09:26:27 -0400 (EDT) > > Pine, and seemingly most PC/Mac clients that I've tested: > In-Reply-To: <000b01c398b5$c77964b0$e11f3b80@ACSCSupervisor> > > Emacs: > In-reply-to: > (message from Jeff Eldredge on Wed, 22 Oct 2003 09:56:25 -0400 (EDT)) > > This will help Remedy, as a BCC'd or CC'd recipient to automatically > connect an email message with a Remedy ticket by correlating it with the > replied-to message, and thus the ticket. > > Thanks in advance, if it doesn't seem like too much trouble. > It doesn't. I'll add it to my list unless Melissa or anybody knows of any reason why I shouldn't (I don't). No promises on the schedule though. - Frank From melissa@columbia.edu Thu Oct 23 17:45:28 2003 Flags: 000000000005 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by tepin.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9NLjR3w016888; Thu, 23 Oct 2003 17:45:27 -0400 (EDT) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.3) with ESMTP id h9NLjRBl009482; Thu, 23 Oct 2003 17:45:27 -0400 (EDT) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id h9NLjRtu009481; Thu, 23 Oct 2003 17:45:27 -0400 (EDT) Date: Thu, 23 Oct 2003 17:45:26 EDT From: Melissa Metz To: Frank da Cruz Cc: Schuyler Duveen , Melissa Metz , bug-mm@columbia.edu Subject: Re: mm feature request In-Reply-To: Your message of Thu, 23 Oct 2003 17:42:16 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 194 > > Basically, it's to respect RFC-2822 wrt In-Reply-To: and References: > > header tags. It seems MM adheres to RFC-822's format. The important thing > > for Remedy is to include the Message-ID in the In-Reply-to: field, or at > > least, the References: field. > > > > Some email client examples: > > MM: > > In-Reply-To: Your message of Tue, 21 Oct 2003 09:26:27 -0400 (EDT) > > > > Pine, and seemingly most PC/Mac clients that I've tested: > > In-Reply-To: <000b01c398b5$c77964b0$e11f3b80@ACSCSupervisor> > > > > Emacs: > > In-reply-to: > > (message from Jeff Eldredge on Wed, 22 Oct 2003 09:56:25 -0400 (EDT)) > > > > This will help Remedy, as a BCC'd or CC'd recipient to automatically > > connect an email message with a Remedy ticket by correlating it with the > > replied-to message, and thus the ticket. > > > > Thanks in advance, if it doesn't seem like too much trouble. > > > It doesn't. I'll add it to my list unless Melissa or anybody knows of any > reason why I shouldn't (I don't). No promises on the schedule though. > > - Frank > Sounds good to me. Thanks, Frank. --Melissa From beecher@columbia.edu Fri Oct 24 00:12:30 2003 Flags: 000000000001 Return-Path: Received: from neb.cc.columbia.edu (neb.cc.columbia.edu [128.59.39.15]) by dewberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9O4CMa3009140; Fri, 24 Oct 2003 00:12:22 -0400 (EDT) Received: from neb.cc.columbia.edu (localhost [127.0.0.1]) by neb.cc.columbia.edu (8.12.10/8.12.3) with ESMTP id h9O4CMVR024771; Fri, 24 Oct 2003 00:12:22 -0400 (EDT) Received: (from beecher@localhost) by neb.cc.columbia.edu (8.12.10/8.12.3/Submit) id h9O4CMsO024770; Fri, 24 Oct 2003 00:12:22 -0400 (EDT) Date: Fri, 24 Oct 2003 0:12:22 EDT From: Ben Beecher To: Melissa Metz Cc: Frank da Cruz , Eric Weaver , unix@columbia.edu Office: 710 Watson (212) 854-7439 Organization: Columbia University Subject: Re: Something wrong with sesame? In-Reply-To: Your message of Thu, 23 Oct 2003 15:43:37 EDT Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 195 > > > > Started mm this morning and it just sat there forever. Works fine on > > > > newcunix, so it's not MM. "truss mm" says: > > > > > > > > stat("/p/kd/fdc/MAIL/mail.txt", 0xFFBFF640) = 0 > > > > open("/p/kd/fdc/MAIL/mail.txt", O_RDWR) = 4 > > > > fstat(4, 0xFFBFF640) = 0 > > > > fcntl(4, F_SETLK, 0xFFBFF390) (sleeping...) > > > > > > > > So it's waiting forever for a lock? Never saw this before... > > > > > > For what it's worth... The same symptom happened to me on papaya this > > > morning. I've seen similar behaviour on other systems, too; tho I can't > > > say on which it does/doesn't occur. Although I didn't check for the > > > underlying cause, I can say that all the occurences have been since the > > > recent deployment of a new MM. I had no such problems previous to that > > > deployment. /Eric > > > > > Thanks, Eric. It's really hard to see how the new MM could be the culprit > > -- I didn't touch any code in this area; only the way it finds the mail > > spool and the way it rewrites the date in the envelope. Anyway, the code > > is behaving normally -- requesting a lock on my personal mailbox. The > > request never returns. I suspect it's an NFS glitch (I always say that :-) > > > > - Frank > > > > My MM (on broccoli) also hung in the fcntl this morning. I killed it > with a 9 and the next MM I started was fine. > > --Melissa > Ditto for me. Ben From fdc@columbia.edu Mon Oct 27 13:09:05 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9RI92bR008694; Mon, 27 Oct 2003 13:09:03 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9RI92nS008304; Mon, 27 Oct 2003 13:09:02 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h9RI92sa008303; Mon, 27 Oct 2003 13:09:02 -0500 (EST) Date: Mon, 27 Oct 2003 13:09:02 EST From: Frank da Cruz To: Schuyler Duveen Cc: Melissa Metz , bug-mm@columbia.edu Subject: Re: mm feature request In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 196 > Basically, it's to respect RFC-2822 wrt In-Reply-To: and References: > header tags. It seems MM adheres to RFC-822's format. The important thing > for Remedy is to include the Message-ID in the In-Reply-to: field, or at > least, the References: field. > > Some email client examples: > MM: > In-Reply-To: Your message of Tue, 21 Oct 2003 09:26:27 -0400 (EDT) > > Pine, and seemingly most PC/Mac clients that I've tested: > In-Reply-To: <000b01c398b5$c77964b0$e11f3b80@ACSCSupervisor> > ... > This will help Remedy, as a BCC'd or CC'd recipient to automatically > connect an email message with a Remedy ticket by correlating it with the > replied-to message, and thus the ticket. > This reply is sent by MM 0.91(157), which does it Pine-style. The binary is in ~fdc/bin.solaris/mm if you want to try it. Let me know if it's OK. - Frank From sky@columbia.edu Mon Oct 27 15:59:35 2003 Flags: 000000000001 Return-Path: Received: from hazelnut.cc.columbia.edu (localhost [127.0.0.1]) by hazelnut.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9RKxW1n013932; Mon, 27 Oct 2003 15:59:32 -0500 (EST) Received: from localhost (sky@localhost) by hazelnut.cc.columbia.edu (8.12.10/8.12.8/Submit) with ESMTP id h9RKxVqc013929; Mon, 27 Oct 2003 15:59:31 -0500 (EST) X-Authentication-Warning: hazelnut.cc.columbia.edu: sky owned process doing -bs Date: Mon, 27 Oct 2003 15:59:31 -0500 (EST) From: Schuyler Duveen Sender: sky@columbia.edu To: Frank da Cruz cc: Melissa Metz , bug-mm@columbia.edu, Linda Wallinger , remedy-dev@columbia.edu Subject: Re: mm feature request In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 197 Looks great for In-Reply-To:. From a test message that Linda replied to me with, References: headers don't carry over. However, In-Reply-To: is probably sufficient functionality for Remedy. Thanks for the quick response! cheers, sky On Mon, 27 Oct 2003, Frank da Cruz wrote: > > Basically, it's to respect RFC-2822 wrt In-Reply-To: and References: > > header tags. It seems MM adheres to RFC-822's format. The important thing > > for Remedy is to include the Message-ID in the In-Reply-to: field, or at > > least, the References: field. > > > > Some email client examples: > > MM: > > In-Reply-To: Your message of Tue, 21 Oct 2003 09:26:27 -0400 (EDT) > > > > Pine, and seemingly most PC/Mac clients that I've tested: > > In-Reply-To: <000b01c398b5$c77964b0$e11f3b80@ACSCSupervisor> > > ... > > This will help Remedy, as a BCC'd or CC'd recipient to automatically > > connect an email message with a Remedy ticket by correlating it with the > > replied-to message, and thus the ticket. > > > This reply is sent by MM 0.91(157), which does it Pine-style. The binary > is in ~fdc/bin.solaris/mm if you want to try it. Let me know if it's OK. > > - Frank > From fdc@columbia.edu Thu Oct 30 10:53:10 2003 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by tepin.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9UFr3Lq002564; Thu, 30 Oct 2003 10:53:04 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.8) with ESMTP id h9UFr3nS019128; Thu, 30 Oct 2003 10:53:03 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id h9UFr3Np019123; Thu, 30 Oct 2003 10:53:03 -0500 (EST) Date: Thu, 30 Oct 2003 10:53:03 EST From: Frank da Cruz To: Schuyler Duveen Cc: Melissa Metz , bug-mm@columbia.edu Subject: Re: newcunix (fwd) In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 198 > MM problem on newcunix > > > was unable to. I got the following message: sh: > > /usr/ucb/more.mm: not > > ideas? Looks like we've been keeping a custom version of "more" around for MM's benefit. Well, I've had "set crt-filter more" in my .mminit forever so I never noticed it before. I tried starting mm without it and I get: MM>show crt-filter set crt-filter /usr/ucb/more -d Not sure where this comes from, though -- I don't see this string anywhere in the sources. Maybe an environment variable? Melissa? - Frank From melissa@columbia.edu Thu Oct 30 10:56:30 2003 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by blueberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id h9UFuSsh029098; Thu, 30 Oct 2003 10:56:28 -0500 (EST) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.3) with ESMTP id h9UFuSBl024887; Thu, 30 Oct 2003 10:56:28 -0500 (EST) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id h9UFuSlC024886; Thu, 30 Oct 2003 10:56:28 -0500 (EST) Date: Thu, 30 Oct 2003 10:56:28 EST From: Melissa Metz To: Frank da Cruz Cc: Schuyler Duveen , Melissa Metz , bug-mm@columbia.edu Subject: Re: newcunix (fwd) In-Reply-To: Your message of Thu, 30 Oct 2003 10:53:03 EST Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 199 > > MM problem on newcunix > > > > was unable to. I got the following message: sh: > > > /usr/ucb/more.mm: not > > > > ideas? > > Looks like we've been keeping a custom version of "more" around for MM's > benefit. > > Well, I've had "set crt-filter more" in my .mminit forever so I never > noticed it before. I tried starting mm without it and I get: > > MM>show crt-filter > set crt-filter /usr/ucb/more -d > > Not sure where this comes from, though -- I don't see this string anywhere > in the sources. Maybe an environment variable? > > Melissa? > > - Frank > Frank, We had a /usr/skel/.mminit a lot of these users got, which set them to more.mm. I told the support folks to just remove that line. more -d is "more for dummies": --More--[Hit space to continue, Del to abort] "more.mm -x" (which is the setting from the .mminit) was supposed to be even better. --Melissa From ron@isri.unlv.edu Thu Aug 8 13:34:13 2002 Flags: 000000000005 Return-Path: Received: from homebase.isri.unlv.edu (homebase.isri.unlv.edu [131.216.20.105]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBAMYC6w004481 for ; Tue, 10 Dec 2002 17:34:13 -0500 (EST) Received: from wiggins.isri.unlv.edu (wiggins.isri.unlv.edu [131.216.20.115]) by homebase.isri.unlv.edu (Postfix) with ESMTP id 467F52E6B9; Tue, 10 Dec 2002 14:34:10 -0800 (PST) To: Frank da Cruz Cc: ron@isri.unlv.edu Subject: MM/ccmd continuation line patch Date: Tue, 10 Dec 2002 14:34:10 -0800 From: Ron Young Message-Id: <20021210223410.467F52E6B9@homebase.isri.unlv.edu> Status: O X-Status: X-Keywords: X-UID: 200 Dear Frank: I have attached a diff listing that fixes a minor bug with continuation line processing. I have also added the ability to display a "secondary" prompt (on each continuation line). The diffs are relative to mm-ccmd-0.91. Please consider them for inclusion in the distributed version. -ron P.S. Do you know if anyone is working on adding windows NT/2k support (specifically for ccmd)? I am using ccmd as my CLI processor for a custom information retrevial system, and I would very much like to include windows support. Just from a quick test, it looks like ccmd will work under cygwin with a hybrid linux/msdos configuration. =============================================================================== Ron Young, Sr. Software Design Engineer & System Admin. (702) 895-1070 (voice) Information Science Research Institute (702) 895-1183 (fax) University of Nevada, Las Vegas (UNLV/ISRI) ron@isri.unlv.edu Box 454021, Las Vegas, NV 89154 diff -c -r ../ccmd-dist/ccmd.c ./ccmd.c *** ../ccmd-dist/ccmd.c 2002-09-17 07:34:06.000000000 -0700 --- ./ccmd.c 2002-12-10 13:45:59.000000000 -0800 *************** *** 26,31 **** --- 26,32 ---- NULL, /* output to console */ NULL, /* error output */ NULL, /* no prompt set yet */ + NULL, /* no continuation prompt set yet */ NULL, /* no command line buffer yet */ NULL, /* no characters to parse */ 0, /* size of nonexistent command buffer */ *************** *** 345,350 **** --- 346,381 ---- } + /* subprompt + ** + ** Purpose: + ** Initializes a prompt string to be issued to a user after he enters a + ** continuation character (the variable cmcont contains the continuation + ** character). + ** + ** Input arguments: + ** prompt - The prompt string to be issued. The string must be preserved + ** throughout the parsing of the command line, as it will be referenced + ** whenever the command line must be redisplayed (after a help request, + ** when the user types ^R, etc.). In other words, do not pass + ** a pointer to dynamic storage that may be deallocated before parsing + ** is complete. + ** + ** Output arguments: none + ** + ** Returns: Standard return code. + **/ + + int + subprompt(p) + char *p; + { + int ret; + cmcsb._cmrty2 = p; /* save pointer to subprompt string */ + return(CMxOK); /* return success */ + } + + /* parse ** diff -c -r ../ccmd-dist/ccmd.guide ./ccmd.guide *** ../ccmd-dist/ccmd.guide 1990-12-18 10:40:58.000000000 -0800 --- ./ccmd.guide 2002-12-10 14:12:13.000000000 -0800 *************** *** 234,239 **** --- 234,240 ---- FILE * _cmoj; /* file for command output */ FILE * _cmej; /* file for error output */ char * _cmrty; /* pointer to prompt string */ + char * _cmrty2; /* pointer to continuation prompt string */ int * _cmbfp; /* pointer to beginning of user input */ int * _cmptr; /* pointer to beg of next field to parse */ int _cmcnt; /* # of chars in buffer past _cmptr */ *************** *** 747,756 **** anything. Then, if you enter the function and the pointer is non-NULL, you will know you have to free the storage. ! f) prompt(str) char *str; ! This sets up the string that will be used for prompting. It is generally done before the first parse of a command, inside a command parsing loop. --- 748,757 ---- anything. Then, if you enter the function and the pointer is non-NULL, you will know you have to free the storage. ! f) prompt(str) and subprompt(str) char *str; ! This sets up the string(s) that will be used for prompting. It is generally done before the first parse of a command, inside a command parsing loop. *************** *** 760,765 **** --- 761,772 ---- In addition, if cmseti() has not been done it will be automatically called. + subprompt() is used to set the secondary prompt that is displayed for + a command continued on a secord (or later) line. if subprompt() has + not been called, the secondary prompt defaults to the continuation + character, followed by the primary prompt. + + g) fdbchn (fdb1, [ fdbn, ] ... NULL) fdb fdb1, fdbn; diff -c -r ../ccmd-dist/ccmd.h ./ccmd.h *** ../ccmd-dist/ccmd.h 2000-12-06 20:59:44.000000000 -0800 --- ./ccmd.h 2002-12-10 13:47:07.000000000 -0800 *************** *** 95,100 **** --- 95,101 ---- FILE * _cmoj; /* file for command output */ FILE * _cmej; /* file for error output */ char * _cmrty; /* pointer to prompt string */ + char * _cmrty2; /* pointer to continuation prompt string */ int * _cmbfp; /* pointer to beginning of user input */ int * _cmptr; /* pointer to beg of next field to parse */ int _cmcnt; /* # of chars in buffer past _cmptr */ diff -c -r ../ccmd-dist/stdact.c ./stdact.c *** ../ccmd-dist/stdact.c 2002-02-20 00:53:28.000000000 -0800 --- ./stdact.c 2002-12-10 14:00:10.000000000 -0800 *************** *** 340,358 **** int ret; int *end; /* end of current input */ - if (!deferred) - return(CMxDFR); - if (cmcsb._cminc > 0) { /* is there unparsed input? */ end = cmcsb._cmcur - 1; /* point to last char */ if ((*end & CC_QCH) == cmcont) { /* last char continuation char? */ /* (fails if quoted) */ *end |= CC_CSK; /* make it conditionally skipped */ ret = cmsti1(NEWLINE,CC_SKP); /* and stuff a skipped newline */ return(ret); /* no wakeup */ } } if (cmcsb._cmflg & CM_CMT) { /* if inside a comment */ cmcsb._cmflg &= ~CM_CMT; /* then turn off the comment */ } --- 340,368 ---- int ret; int *end; /* end of current input */ if (cmcsb._cminc > 0) { /* is there unparsed input? */ end = cmcsb._cmcur - 1; /* point to last char */ if ((*end & CC_QCH) == cmcont) { /* last char continuation char? */ /* (fails if quoted) */ *end |= CC_CSK; /* make it conditionally skipped */ ret = cmsti1(NEWLINE,CC_SKP); /* and stuff a skipped newline */ + if (cmcsb._cmrty2 != NULL) + { + cmxputs(cmcsb._cmrty2); /* print secondary prompt if any */ + } + else + { + cmxputc(cmcont); /* make secondard prompt: prefix */ + cmxputs(cmcsb._cmrty); /* continuation character to front */ + } /* of primary prompt */ + return(ret); /* no wakeup */ } } + if (!deferred) + return(CMxDFR); + if (cmcsb._cmflg & CM_CMT) { /* if inside a comment */ cmcsb._cmflg &= ~CM_CMT; /* then turn off the comment */ } *************** *** 569,575 **** cmcsb._cmcol = 0; if (cp1 == cmcsb._cmbfp) { /* killed prompt line? */ cmxputs(cmcsb._cmrty); /* then reprompt */ ! } cmcsb._cmcur = cp1; cmcsb._cmcur = disp_forward_char(cp2 - cp1); --- 579,593 ---- cmcsb._cmcol = 0; if (cp1 == cmcsb._cmbfp) { /* killed prompt line? */ cmxputs(cmcsb._cmrty); /* then reprompt */ ! } else if (cmcsb._cmrty2 != NULL) /* do we have a secondary prompt? */ ! { ! cmxputs(cmcsb._cmrty2); /* yes, print it */ ! } ! else ! { ! cmxputc(cmcont); /* no, build one, prefix cont. char */ ! cmxputs(cmcsb._cmrty); /* in front of primary prompt */ ! } cmcsb._cmcur = cp1; cmcsb._cmcur = disp_forward_char(cp2 - cp1); From fdc@columbia.edu Thu Jan 15 11:32:08 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0FGW62N018081; Thu, 15 Jan 2004 11:32:06 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0FGW59Y014137; Thu, 15 Jan 2004 11:32:05 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id i0FGW5LE014136; Thu, 15 Jan 2004 11:32:05 -0500 (EST) Date: Thu, 15 Jan 2004 11:32:05 EST From: Frank da Cruz To: Schuyler Duveen Cc: Melissa Metz , bug-mm@columbia.edu Subject: Re: mm feature request In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 201 > Did this ever get put into the production MM version (on new cunix)? It > seems like MM users still have the old "In-Reply-To:" format. > I dunno. I've been using the updated binary since Oct 27th; it's still where I said it was then: > > This reply is sent by MM 0.91(157), which does it Pine-style. The binary > > is in ~fdc/bin.solaris/mm if you want to try it. Let me know if it's OK. > As you can see, it makes the new-style In-Reply-To. I can hack the code, but I can't install the application. - Frank From melissa@columbia.edu Thu Jan 15 12:00:31 2004 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0FH0T7m027688; Thu, 15 Jan 2004 12:00:29 -0500 (EST) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0FH0T79008721; Thu, 15 Jan 2004 12:00:29 -0500 (EST) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id i0FH0TpV008720; Thu, 15 Jan 2004 12:00:29 -0500 (EST) Date: Thu, 15 Jan 2004 12:00:29 EST From: Melissa Metz To: Frank da Cruz Cc: Schuyler Duveen , Melissa Metz , bug-mm@columbia.edu Subject: Re: mm feature request In-Reply-To: Your message of Thu, 15 Jan 2004 11:32:05 EST Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 202 > > Did this ever get put into the production MM version (on new cunix)? It > > seems like MM users still have the old "In-Reply-To:" format. > > > I dunno. I've been using the updated binary since Oct 27th; it's still > where I said it was then: > > > > This reply is sent by MM 0.91(157), which does it Pine-style. The binary > > > is in ~fdc/bin.solaris/mm if you want to try it. Let me know if it's OK. > > > As you can see, it makes the new-style In-Reply-To. I can hack the code, > but I can't install the application. > > - Frank > Sorry I dopped this. I'll try to install it today. --Melissa From fdc@columbia.edu Tue Jan 20 13:25:06 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0KIP5Y6003229; Tue, 20 Jan 2004 13:25:05 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0KIP59Y019342; Tue, 20 Jan 2004 13:25:05 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id i0KIP5am019341; Tue, 20 Jan 2004 13:25:05 -0500 (EST) Date: Tue, 20 Jan 2004 13:25:05 EST From: Frank da Cruz To: Melissa Metz Subject: Re: this is happening again... In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 203 > Maybe your spool file *is* busy -- maybe mail is being delivered? > OK, I looked at the code -- if the fcntcl(...F_SETLK...) (or equivalent flock()) fails, MM prints "already locked", without checking the failure reason. I suppose if this starts bothering me enough, I can add some code at these spots to get a better message. - Frank From fdc@columbia.edu Tue Jan 20 16:33:43 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by tepin.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0KLXfqu017473; Tue, 20 Jan 2004 16:33:42 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0KLXf9Y011361; Tue, 20 Jan 2004 16:33:41 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id i0KLXflg011360; Tue, 20 Jan 2004 16:33:41 -0500 (EST) Date: Tue, 20 Jan 2004 16:33:41 EST From: Frank da Cruz To: Melissa Metz Subject: Re: this is happening again... In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 204 > Is MM reading your spool file directly? Doesn't it fork up movemail > to move your spool to ~/tmp/something? > It forks up movemail. I changed my private copy of movemail to print the errno if this happens again. I assume MM will fork this copy if it is ahead of the regular one in my PATH. - Frank From fdc@columbia.edu Tue Jan 20 17:25:35 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0KMPXQM023038; Tue, 20 Jan 2004 17:25:34 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0KMPX9Y017511; Tue, 20 Jan 2004 17:25:33 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id i0KMPX07017510; Tue, 20 Jan 2004 17:25:33 -0500 (EST) Date: Tue, 20 Jan 2004 17:25:33 EST From: Frank da Cruz To: Melissa Metz Subject: Re: this is happening again... In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 205 > Do you think maybe you are actually receiving new mail when it is > busy? > No. It is stuck (but visible) in the spool, and MM is not getting it, not even if I say "check" -- it (or, rather, movemail) just gives the "already locked" message. - Frank From fdc@columbia.edu Wed Jan 21 11:14:11 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0LGE8QM008824; Wed, 21 Jan 2004 11:14:08 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0LGE79Y019602; Wed, 21 Jan 2004 11:14:07 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id i0LGE7kb019601; Wed, 21 Jan 2004 11:14:07 -0500 (EST) Date: Wed, 21 Jan 2004 11:14:07 EST From: Frank da Cruz To: Melissa Metz Subject: Re: this is happening again... In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 206 > > > Do you think maybe you are actually receiving new mail when it is > > > busy? > > > > > No. It is stuck (but visible) in the spool, and MM is not getting it, > > not even if I say "check" -- it (or, rather, movemail) just gives the > > "already locked" message. > > I didn't mean, MM is receiving new mail, I meant maybe > sendmail/procmail is delivering new mail into your spool. ?? > Yes, it is. I can see messages added to the spool in one window, while MM in the other window is saying "already locked" and can't get them. Maybe you could take the new copy of movemail out of ~fdc/mm/work/mm/movemail and put it somewhere in the movemail path so we can get the errno next time this happens? - Frank From fdc@columbia.edu Wed Jan 21 11:46:12 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0LGk9QM020295; Wed, 21 Jan 2004 11:46:12 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0LGk99Y023452; Wed, 21 Jan 2004 11:46:09 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id i0LGk9jc023451; Wed, 21 Jan 2004 11:46:09 -0500 (EST) Date: Wed, 21 Jan 2004 11:46:09 EST From: Frank da Cruz To: Melissa Metz Subject: Re: this is happening again... In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 207 > You can just set your movemail-path to /p/kd/fdc/mm/work/mm/movemail. > Oops, sorry to be dense. Done. > My point is that if procmail is delivering mail to your file while > MM/movemail is trying to read it, it is correct for procmail to lock > the file and MM to respect the lock. That is the point of locking. > > That would make the question "why are you noticing the procmail locks > more lately?" and then I would tie it to the new procmail recently > installed. > OK. I don't think it's what you said because the condition usually lasts a minute or two. Next time it happens at least I'll see the errno. Thanks! - Frank From fdc@columbia.edu Fri Jan 23 15:29:47 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0NKTiws008212; Fri, 23 Jan 2004 15:29:44 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0NKTh9Y014150; Fri, 23 Jan 2004 15:29:44 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.10/8.12.8/Submit) id i0NKThbf014148; Fri, 23 Jan 2004 15:29:43 -0500 (EST) Date: Fri, 23 Jan 2004 15:29:43 EST From: Frank da Cruz To: Melissa Metz Subject: Caught in the act Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 208 (bringing MM to the foreground from being suspended...) mm /var/spool/mail/f/d/fdc: set lock failed (fcntl errno=11) MM> #define EAGAIN 11 /* Resource temporarily unavailable */ This is different from what happened yesterday, which was an open() failure. - Frank From melissa@columbia.edu Wed Jan 21 16:22:52 2004 Flags: 000000000001 Return-Path: Received: from broccoli.cc.columbia.edu (broccoli.cc.columbia.edu [128.59.39.153]) by marionberry.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0LLMqWS012776; Wed, 21 Jan 2004 16:22:52 -0500 (EST) Received: from broccoli.cc.columbia.edu (localhost [127.0.0.1]) by broccoli.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id i0LLMp79013196; Wed, 21 Jan 2004 16:22:51 -0500 (EST) Received: (from melissa@localhost) by broccoli.cc.columbia.edu (8.12.10/8.12.3/Submit) id i0LLMpfs013195; Wed, 21 Jan 2004 16:22:51 -0500 (EST) Date: Wed, 21 Jan 2004 16:22:51 EST From: Melissa Metz To: Frank da Cruz Cc: Melissa Metz Subject: Re: this is happening again... In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Status: O X-Status: X-Keywords: X-UID: 209 > > You can just set your movemail-path to /p/kd/fdc/mm/work/mm/movemail. > > > Oops, sorry to be dense. Done. > > > My point is that if procmail is delivering mail to your file while > > MM/movemail is trying to read it, it is correct for procmail to lock > > the file and MM to respect the lock. That is the point of locking. > > > > That would make the question "why are you noticing the procmail locks > > more lately?" and then I would tie it to the new procmail recently > > installed. > > > OK. I don't think it's what you said because the condition usually lasts > a minute or two. Next time it happens at least I'll see the errno. > > Thanks! > > - Frank > What if you put your mail in another file, as I do? A .procmailrc to do this would look something like this: # copy all mail to ~/MAIL/incoming :0 c * incoming I think this would let another copy of each message "fall through" to your spool file. Then if you "set incoming-mail /p/kd/fdc/MAIL/incoming" MM will read it from there. I am pretty sure this would fix your error, though it does not avoid NFS or procmail. But it works for me. I don't suggest this as a permanent solution, but as another data point. --Melissa From fdc@columbia.edu Mon Mar 8 16:54:43 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by pecan.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i28LsVGE027368; Mon, 8 Mar 2004 16:54:31 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.12.11/8.12.10) with ESMTP id i28LsVxS011547; Mon, 8 Mar 2004 16:54:31 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.12.11/8.12.8/Submit) id i28LsVu1011542; Mon, 8 Mar 2004 16:54:31 -0500 (EST) Date: Mon, 8 Mar 2004 16:54:31 EST From: Frank da Cruz To: Melissa Metz Cc: selsky@columbia.edu, brennan@columbia.edu, melissa@columbia.edu, sky@columbia.edu Subject: Re: install new MM In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.39 Status: O X-Status: X-Keywords: X-UID: 210 > I have been trying to remember to install a new MM for weeks now, but > I am no good at it (even after you have repeatedly told me how to run > Opium). I think I've been testing the new MM, but I'm not sure. My > copy is from Oct 27. I was confused by /master/opt/ACISmm/bin/mm.new, > which is from Oct 17. Then again, /opt/local/bin/mm on cunix is from > Oct 20 and doesn't have the new behavior Sky requested (RFC compliant > In-Reply-To). So maybe I do have the right new version. > > Can you work with Frank to get the new version installed, not on a > Monday or a Friday? If you tell me when you're doing it I will notify > acsc-ft and emailgroup for good measure. > Columbia MM, version 0.91.0(157) Copyright (c) 1986, 2003 The Trustees of Columbia University in the City of New York Compiled by fdc@sesame on 27 Oct 2003 1:02pm You can find a copy in /p/kd/fdc/bin.solaris/mm. - Frank From eric@columbia.edu Thu Apr 22 07:48:04 2004 Flags: 000000000015 Return-Path: Received: from papaya.cc.columbia.edu (localhost [127.0.0.1]) by papaya.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i3MBm3pC025006; Thu, 22 Apr 2004 07:48:03 -0400 (EDT) Received: (from eric@localhost) by papaya.cc.columbia.edu (8.12.11/8.12.3/Submit) id i3MBm3T5025005; Thu, 22 Apr 2004 07:48:03 -0400 (EDT) Date: Thu, 22 Apr 2004 7:48:02 EDT From: Eric Weaver To: bug-mm@columbia.edu Cc: eric@columbia.edu Subject: [sys@rg03.ais.columbia.edu: New system errors for rg03 as of 04-21-2004 09:30PM] Message-ID: Status: O X-Status: X-Keywords: X-UID: 211 I think MM's sense of which day is it was messed up by the change to Daylight Saving Time... The message below should be "yesterday", but it is listed when I get a list of messages for "today". Am I missing something? /Eric --------------- Return-Path: Received: from cuvmc.ais.columbia.edu (cuvmc1.ais.columbia.edu [128.59.213.2]) by dewberry.cc.columbia.edu (8.12.11/8.12.11) with SMTP id i3M1U3rr022991; Wed, 21 Apr 2004 21:30:03 -0400 (EDT) Received: by cuvmc.ais.columbia.edu (IBM VM SMTP Level 310) via spool with SMTP id 1452 ; Wed, 21 Apr 2004 21:29:35 EST Received: from CUVMC.AIS.COLUMBIA.EDU (NJE origin LISTSERV@CUVMC) by CUVMC.AIS.COLUMBIA.EDU (LMail V1.2c/1.8c) with BSMTP id 2370; Wed, 21 Apr 2004 21:29:36 -0500 Received: from CUVMC.AIS.COLUMBIA.EDU by CUVMC.AIS.COLUMBIA.EDU (LISTSERV-TCP/IP release 1.8e) with spool id 4727 for AIXADMIN@CUVMC.AIS.COLUMBIA.EDU; Wed, 21 Apr 2004 21:29:36 -0500 Received: from CUVMC (NJE origin SMTPE@CUVMC) by CUVMC.AIS.COLUMBIA.EDU (LMail V1.2c/1.8c) with BSMTP id 2368; Wed, 21 Apr 2004 21:29:36 -0500 Received: from pomegranate.cc.columbia.edu [128.59.59.134] by cuvmc.ais.columbia.edu (IBM VM SMTP Level 310) via TCP with SMTP ; Wed, 21 Apr 2004 21:29:35 EST Received: from rg03.ais (rg03.ais.columbia.edu [128.59.213.153]) by pomegranate.cc.columbia.edu (8.12.11/8.12.8) with ESMTP id i3M1U3D9025887 for ; Wed, 21 Apr 2004 21:30:03 -0400 (EDT) Received: (from sys@localhost) by rg03.ais (AIX5.1/8.11.6p2/8.11.0) id i3M1U2q51270 for aixadmin@cuvmc.ais.columbia.edu; Wed, 21 Apr 2004 21:30:02 -0400 Date: Wed, 21 Apr 2004 21:30:02 -0400 From: sys@rg03.ais.columbia.edu Message-Id: <200404220130.i3M1U2q51270@rg03.ais> To: aixadmin@CUVMC.AIS.COLUMBIA.EDU Subject: New system errors for rg03 as of 04-21-2004 09:30PM X-Spam-Score: 1.133 (*) NO_REAL_NAME UPPERCASE_50_75 X-Scanned-By: MIMEDefang 2.40 Sender: owner-aixadmin@CUVMC.AIS.COLUMBIA.EDU Precedence: list X-No-Spam-Score: Local IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION ---------------------------------------------------- 5DFED6F1 0421211704 I O SYSPFS UNABLE TO ALLOCATE SPACE IN FILE SYSTEM From fdc@columbia.edu Thu Aug 26 11:03:15 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i7QF3DCl004402; Thu, 26 Aug 2004 11:03:13 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.12.11) with ESMTP id i7QF3DeI005813; Thu, 26 Aug 2004 11:03:13 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id i7QF3Dqj005812; Thu, 26 Aug 2004 11:03:13 -0400 (EDT) Date: Thu, 26 Aug 2004 11:03:13 EDT From: Frank da Cruz To: Linda Wallinger Cc: bug-mm@columbia.edu, postmaster@columbia.edu, unixsys@columbia.edu Subject: Re: lost mail ,,cs In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Status: O X-Status: X-Keywords: X-UID: 212 Linda Wallinger wrote: > There are only two people who support user MM problems, Joe Brennan and I. > Joe is on vacation, and I was out Friday and Monday. Sooner or later the > window for restorals will close with you and MM. MM requires knowledge of > unix to recover from its unique way of saving mail during crashes. You > are not able to do this. You need to change now to another mail program; > no other program behaves this way. It is great for those who know how to > fix things, totally mysterious to those who do not. Luckily there is a > snapshot of your inbox from Aug 21 at 19:08. I put it in a file called > mbox-aug21. Sooner or later MM will be removed from cunix hosts, so make > the transition to something else like Pine now. > What exactly should MM do differently? Why are these people losing their mail? Maybe I can do something about it. What does Pine do? The main problem with MM that I'm aware of is the stale lock problem, which could be fixed by letting people know about the "onall" script to hunt down and kill -HUP the disconnected MM process. If we could put the onall script in a public place and commit to leaving it there, I could add code to MM to tell people to exit MM, run the script, and restart MM if it gets a locked mailbox (actually running the script from MM might be counterproductive :-) - Frank From lindaw@columbia.edu Thu Aug 26 11:47:07 2004 Flags: 000000000001 Return-Path: Received: from walnut.cc.columbia.edu (walnut.cc.columbia.edu [128.59.59.124]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i7QFl5hl014549; Thu, 26 Aug 2004 11:47:05 -0400 (EDT) Received: from walnut.cc.columbia.edu (localhost [127.0.0.1]) by walnut.cc.columbia.edu (8.13.0/8.12.11) with ESMTP id i7QFl53h005378; Thu, 26 Aug 2004 11:47:05 -0400 (EDT) Received: (from lindaw@localhost) by walnut.cc.columbia.edu (8.13.0/8.12.3/Submit) id i7QFl57u005377; Thu, 26 Aug 2004 11:47:05 -0400 (EDT) Date: Thu, 26 Aug 2004 11:47:05 EDT From: Linda Wallinger To: Frank da Cruz Cc: Linda Wallinger , bug-mm@columbia.edu, postmaster@columbia.edu, unixsys@columbia.edu Subject: Re: lost mail ,,cs In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Status: O X-Status: X-Keywords: X-UID: 213 > Linda Wallinger wrote: > > > There are only two people who support user MM problems, Joe Brennan and I. > > Joe is on vacation, and I was out Friday and Monday. Sooner or later the > > window for restorals will close with you and MM. MM requires knowledge of > > unix to recover from its unique way of saving mail during crashes. You > > are not able to do this. You need to change now to another mail program; > > no other program behaves this way. It is great for those who know how to > > fix things, totally mysterious to those who do not. Luckily there is a > > snapshot of your inbox from Aug 21 at 19:08. I put it in a file called > > mbox-aug21. Sooner or later MM will be removed from cunix hosts, so make > > the transition to something else like Pine now. > > > What exactly should MM do differently? Why are these people losing their > mail? Maybe I can do something about it. What does Pine do? > > The main problem with MM that I'm aware of is the stale lock problem, > which could be fixed by letting people know about the "onall" script to > hunt down and kill -HUP the disconnected MM process. If we could put the > onall script in a public place and commit to leaving it there, I could add > code to MM to tell people to exit MM, run the script, and restart MM if > it gets a locked mailbox (actually running the script from MM might be > counterproductive :-) > > - Frank > They don't lose their mail if they know how to compare #mbox# with mbox, or mbox.xxxx with mbox, and make the most complete file the mbox. There is a killme script but it doesn't always work, and most people now don't know enough unix to recover from all this, especially this particular person. She is now pretty much the only person having problems but she has problems every week or so, so rather than changing MM, we need to change her :) /Linda From brennan@columbia.edu Fri Aug 27 10:20:06 2004 Flags: 000000000011 Return-Path: Received: from alpha.cc.columbia.edu (alpha.cc.columbia.edu [128.59.39.120]) (user=brennan mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i7REK1SK017267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Aug 2004 10:20:03 -0400 (EDT) Date: Fri, 27 Aug 2004 10:21:05 -0400 From: Joseph Brennan To: Frank da Cruz , Linda Wallinger cc: bug-mm@columbia.edu, postmaster@columbia.edu, unixsys@columbia.edu Subject: Re: lost mail ,,cs Message-ID: <2147483647.1093602065@alpha.cc.columbia.edu> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Status: O X-Status: X-Keywords: X-UID: 214 --On Thursday, August 26, 2004 11:03 AM -0400 Frank da Cruz wrote: > Linda Wallinger wrote: > >> There are only two people who support user MM problems, Joe Brennan and >> I. Joe is on vacation, and I was out Friday and Monday. Sooner or later >> the window for restorals will close with you and MM. MM requires >> knowledge of unix to recover from its unique way of saving mail during >> crashes. You are not able to do this. You need to change now to >> another mail program; no other program behaves this way. It is great >> for those who know how to fix things, totally mysterious to those who do >> not. Luckily there is a snapshot of your inbox from Aug 21 at 19:08. I >> put it in a file called mbox-aug21. Sooner or later MM will be removed >> from cunix hosts, so make the transition to something else like Pine now. >> > What exactly should MM do differently? Why are these people losing their > mail? Maybe I can do something about it. What does Pine do? > > The main problem with MM that I'm aware of is the stale lock problem, > which could be fixed by letting people know about the "onall" script to > hunt down and kill -HUP the disconnected MM process. If we could put the > onall script in a public place and commit to leaving it there, I could add > code to MM to tell people to exit MM, run the script, and restart MM if > it gets a locked mailbox (actually running the script from MM might be > counterproductive :-) > > - Frank Within a year mail will be accessible only with POP and IMAP clients. MM could conceivably run as a POP client to collect new mail and then maintain its own local mailboxes, but that would be wildly incompatible with everything else. Joe From alan@columbia.edu Fri Aug 27 10:59:36 2004 Flags: 000000000001 Return-Path: Received: from [128.59.39.150] (curta.cc.columbia.edu [128.59.39.150]) (user=alan mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i7RExYZl025825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Aug 2004 10:59:34 -0400 (EDT) Message-ID: <412F4C56.7020805@columbia.edu> Date: Fri, 27 Aug 2004 10:59:34 -0400 From: Alan Crosswell User-Agent: Mozilla Thunderbird 0.7 (X11/20040615) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Brennan CC: Frank da Cruz , Linda Wallinger , bug-mm@columbia.edu, postmaster@columbia.edu, unixsys@columbia.edu Subject: Re: lost mail ,,cs References: <2147483647.1093602065@alpha.cc.columbia.edu> In-Reply-To: <2147483647.1093602065@alpha.cc.columbia.edu> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Status: O X-Status: X-Keywords: X-UID: 215 MM uses movemail which there are IMAP versions of. /a Joseph Brennan wrote: > > > --On Thursday, August 26, 2004 11:03 AM -0400 Frank da Cruz > wrote: > >> Linda Wallinger wrote: >> >>> There are only two people who support user MM problems, Joe Brennan and >>> I. Joe is on vacation, and I was out Friday and Monday. Sooner or later >>> the window for restorals will close with you and MM. MM requires >>> knowledge of unix to recover from its unique way of saving mail during >>> crashes. You are not able to do this. You need to change now to >>> another mail program; no other program behaves this way. It is great >>> for those who know how to fix things, totally mysterious to those who do >>> not. Luckily there is a snapshot of your inbox from Aug 21 at 19:08. I >>> put it in a file called mbox-aug21. Sooner or later MM will be removed >>> from cunix hosts, so make the transition to something else like Pine >>> now. >>> >> What exactly should MM do differently? Why are these people losing their >> mail? Maybe I can do something about it. What does Pine do? >> >> The main problem with MM that I'm aware of is the stale lock problem, >> which could be fixed by letting people know about the "onall" script to >> hunt down and kill -HUP the disconnected MM process. If we could put the >> onall script in a public place and commit to leaving it there, I could >> add >> code to MM to tell people to exit MM, run the script, and restart MM if >> it gets a locked mailbox (actually running the script from MM might be >> counterproductive :-) >> >> - Frank > > > > > Within a year mail will be accessible only with POP and IMAP clients. > > MM could conceivably run as a POP client to collect new mail and then > maintain its own local mailboxes, but that would be wildly incompatible > with everything else. > > Joe > From fdc@columbia.edu Fri Aug 27 11:00:05 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i7RF01up007075; Fri, 27 Aug 2004 11:00:01 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.12.11) with ESMTP id i7RF01aq026700; Fri, 27 Aug 2004 11:00:01 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id i7RF00Yr026687; Fri, 27 Aug 2004 11:00:00 -0400 (EDT) Date: Fri, 27 Aug 2004 11:00:00 EDT From: Frank da Cruz To: Joseph Brennan Cc: Linda Wallinger , bug-mm@columbia.edu, postmaster@columbia.edu, unixsys@columbia.edu Subject: Re: lost mail ,,cs In-Reply-To: <2147483647.1093602065@alpha.cc.columbia.edu> Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Status: O X-Status: X-Keywords: X-UID: 216 > Within a year mail will be accessible only with POP and IMAP clients. > You're kidding, I hope. POP and IMAP and authenticated SMTP are obviously needed for those who want to use desktop email clients, but if I'm logged in to a central host, I'm already authenticated. What problem are we trying to solve? > MM could conceivably run as a POP client to collect new mail and then > maintain its own local mailboxes, but that would be wildly incompatible > with everything else. > Everything else is wildly incompatible with MM! I don't think we should be in the business of constantly forcing people to change the way they use our services -- at least not any more than can be avoided. I realize I'm in a minority whose size is rapidly shrinking to 1, but the tools I use are the ones that let me work fast, as a touch typist -- no grovelling through menus, no taking my hands away from the home keys to use a mouse or even arrow or function keys. We should not discriminate against people who want to use computers efficiently and safely. - Frank From brennan@columbia.edu Fri Aug 27 11:20:51 2004 Flags: 000000000001 Return-Path: Received: from alpha.cc.columbia.edu (alpha.cc.columbia.edu [128.59.39.120]) (user=brennan mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i7RFKlqJ011320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Aug 2004 11:20:49 -0400 (EDT) Date: Fri, 27 Aug 2004 11:21:51 -0400 From: Joseph Brennan To: Frank da Cruz cc: Linda Wallinger , bug-mm@columbia.edu, postmaster@columbia.edu, unixsys@columbia.edu Subject: Re: lost mail ,,cs Message-ID: <2147483647.1093605711@alpha.cc.columbia.edu> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Status: O X-Status: X-Keywords: X-UID: 217 --On Friday, August 27, 2004 11:00 AM -0400 Frank da Cruz wrote: >> Within a year mail will be accessible only with POP and IMAP clients. >> > You're kidding, I hope. POP and IMAP and authenticated SMTP are obviously > needed for those who want to use desktop email clients, but if I'm logged > in to a central host, I'm already authenticated. What problem are we > trying to solve? Efficiency, which we get by using an indexed file format, which in turn requires local disks not NFS. Same solution also handles simultaneous access by multiple clients which is getting more common. Joe From ed2019@columbia.edu Fri Aug 27 11:29:12 2004 Flags: 000000000001 Return-Path: Received: from columbia.edu (oslo.cc.columbia.edu [128.59.31.51]) (user=ed2019 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i7RFT9DU028519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Aug 2004 11:29:10 -0400 (EDT) Message-ID: <412F5346.6030406@columbia.edu> Date: Fri, 27 Aug 2004 11:29:10 -0400 From: Erik Dykema User-Agent: Mozilla Thunderbird 0.5 (X11/20040306) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank da Cruz CC: Joseph Brennan , Linda Wallinger , bug-mm@columbia.edu, postmaster@columbia.edu, unixsys@columbia.edu Subject: Re: lost mail ,,cs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Status: O X-Status: X-Keywords: X-UID: 218 Frank da Cruz wrote: >>Within a year mail will be accessible only with POP and IMAP clients. >> > > You're kidding, I hope. POP and IMAP and authenticated SMTP are obviously > needed for those who want to use desktop email clients, but if I'm logged in > to a central host, I'm already authenticated. What problem are we trying > to solve? An analysis and discussion of the e-mail situation is maintained here: https://www1.columbia.edu/sec/acis/emailtech/storage.html There are a lot of issues with the present system that new proposals seek to address. If you really don't want to use an IMAP client, you could forward your mail to a personal SMTP server, where you could read it with MM. >>MM could conceivably run as a POP client to collect new mail and then >>maintain its own local mailboxes, but that would be wildly incompatible >>with everything else. > > Everything else is wildly incompatible with MM! > > I don't think we should be in the business of constantly forcing people to > change the way they use our services -- at least not any more than can be > avoided. I think that AcIS operates in exactly the opposite fashion from what you have described. I personally am astonished that we are STILL supporting MM, the original version of which was written in 1978. (according to our own documentation here: http://www.columbia.edu/acis/email/mm.home/mmmanual/8.about.mm.html . In a business where 2 years = obselete, 25 years is a long time.. erik From fdc@columbia.edu Fri Aug 27 11:29:49 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i7RFTl9W028637; Fri, 27 Aug 2004 11:29:47 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.12.11) with ESMTP id i7RFTlZN000183; Fri, 27 Aug 2004 11:29:47 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id i7RFTkFq000182; Fri, 27 Aug 2004 11:29:46 -0400 (EDT) Date: Fri, 27 Aug 2004 11:29:46 EDT From: Frank da Cruz To: Vace Kundakci CC: Joseph Brennan , Linda Wallinger , bug-mm@columbia.edu, postmaster@columbia.edu, unixsys@columbia.edu Subject: Re: lost mail ,,cs In-Reply-To: <412F50F6.5030805@columbia.edu> Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Status: O X-Status: X-Keywords: X-UID: 219 > You are very much in the minority. Access to mbox from unix is a > thing of the past, or will be. You could move your messages from > whatever closed box we run to unix space as you wish. /V > Alan says movemail can use IMAP, so that should do the trick, no? And transparently, too. It's a lot less disruptive than telling people to get off MM (even if there aren't many left). I have no idea how many people still use it, but you'll never really know until you break it. I learned this many years ago, when trying to free up disk space on the DEC-20. PS: contained all kinds of stuff that I didn't even know what it was, and that had low access counts, so I deleted/expunged it. Within THIRTY SECONDS my phone started ringing :-) Does Pine use movemail? If so then no worries, right? If not, I'll be glad to do any work needed to make movemail do what's needed, if nobody else was going to do it. - Frank From fdc@columbia.edu Fri Aug 27 12:30:52 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i7RGUqu3009746 for ; Fri, 27 Aug 2004 12:30:52 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.12.11) with ESMTP id i7RGUnEe007325; Fri, 27 Aug 2004 12:30:49 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id i7RGUnWT007324; Fri, 27 Aug 2004 12:30:49 -0400 (EDT) Date: Fri, 27 Aug 2004 12:30:49 EDT From: Frank da Cruz To: Mark Crispin Subject: Movemail? Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Status: O X-Status: X-Keywords: X-UID: 220 Hi Mark, what's up? Do you know of a version of movemail that uses IMAP? Or any other movemail-like program that does? Our local copy of movemail just copies stuff out of the spool directories, but those are going to be shut off at some point. Thanks! - Frank From lev@columbia.edu Fri Aug 27 11:50:26 2004 Flags: 000000000001 Return-Path: Received: from crenshaw.cc.columbia.edu (crenshaw.cc.columbia.edu [128.59.59.48]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i7RFoPYl016674; Fri, 27 Aug 2004 11:50:25 -0400 (EDT) Received: from crenshaw.cc.columbia.edu (localhost [127.0.0.1]) by crenshaw.cc.columbia.edu (8.13.0/8.12.11) with ESMTP id i7RFoOdp028938; Fri, 27 Aug 2004 11:50:24 -0400 (EDT) Received: (from lev@localhost) by crenshaw.cc.columbia.edu (8.13.0/8.12.8/Submit) id i7RFoONH028935; Fri, 27 Aug 2004 11:50:24 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16687.22592.638279.371578@crenshaw.cc.columbia.edu> Date: Fri, 27 Aug 2004 11:50:24 -0400 From: Lev Givon To: Frank da Cruz Cc: Joseph Brennan , Linda Wallinger , bug-mm@columbia.edu, postmaster@columbia.edu, unixsys@columbia.edu Subject: Re: lost mail ,,cs In-Reply-To: References: <2147483647.1093602065@alpha.cc.columbia.edu> X-Mailer: VM 7.18 under Emacs 21.3.1 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Status: O X-Status: X-Keywords: X-UID: 221 Received from fdc@columbia.edu on August 27, 2004: (snip) > > I realize I'm in a minority whose size is rapidly shrinking to 1, but the > tools I use are the ones that let me work fast, as a touch typist -- no > grovelling through menus, no taking my hands away from the home keys to use > a mouse or even arrow or function keys. We should not discriminate against > people who want to use computers efficiently and safely. > There are a number of console email clients (e.g., Mutt, VM) around that can access IMAP folders and support customizable keyboard shortcuts and functions. > - Frank L.G. From fdc@columbia.edu Fri Sep 10 14:38:31 2004 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id i8AIcV3q019630 for ; Fri, 10 Sep 2004 14:38:31 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.12.11) with ESMTP id i8AIV1XC001180; Fri, 10 Sep 2004 14:31:01 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id i8AIV1DV001179; Fri, 10 Sep 2004 14:31:01 -0400 (EDT) Date: Fri, 10 Sep 2004 14:31:01 EDT From: Frank da Cruz To: Subject: Re: Re[5]: Ivan In-Reply-To: <0409101094.AA1094843741@ws3.cimex.com.cu> Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Status: O X-Status: X-Keywords: X-UID: 222 > ... but our high levels decided change ccmail by ms exchage ......... > But I thought Cubans were more intelligent than Americans! :-) > i will be le LAST user of ccmail, then i will pass to pine in linux > btw, which mail client do you use in unix? > It's called MM. It was written by my group 20 years ago :-) I am one of the last people in the world who still uses it, and I maintain it myself. I talk about it a little bit in here: http://www.columbia.edu/kermit/safe.html and in here: http://www.columbia.edu/kermit/dec20.html There is some documentation (not by me) here: http://www.columbia.edu/acis/email/mm/index.html and you can download it here: ftp://kermit.columbia.edu/kermit/mm/ I think this is the latest tarball: ftp://kermit.columbia.edu/kermit/mm/mm-ccmd-0.91-20031017.tar.gz I like it because I don't have to use menus, arrow keys, F-keys or anything like that, just ascii keys. This is good for me because I type very fast if I don't have to take my hands away from the main keyboard. MM is very powerful for storing and retrieving messages, like a database, but It doesn't understand attachments at all. But I like that :-) Recently I fixed it to allow 8-bit bytes for ISO 8859-1 and UTF-8 (or any other character set) so I can send and view mail in Spanish, Russian, etc. I also added a "download" command so I can send messages to my PC in case I want to view the attachments (after I know they are safe). It uses Kermit for downloading, of course. - Frank From fdc@columbia.edu Mon Mar 28 10:49:23 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j2SFnLkm016324; Mon, 28 Mar 2005 10:49:21 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j2SFnLwH006972; Mon, 28 Mar 2005 10:49:21 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id j2SFnLQN006971; Mon, 28 Mar 2005 10:49:21 -0500 (EST) Date: Mon, 28 Mar 2005 10:49:21 EST From: Frank da Cruz To: Eric Weaver Cc: bug-mm@columbia.edu, eric@columbia.edu Subject: Re: intermittent bug regarding previous In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: O X-Status: X-Keywords: X-UID: 223 > There's some bug relating to the use of "previous". I haven't yet > isolated it well, but I'll share what I have ... maybe someone else has > experienced it. Maybe it is related to the termcap definitions and > characters. Anyway... > Sounds like it. What do you have on your desktop, that you're using for a terminal? What kind of terminal is it emulating (if it isn't a real HP-2621 :-) ? What kind of terminal does the host think you have? > When I'm reading through a sequence (not necessarily numerically > sequential) of messages, and I then do "prev" to go backward, sometimes at > the "first" message it will cause mm to hang, not accept any more input. > What happens if you type Ctrl-Q? > Pressing RETURN (or ENTER) simply causes the cursor to go down one line, > but the prompt does not return. Pressing Ctrl-C does bring up the message > allowing one to exit from MM, but that means I lose my changes. Once in > this prev-related limbo there's no way to resume working within that same > instance of MM. > I am, as yet, unable to reproduce this problem, so either it is > intermittent or there's some co-requisite trigger/catalyst of which I'm > not yet aware. When I have more information or am able to reproduce the > problem, I'll let you know. > Oh, maybe useful: whenever I do "prev" at the "first" message of a > sequence, the cmd parser spits out "pr" on the subsequent prompt. Ex: > > Read>prev > ?Already at start of sequence > Read>pr > That's probably unrelated. From beebe@math.utah.edu Wed Jul 13 19:00:25 2005 Flags: 000000000011 Return-Path: Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by feta.cc.columbia.edu (8.13.0/8.13.0) with SMTP id j6DN0NvG010542; Wed, 13 Jul 2005 19:00:23 -0400 (EDT) Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jul 2005 15:52:53 -0700 (PDT) Received: from psi.math.utah.edu (IDENT:uGzQREC1kFxJnW8Hp0W2V0po8kxnZmgH@psi.math.utah.edu [155.101.96.19]) by sunshine.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6DMqlAM025316; Wed, 13 Jul 2005 16:52:47 -0600 (MDT) Received: from psi.math.utah.edu (IDENT:Cm6ruIG/LvrweNQHA+erTOzu6N0piS+8@localhost [127.0.0.1]) by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6DMqlm1008431; Wed, 13 Jul 2005 16:52:47 -0600 (MDT) Received: (from beebe@localhost) by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j6DMqlK6008429; Wed, 13 Jul 2005 16:52:47 -0600 (MDT) Date: Wed, 13 Jul 2005 16:52:47 -0600 (MDT) From: "Nelson H. F. Beebe" To: tops-20@lingling.panda.com Cc: beebe@math.utah.edu X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: News of mm Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine.math.utah.edu [128.110.198.2]); Wed, 13 Jul 2005 16:52:47 -0600 (MDT) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.164 Status: O X-Status: X-Keywords: X-UID: 224 Back in 1986--1990, at Columbia University (CUCCA) Howie Kaye and Andrew Lowry prepared ccmd, a C implementation of the TOPS-20 COMND% JSYS. With this code available, Chris Maio, Fuat Baran, Howie Kaye and Melissa Metz translated Mark Crispin's mm from PDP-10 assembly code to C, and so Columbia-MM was born. We have used this code at Utah since at least 1990 on our Sun SunOS and Solaris systems, but it is not been buildable on most other flavors of Unix (we have 20+ in our software development lab). In October 1998, I spent time examining the ccmd and mm code to see whether I could make it 8-bit clean. I wrote then: >> ... >> I make some experiments today in a several-hour-long session to see >> whether mm could be made 8-bit clean, so that mail messages in the ISO >> 8859-n character sets could be successfully sent and received. >> >> In summary, the answer is a RESOUNDING NO! >> >> Sadly, the assumptions about 7-bit characters run deep into both mm >> and ccmd. In ccmd.h, I tried moving the CC_QUO flag bit above the 8th >> bit, but this breaks most code dealing with CC_QUO in ccmd, where >> character strings are passed around as char* data, and it is assumed >> that such data can be tested for the CC_QUO bit. >> >> With ISO 8859-n becoming widespread, and Unicode increasingly common, >> the lack of 8-bit (and eventually, 16-bit and 32-bit) character >> support is going to make mm less and less desirable as a mail client. >> >> This could be remedied by converting ccmd from char* to wchar_t* data >> (wchar_t is typedef'ed to a 32-bit integer type in modern C >> implementations). However, the changes in ccmd, and then in mm, would >> be rather extensive: >> >> In ccmd: >> % cat *.[ch] | grep -c 'char *[*]' >> 1040 >> >> In mm: >> % cat *.[ch] | grep -c 'char *[*]' >> 1458 >> >> Obviously, a simple sed script could be used to change the char* data >> types to wchar_t universally, but then all of the strxxx() functions >> would have to be changed too: >> >> In ccmd: >> cat *.[ch] | egrep -c 'str[a-z0-9]+ *[(]' >> 383 >> >> In mm: >> cat *.[ch] | egrep -c 'str[a-z0-9]+ *[(]' >> 585 >> >> and then all bitmasks would have to be carefully examined to see >> whether further hidden assumptions of byte size were present, and all >> I/O statements would have to be modified as well. >> >> This is probably too big a project to tackle, given the many other >> defiencies of the ccmd library. >> >> This is further evidence of the desirability of a redesign in C++ (or >> perhaps even Java!) to make the code independent of character-set >> size, and much cleaner; there is altogether too much exposure of the >> cmscb data structure in the code: >> >> In ccmd: >> cat *.[ch] | egrep -c 'cmcsb[.]' >> 762 >> >> In mm: >> cat *.[ch] | egrep -c 'cmcsb[.]' >> 127 >> ... It has bothered me ever since that ccmd and/or mm would not build on most other flavors of Unix, and particularly, on GNU/Linux, which is commonly present on personal and lab computers in our academic computing environment. When ccmd/mm failed to build on Sun Solaris 10, to which we are in the process of migrating from Solaris 7, 8, and 9, it became urgent, because for several of us, handling our large mail volume without mm is utterly unthinkable. [Yes, we have pine, emacs rmail, and several others, and Mark Crispin and I had a long telephone conversation a couple of months ago about the merits of various mail clients.] In May of this year, I therefore spent more time on those packages, primarily to get them working on Solaris 10. I'm pleased to report that I largely succeeded. My README.mm-0.94 file records this: >> ... >> The Makefiles contain new solaris10 targets. >> >> An additional extensive batch of updates on many other files produced >> working versions of mm for the first time on GNU/Linux on these >> architectures: >> >> Alpha >> AMD64 >> IA-32 >> IA-64 >> MIPS >> PowerPC >> SPARC >> >> Also supported for the first time are: >> >> FreeBSD 5.0 IA-32 >> NetBSD 1.6 IA-32 >> OpenBSD 3.2 IA-32 >> DEC OSF/1 4.0 Alpha >> Compaq OSF/1 5.2 Alpha >> ... The last updates of ccmd and mm at ftp://kermit.columbia.edu/pub/mm/ are these files: -rw-r--r-- 1 staff 584592 Oct 9 2003 mm-ccmd-0.91-20031009.tar.gz -rw-r--r-- 1 staff 585297 Oct 17 2003 mm-ccmd-0.91-20031017.tar.gz I am prepared to make mm-0.94 available privately on request to anyone on this list, and could easily set up Web and FTP sites for it. However, I'd prefer to have the new distribution available from Columbia (Frank da Cruz, are you reading this?) so that there is one definitive permanent source of ccmd + mm. Web searches show that the programmers at Columbia who were involved in the ccmd + mm effort have mostly moved on to new jobs, but Frank and I are still around, and hope to be for many years yet. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From fdc@columbia.edu Thu Jul 14 10:11:38 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6EEBc07006198 for ; Thu, 14 Jul 2005 10:11:38 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6EEBQ1J027949; Thu, 14 Jul 2005 10:11:26 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id j6EEBQBl027948; Thu, 14 Jul 2005 10:11:26 -0400 (EDT) Date: Thu, 14 Jul 2005 10:11:26 EDT From: Frank da Cruz To: "Nelson H. F. Beebe" Cc: tops-20@lingling.panda.com, beebe@math.utah.edu Subject: Re: News of mm In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: O X-Status: X-Keywords: X-UID: 225 > Back in 1986--1990, at Columbia University (CUCCA) Howie Kaye and > Andrew Lowry prepared ccmd, a C implementation of the TOPS-20 COMND% > JSYS. With this code available, Chris Maio, Fuat Baran, Howie Kaye > and Melissa Metz translated Mark Crispin's mm from PDP-10 assembly > code to C, and so Columbia-MM was born. > > We have used this code at Utah since at least 1990 on our Sun SunOS > and Solaris systems, but it is not been buildable on most other > flavors of Unix (we have 20+ in our software development lab). > As you noted further down, I use it too, and until I received this note, thought that I was the only one touching the code any more. On a historical note, I was the manager of the group that wrote CMM but I didn't work on the code then because I was too busy with Kermit :-) Ironically, although Kermit has a COMD-like interface I never picked up CCMD because (a) it wasn't ready in time and (b) by the time it was ready it was too big and seemed like overkill. After that I kept working on my stuff, adding variables and whatnot, until there was no going back. CCMD definitely is more authentic though :-) > In October 1998, I spent time examining the ccmd and mm code to see > whether I could make it 8-bit clean. I wrote then: > I went through this too a couple years ago and gave up because, as you found, the problem is deep, deep down. In those days, it wasn't a problem. If I'm not mistaken, they used the 8th bit as some kind of flag, so converting to data was going to break something else. I would have kept pursuing it but I found a workaround, which I use many times every day, that is described here: ftp://kermit.columbia.edu/kermit/mm/release-0.91.txt Basically, if you always use the editor (EMACS in my case), you can compose 8-bit messages all you want. Reading them was never a problem. > It has bothered me ever since that ccmd and/or mm would not build on > most other flavors of Unix, and particularly, on GNU/Linux, which is > commonly present on personal and lab computers in our academic > computing environment. > Over the last few years, I've been building it on Linux, OpenBSD, and NetBSD. I tried some other builds (HP-UX, AIX, Tru64, etc) without success but didn't have time to pursue them. > When ccmd/mm failed to build on Sun Solaris 10, to which we are in the > process of migrating from Solaris 7, 8, and 9, it became urgent, > because for several of us, handling our large mail volume without mm > is utterly unthinkable. > Me too. CMM is still my one and only mail client and I hope I won't ever have to switch. > [Yes, we have pine, emacs rmail, and several > others, and Mark Crispin and I had a long telephone conversation a > couple of months ago about the merits of various mail clients.] > Ditto. > The last updates of ccmd and mm at ftp://kermit.columbia.edu/pub/mm/ > are these files: > > -rw-r--r-- 1 staff 584592 Oct 9 2003 mm-ccmd-0.91-20031009.tar.gz > -rw-r--r-- 1 staff 585297 Oct 17 2003 mm-ccmd-0.91-20031017.tar.gz > > I am prepared to make mm-0.94 available privately on request to anyone > on this list, and could easily set up Web and FTP sites for it. > However, I'd prefer to have the new distribution available from > Columbia (Frank da Cruz, are you reading this?) so that there is one > definitive permanent source of ccmd + mm. > Yes indeed; I'll pick it up as soon as I have a chance. (I'm doing the work of 7 people these days, it's hard to keep up.) > Web searches show that the programmers at Columbia who were involved > in the ccmd + mm effort have mostly moved on to new jobs, but Frank > and I are still around, and hope to be for many years yet. > Hear hear! (Besides me, another one of the original team remains, but doesn't have time to work on MM any more.) - Frank From ron@isri.unlv.edu Thu Aug 8 13:34:13 2002 Flags: 000000000005 Return-Path: Received: from homebase.isri.unlv.edu (homebase.isri.unlv.edu [131.216.20.105]) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id gBAMYC6w004481 for ; Tue, 10 Dec 2002 17:34:13 -0500 (EST) Received: from wiggins.isri.unlv.edu (wiggins.isri.unlv.edu [131.216.20.115]) by homebase.isri.unlv.edu (Postfix) with ESMTP id 467F52E6B9; Tue, 10 Dec 2002 14:34:10 -0800 (PST) To: Frank da Cruz Cc: ron@isri.unlv.edu Subject: MM/ccmd continuation line patch Date: Tue, 10 Dec 2002 14:34:10 -0800 From: Ron Young Message-Id: <20021210223410.467F52E6B9@homebase.isri.unlv.edu> Status: O X-Status: X-Keywords: X-UID: 226 Dear Frank: I have attached a diff listing that fixes a minor bug with continuation line processing. I have also added the ability to display a "secondary" prompt (on each continuation line). The diffs are relative to mm-ccmd-0.91. Please consider them for inclusion in the distributed version. -ron P.S. Do you know if anyone is working on adding windows NT/2k support (specifically for ccmd)? I am using ccmd as my CLI processor for a custom information retrevial system, and I would very much like to include windows support. Just from a quick test, it looks like ccmd will work under cygwin with a hybrid linux/msdos configuration. =============================================================================== Ron Young, Sr. Software Design Engineer & System Admin. (702) 895-1070 (voice) Information Science Research Institute (702) 895-1183 (fax) University of Nevada, Las Vegas (UNLV/ISRI) ron@isri.unlv.edu Box 454021, Las Vegas, NV 89154 diff -c -r ../ccmd-dist/ccmd.c ./ccmd.c *** ../ccmd-dist/ccmd.c 2002-09-17 07:34:06.000000000 -0700 --- ./ccmd.c 2002-12-10 13:45:59.000000000 -0800 *************** *** 26,31 **** --- 26,32 ---- NULL, /* output to console */ NULL, /* error output */ NULL, /* no prompt set yet */ + NULL, /* no continuation prompt set yet */ NULL, /* no command line buffer yet */ NULL, /* no characters to parse */ 0, /* size of nonexistent command buffer */ *************** *** 345,350 **** --- 346,381 ---- } + /* subprompt + ** + ** Purpose: + ** Initializes a prompt string to be issued to a user after he enters a + ** continuation character (the variable cmcont contains the continuation + ** character). + ** + ** Input arguments: + ** prompt - The prompt string to be issued. The string must be preserved + ** throughout the parsing of the command line, as it will be referenced + ** whenever the command line must be redisplayed (after a help request, + ** when the user types ^R, etc.). In other words, do not pass + ** a pointer to dynamic storage that may be deallocated before parsing + ** is complete. + ** + ** Output arguments: none + ** + ** Returns: Standard return code. + **/ + + int + subprompt(p) + char *p; + { + int ret; + cmcsb._cmrty2 = p; /* save pointer to subprompt string */ + return(CMxOK); /* return success */ + } + + /* parse ** diff -c -r ../ccmd-dist/ccmd.guide ./ccmd.guide *** ../ccmd-dist/ccmd.guide 1990-12-18 10:40:58.000000000 -0800 --- ./ccmd.guide 2002-12-10 14:12:13.000000000 -0800 *************** *** 234,239 **** --- 234,240 ---- FILE * _cmoj; /* file for command output */ FILE * _cmej; /* file for error output */ char * _cmrty; /* pointer to prompt string */ + char * _cmrty2; /* pointer to continuation prompt string */ int * _cmbfp; /* pointer to beginning of user input */ int * _cmptr; /* pointer to beg of next field to parse */ int _cmcnt; /* # of chars in buffer past _cmptr */ *************** *** 747,756 **** anything. Then, if you enter the function and the pointer is non-NULL, you will know you have to free the storage. ! f) prompt(str) char *str; ! This sets up the string that will be used for prompting. It is generally done before the first parse of a command, inside a command parsing loop. --- 748,757 ---- anything. Then, if you enter the function and the pointer is non-NULL, you will know you have to free the storage. ! f) prompt(str) and subprompt(str) char *str; ! This sets up the string(s) that will be used for prompting. It is generally done before the first parse of a command, inside a command parsing loop. *************** *** 760,765 **** --- 761,772 ---- In addition, if cmseti() has not been done it will be automatically called. + subprompt() is used to set the secondary prompt that is displayed for + a command continued on a secord (or later) line. if subprompt() has + not been called, the secondary prompt defaults to the continuation + character, followed by the primary prompt. + + g) fdbchn (fdb1, [ fdbn, ] ... NULL) fdb fdb1, fdbn; diff -c -r ../ccmd-dist/ccmd.h ./ccmd.h *** ../ccmd-dist/ccmd.h 2000-12-06 20:59:44.000000000 -0800 --- ./ccmd.h 2002-12-10 13:47:07.000000000 -0800 *************** *** 95,100 **** --- 95,101 ---- FILE * _cmoj; /* file for command output */ FILE * _cmej; /* file for error output */ char * _cmrty; /* pointer to prompt string */ + char * _cmrty2; /* pointer to continuation prompt string */ int * _cmbfp; /* pointer to beginning of user input */ int * _cmptr; /* pointer to beg of next field to parse */ int _cmcnt; /* # of chars in buffer past _cmptr */ diff -c -r ../ccmd-dist/stdact.c ./stdact.c *** ../ccmd-dist/stdact.c 2002-02-20 00:53:28.000000000 -0800 --- ./stdact.c 2002-12-10 14:00:10.000000000 -0800 *************** *** 340,358 **** int ret; int *end; /* end of current input */ - if (!deferred) - return(CMxDFR); - if (cmcsb._cminc > 0) { /* is there unparsed input? */ end = cmcsb._cmcur - 1; /* point to last char */ if ((*end & CC_QCH) == cmcont) { /* last char continuation char? */ /* (fails if quoted) */ *end |= CC_CSK; /* make it conditionally skipped */ ret = cmsti1(NEWLINE,CC_SKP); /* and stuff a skipped newline */ return(ret); /* no wakeup */ } } if (cmcsb._cmflg & CM_CMT) { /* if inside a comment */ cmcsb._cmflg &= ~CM_CMT; /* then turn off the comment */ } --- 340,368 ---- int ret; int *end; /* end of current input */ if (cmcsb._cminc > 0) { /* is there unparsed input? */ end = cmcsb._cmcur - 1; /* point to last char */ if ((*end & CC_QCH) == cmcont) { /* last char continuation char? */ /* (fails if quoted) */ *end |= CC_CSK; /* make it conditionally skipped */ ret = cmsti1(NEWLINE,CC_SKP); /* and stuff a skipped newline */ + if (cmcsb._cmrty2 != NULL) + { + cmxputs(cmcsb._cmrty2); /* print secondary prompt if any */ + } + else + { + cmxputc(cmcont); /* make secondard prompt: prefix */ + cmxputs(cmcsb._cmrty); /* continuation character to front */ + } /* of primary prompt */ + return(ret); /* no wakeup */ } } + if (!deferred) + return(CMxDFR); + if (cmcsb._cmflg & CM_CMT) { /* if inside a comment */ cmcsb._cmflg &= ~CM_CMT; /* then turn off the comment */ } *************** *** 569,575 **** cmcsb._cmcol = 0; if (cp1 == cmcsb._cmbfp) { /* killed prompt line? */ cmxputs(cmcsb._cmrty); /* then reprompt */ ! } cmcsb._cmcur = cp1; cmcsb._cmcur = disp_forward_char(cp2 - cp1); --- 579,593 ---- cmcsb._cmcol = 0; if (cp1 == cmcsb._cmbfp) { /* killed prompt line? */ cmxputs(cmcsb._cmrty); /* then reprompt */ ! } else if (cmcsb._cmrty2 != NULL) /* do we have a secondary prompt? */ ! { ! cmxputs(cmcsb._cmrty2); /* yes, print it */ ! } ! else ! { ! cmxputc(cmcont); /* no, build one, prefix cont. char */ ! cmxputs(cmcsb._cmrty); /* in front of primary prompt */ ! } cmcsb._cmcur = cp1; cmcsb._cmcur = disp_forward_char(cp2 - cp1); From beebe@math.utah.edu Tue Aug 2 09:37:34 2005 Flags: 000000000001 Return-Path: Received: from sunshine2.math.utah.edu (sunshine2.math.utah.edu [155.101.96.3]) by elderberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j72DbXm7021856 for ; Tue, 2 Aug 2005 09:37:34 -0400 (EDT) Received: from psi.math.utah.edu (IDENT:VqfqOwGvTH+RJPFTFZnZlegJntH+Sy31@psi.math.utah.edu [155.101.96.19]) by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72DbMgl001379; Tue, 2 Aug 2005 07:37:22 -0600 (MDT) Received: from psi.math.utah.edu (IDENT:c2kqazKBbNJjJVxt7AxDRkSWhBrNop7+@localhost [127.0.0.1]) by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72DbMKE004710; Tue, 2 Aug 2005 07:37:22 -0600 (MDT) Received: (from beebe@localhost) by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j72DbL9D004708; Tue, 2 Aug 2005 07:37:22 -0600 (MDT) Date: Tue, 2 Aug 2005 07:37:22 -0600 (MDT) From: "Nelson H. F. Beebe" To: William "Chops" Westfield Cc: beebe@math.utah.edu, Frank da Cruz , "Nelson H. F. Beebe" , tops-20@lingling.panda.com, beebe@math.utah.edu X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: News of mm In-Reply-To: Your message of Mon, 1 Aug 2005 21:59:00 PDT Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Tue, 02 Aug 2005 07:37:22 -0600 (MDT) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.166 Status: O X-Status: X-Keywords: X-UID: 227 William "Chops" Westfield asks on Mon, 1 Aug 2005 21:59:00 PDT about my changes to the C version of mm: >> I've been touching it too ... Did you do other cleanups? >> I keep looking at it (in light of 'modern' styles of C programming) and >> getting very depressed about the prospects of doing significant work, ... Our work at Utah on mm has not added any new commands, but instead has been directed at enhancing portability, and trying to make it 8-bit clean. We also disabled the mail file locking, since it doesn't work reliably in an NFS environment: we simply warn our mm users that they must avoid running multiple instances of mm, just as they already know they must also avoid running multiple Web browsers. All changes in both the ccmd and mm directories are under RCS control, and the mm-0.94/mm/CHANGELOG file summarizes the changes. We have succeeded in improving portability, since mm-0.94 now builds on all of our 20+ flavors of Unix, but we failed in the 8-bit cleanup. I found that there are pervasive assumptions in the ccmd command-parser library that the high-order bit of each 8-bit character can be used as a flag, and concluded long ago that the only solution was a complete redesign and rewrite of the parsing package, possibly in C++ or Java, with elimination of the TOPS-20 data structures in favor of a much cleaner interface. Inasmuch as there are 21,187 lines of code in ccmd, and 36,088 lines of code in mm, any such project is destined to take many months in the hands of skilled programmer, and since we are all getting old and gray, that is hard to justify. There are lots of other programming projects that I want to work on. As long as you keep the parser's hands off your text, you can use 8-bit characters in mm. The header lines, like Subject:, gets parsed, so they are stuck with 7-bit characters unless you edit them. What I generally do is have a permanently-running emacs session with the mail-server library preloaded, and then when I ask mm to get me to an editor, it hands what I've typed so far off to emacs. I can then edit the entire message, using 8-bit characters as needed, even putting those characters into mail headers. For example, here is a snippet of a Danish rhyme in ISO 8859-1 encoding: Subject: Danske børnerim og engelsk oversættelse Øen i søen har kun én barber, The island in the lake has only one barber, men tilgengæld så klipper han but then he clips alt hvad han ser. everything he sees. When I end the emacs message editing with C-x ! (server-edit), control returns to mm, which is then happy to send my 8-bit characters, as long as I don't try to edit them further by, for example, typing in a new subject line. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From fdc@columbia.edu Tue Aug 2 11:18:21 2005 Flags: 000000000001 Return-Path: Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by feta.cc.columbia.edu (8.13.0/8.13.0) with SMTP id j72FIJqF002923; Tue, 2 Aug 2005 11:18:20 -0400 (EDT) Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Tue, 2 Aug 2005 08:12:17 -0700 (PDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j72FCAtl012877; Tue, 2 Aug 2005 11:12:10 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id j72FC5b7012858; Tue, 2 Aug 2005 11:12:05 -0400 (EDT) Date: Tue, 2 Aug 2005 11:12:05 EDT From: Frank da Cruz To: "Nelson H. F. Beebe" Cc: tops-20@lingling.panda.com Subject: Re: News of mm In-Reply-To: Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.164 Status: O X-Status: X-Keywords: X-UID: 228 Nelson Wrote... > William "Chops" Westfield asks on Mon, 1 Aug 2005 > 21:59:00 PDT about my changes to the C version of mm: > > >> I've been touching it too ... Did you do other cleanups? > >> I keep looking at it (in light of 'modern' styles of C programming) and > >> getting very depressed about the prospects of doing significant work, ... > > Our work at Utah on mm has not added any new commands, but instead has > been directed at enhancing portability, and trying to make it 8-bit > clean. We also disabled the mail file locking, since it doesn't work > reliably in an NFS environment: we simply warn our mm users that they > must avoid running multiple instances of mm, just as they already know > they must also avoid running multiple Web browsers. > This is the major reason MM fell out of favor at Columbia, where we have a big (Solaris) host pool. With tens of thousands of users, it's just too easy for somebody to get disconnected and leave behind an mm zombie, and then not be able to get back to the same host to kill it, even if they knew how to do that, so our help desk was always swamped with "my mailbox is locked" calls. Now the only people who use mm any more are the ones who know how to take care of themselves. It never occurred to me to just remove the locking, but maybe at this point it's safe. > All changes in both the ccmd and mm directories are under RCS control, > and the mm-0.94/mm/CHANGELOG file summarizes the changes. > > We have succeeded in improving portability, since mm-0.94 now builds > on all of our 20+ flavors of Unix... > That's a big and badly needed step. > ... but we failed in the 8-bit cleanup. > I found that there are pervasive assumptions in the ccmd > command-parser library that the high-order bit of each 8-bit character > can be used as a flag, and concluded long ago that the only solution > was a complete redesign and rewrite of the parsing package, possibly > in C++ or Java, with elimination of the TOPS-20 data structures in > favor of a much cleaner interface. Inasmuch as there are 21,187 lines > of code in ccmd, and 36,088 lines of code in mm, any such project is > destined to take many months in the hands of skilled programmer, and > since we are all getting old and gray, that is hard to justify. There > are lots of other programming projects that I want to work on. > Right, this will probably never happen. Anyway I like leaving CCMD as a kind of memorial to how it was. The DEC-20 was pretty much hardwired 7-bit ASCII, despite its variable-length bytes (although I did hear rumors at the time of installations in Japan that bought them for exactly that reason, and used larger bytesizes for some combination of Roman, Kana, and Kanji -- I visited the NTT lab in 1987 and didn't see any evidence of this, but maybe Mark knows more). Given the number of Scandinavians at Marlboro you'd think there would have been some interest in at least Latin-1, but with them I think it was a matter of pride to speak better English than Americans -- facilitating the use of other languages would have been sign of weakness :-) > As long as you keep the parser's hands off your text, you can use > 8-bit characters in mm. The header lines, like Subject:, gets parsed, > so they are stuck with 7-bit characters unless you edit them. > > What I generally do is have a permanently-running emacs session with > the mail-server library preloaded, and then when I ask mm to get me to > an editor, it hands what I've typed so far off to emacs. I can then > edit the entire message, using 8-bit characters as needed, even > putting those characters into mail headers. For example, here is a > snippet of a Danish rhyme in ISO 8859-1 encoding: > > Subject: Danske bxrnerim og engelsk oversfttelse > > Xen i sxen har kun in barber, The island in the lake has only one barber, > men tilgengfld se klipper han but then he clips > alt hvad han ser. everything he sees. > > When I end the emacs message editing with C-x ! (server-edit), control > returns to mm, which is then happy to send my 8-bit characters, as > long as I don't try to edit them further by, for example, typing in a > new subject line. > I just "set use-editor-always true". I send tons Latin-1 mail every day, sometimes also UTF-8. Now that we have relatively fast computers, the penalty of starting EMACS on each messages is hardly noticeable. BillW said: > There was the y2k fix attempts, the "mimetype" command, the > "howmany" that wasn't really needed... Sigh. > I should hope the current Columbia version (and therefore Nelson's) obviates the need for any y2k fixes. It also has a MIME-VERSION command. One thing I'm not happy about is the CONTENT-TYPE command that I added. I assumed the only thing I would ever use MM for was plain text, so this command only fills in the character-set part of the Content-Type header, keeping "text/plain" hardwired. Now it seems I need to send HTML from time to time, so this command should be changed to do what you'd expect -- specify the content type! I also have a few other items on my list. I guess the ball is in my court. I haven't had a chance to look at Nelson's stuff yet. The main thing that worries me is the 8-bit changes. Since you say they didn't work, I assume that you backed them out? > ----------------------------------------------------------------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 - > - University of Utah FAX: +1 801 581 4148 - > - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - > - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - > - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - > ----------------------------------------------------------------------------- - Frank From MRC@lingling.panda.com Tue Aug 2 14:30:36 2005 Flags: 000000000001 Return-Path: Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by dewberry.cc.columbia.edu (8.13.0/8.13.0) with SMTP id j72IUORr027564; Tue, 2 Aug 2005 14:30:35 -0400 (EDT) Date: Tue, 2 Aug 2005 11:25:02 -0700 (PDT) From: Mark Crispin Subject: Re: News of mm To: fdc@columbia.edu cc: beebe@math.utah.edu, tops-20@lingling.panda.com In-Reply-To: Pithy-Thought: TOPS-20 was a great improvement over its successors Message-ID: <14046925261.16.MRC@lingling.panda.com> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.165 Status: O X-Status: X-Keywords: X-UID: 229 > This is the major reason MM fell out of favor at Columbia, where we have a > big (Solaris) host pool. With tens of thousands of users, it's just too > easy for somebody to get disconnected and leave behind an mm zombie, and > then not be able to get back to the same host to kill it, even if they knew > how to do that, so our help desk was always swamped with "my mailbox is > locked" calls. This was something that I addressed in the course of c-client/IMAP development. There is, by the way, a baby version of UNIX MM that is built upon c-client (and thus is IMAP capable) and ccmd called...of course...MS. I used it quite extensively until I switched to Pine (which is also based upon c-client but not ccmd). > The DEC-20 was pretty much hardwired 7-bit > ASCII, despite its variable-length bytes (although I did hear rumors at the > time of installations in Japan that bought them for exactly that reason, and > used larger bytesizes for some combination of Roman, Kana, and Kanji -- I > visited the NTT lab in 1987 and didn't see any evidence of this, but maybe > Mark knows more). The PDP-10 systems in Japan all used ISO 2022 encoded JIS, which is the standard way of sending Japanese email today. By the way,... I assume that everybody has read my UTF-9 and UTF-18 document (RFC 4042) for how to do Unicode on PDP-10s. I am quite serious about this, and am thinking about how to handle 9-bit text files seamlessly e.g., making 7-bit open mode truncate bits from a 9-bit file rather than bit-shifting, so that legacy 7-bit applications can handle ASCII content 9-bit files. So, after 35 years, IO.MAC may finally realize its promise. ------- From billw@cisco.com Tue Aug 2 15:17:39 2005 Flags: 000000000005 Return-Path: Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by elderberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j72JHcKZ024654 for ; Tue, 2 Aug 2005 15:17:38 -0400 (EDT) Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 02 Aug 2005 12:17:38 -0700 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j72JHaqK021109; Tue, 2 Aug 2005 12:17:36 -0700 (PDT) Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA26533; Tue, 2 Aug 2005 12:17:36 -0700 (PDT) Sender: Bill Westfield Date: Tue, 2 Aug 2005 12:17:35 PDT From: William "Chops" Westfield To: Frank da Cruz Cc: "Nelson H. F. Beebe" , tops-20@lingling.panda.com Subject: Re: News of mm In-Reply-To: Your message of Tue, 2 Aug 2005 11:12:05 EDT 2 Aug 2005 09:34:46 -0600 (MDT) Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.166 Status: O X-Status: X-Keywords: X-UID: 230 > ... but we failed in the 8-bit cleanup. > I found that there are pervasive assumptions in the ccmd > command-parser library that the high-order bit of each 8-bit character > can be used as a flag, and concluded long ago that the only solution > was a complete redesign and rewrite of the parsing package... Couldn't you add 8-bit CMTXT style parsing without needing to make ccmd completely "8bit clean"? I wouldn't think that mm needs 8 bit keywords and tokens and so on. (This is more or less what I did at cisco for international character support; a couple spots just pass on the 8th bit when they didn't in the past, but the parser itself isn't '8bit' by any means. Never did get a good feel for how well that worked in the field...) > There was the y2k fix attempts, the "mimetype" command... > I should hope the current Columbia version obviates the need for any y2k fixes. It also has a MIME-VERSION command. Probably. I think I got to a point where I couldn't (or believed I couldn't) download new columbia code and still have it compile in our solaris environment. I'm still running 0.90.4... "mimetype" is a display command; simply a version of the "type" command with a different output filter, so that you can pipe a message though mh's (?) metamail. Cheap, easy, and pretty useful... BillW From beebe@math.utah.edu Tue Aug 2 16:08:41 2005 Flags: 000000000001 Return-Path: Received: from sunshine2.math.utah.edu (sunshine2.math.utah.edu [155.101.96.3]) by tepin.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j72K8atR020183 for ; Tue, 2 Aug 2005 16:08:40 -0400 (EDT) Received: from psi.math.utah.edu (IDENT:IeWExoBTYLmnLCYe5s+PjcrmvkyfPFdR@psi.math.utah.edu [155.101.96.19]) by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72K7UX8014852; Tue, 2 Aug 2005 14:07:30 -0600 (MDT) Received: from psi.math.utah.edu (IDENT:1YX/VcE1wM2hHZ+Ucd90y1J3oqoz9MES@localhost [127.0.0.1]) by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72K7Tbc007492; Tue, 2 Aug 2005 14:07:29 -0600 (MDT) Received: (from beebe@localhost) by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j72K7TM5007491; Tue, 2 Aug 2005 14:07:29 -0600 (MDT) Date: Tue, 2 Aug 2005 14:07:29 -0600 (MDT) From: "Nelson H. F. Beebe" To: William "Chops" Westfield Cc: beebe@math.utah.edu, Frank da Cruz , "Nelson H. F. Beebe" , tops-20@lingling.panda.com X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: News of mm In-Reply-To: Your message of Tue, 2 Aug 2005 12:17:35 PDT Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Tue, 02 Aug 2005 14:07:30 -0600 (MDT) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.169 Status: O X-Status: X-Keywords: X-UID: 231 William "Chops" Westfield writes on Tue, 2 Aug 2005 12:17:35 PDT about the 8-bit limitation of the ccmd parsing package: >> Couldn't you add 8-bit CMTXT style parsing without needing to make >> ccmd completely "8bit clean"? That is definitely an idea worth investigating: we could certainly live without 8-bit characters in mm prompts and commands, since they are in English to begin with, and are not easily internationalized (although that should be a fundamental design point in any new software). More critical, however, is the issue of attachments. Bill goes on to write: >> ... >> "mimetype" is a display command; simply a version of the "type" >> command with a different output filter, so that you can pipe a message >> though mh's (?) metamail. Cheap, easy, and pretty useful... >> ... Another good idea. Bill, do think you might have the time to run diffs of your mimetype additions against the mm-0.90 base and email them to me offlist? If they are not extensive and conflicting with what I've done, I'll be happy to take a stab at merging them into the mm-0.94 code. I leave for China in two weeks, so nothing is likely to happen to mm at my end before late September, at the earliest, so there is no great rush. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From beebe@math.utah.edu Tue Aug 2 16:08:41 2005 Flags: 000000000001 Return-Path: Received: from sunshine2.math.utah.edu (sunshine2.math.utah.edu [155.101.96.3]) by tepin.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j72K8atR020183 for ; Tue, 2 Aug 2005 16:08:40 -0400 (EDT) Received: from psi.math.utah.edu (IDENT:IeWExoBTYLmnLCYe5s+PjcrmvkyfPFdR@psi.math.utah.edu [155.101.96.19]) by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72K7UX8014852; Tue, 2 Aug 2005 14:07:30 -0600 (MDT) Received: from psi.math.utah.edu (IDENT:1YX/VcE1wM2hHZ+Ucd90y1J3oqoz9MES@localhost [127.0.0.1]) by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72K7Tbc007492; Tue, 2 Aug 2005 14:07:29 -0600 (MDT) Received: (from beebe@localhost) by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j72K7TM5007491; Tue, 2 Aug 2005 14:07:29 -0600 (MDT) Date: Tue, 2 Aug 2005 14:07:29 -0600 (MDT) From: "Nelson H. F. Beebe" To: William "Chops" Westfield Cc: beebe@math.utah.edu, Frank da Cruz , "Nelson H. F. Beebe" , tops-20@lingling.panda.com X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: News of mm In-Reply-To: Your message of Tue, 2 Aug 2005 12:17:35 PDT Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Tue, 02 Aug 2005 14:07:30 -0600 (MDT) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.169 Status: O X-Status: X-Keywords: X-UID: 232 William "Chops" Westfield writes on Tue, 2 Aug 2005 12:17:35 PDT about the 8-bit limitation of the ccmd parsing package: >> Couldn't you add 8-bit CMTXT style parsing without needing to make >> ccmd completely "8bit clean"? That is definitely an idea worth investigating: we could certainly live without 8-bit characters in mm prompts and commands, since they are in English to begin with, and are not easily internationalized (although that should be a fundamental design point in any new software). More critical, however, is the issue of attachments. Bill goes on to write: >> ... >> "mimetype" is a display command; simply a version of the "type" >> command with a different output filter, so that you can pipe a message >> though mh's (?) metamail. Cheap, easy, and pretty useful... >> ... Another good idea. Bill, do think you might have the time to run diffs of your mimetype additions against the mm-0.90 base and email them to me offlist? If they are not extensive and conflicting with what I've done, I'll be happy to take a stab at merging them into the mm-0.94 code. I leave for China in two weeks, so nothing is likely to happen to mm at my end before late September, at the earliest, so there is no great rush. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From billw@cisco.com Wed Aug 3 21:04:36 2005 Flags: 000000000001 Return-Path: Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by dewberry.cc.columbia.edu (8.13.0/8.13.0) with SMTP id j7414Y8A005901; Wed, 3 Aug 2005 21:04:34 -0400 (EDT) Received: from sj-iport-1.cisco.com ([171.71.176.70]) by lingling.panda.com with TCP/SMTP; Wed, 3 Aug 2005 17:55:06 -0700 (PDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2005 17:55:00 -0700 X-IronPort-AV: i="3.95,165,1120460400"; d="scan'208"; a="652840151:sNHT27499944" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j740svoo005834; Wed, 3 Aug 2005 17:54:58 -0700 (PDT) Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA26063; Wed, 3 Aug 2005 17:54:57 -0700 (PDT) Sender: Bill Westfield Date: Wed, 3 Aug 2005 17:54:57 PDT From: William "Chops" Westfield To: Ken Rossman Cc: tops-20@lingling.panda.com Subject: Re: News of mm In-Reply-To: Your message of Tue, 2 Aug 2005 16:33:13 -0400 Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.165 Status: O X-Status: X-Keywords: X-UID: 233 >> I think some work on ccmd and mm is well merited. >> >> 1) Lets come up with a specific list of modifications that ought to >> be made to the code, and prioritize the list. >> >> 2) Analyze the existing code to determine just how modular and "object >> oriented" it already is (not specifically strictly object oriented, Alas, the code is pretty sucky by modern C standards. For instance, there are no function prototypes. Merely compiling with a modern compiler requires things like --traditional, and there are still lots of warnings generated :-( Whenever I contemplate touching it (ie for something like a linux port), I keep running up agains the idea is that "first, I oughta modernize it and get rid of the existing compiler-found bugs.") Which would be a moderate sized project in itself :-( Things I've done anyway: Mime output via existing external mime filters. Sorta. Add "fix-dates" commands to make the internal dates match the Date: fields in the message. One of the y2k-related (?) bugs caused the internal date to "drift" a day at a time, causing "before" and similar search keywords to fail miserably. (a hack, in case you had any doubts!) Fix (maybe, sorta) incorrect parsing of lines beginning with "From " that caused mm to think this meant the beginning of a new message. (perhaps only in some formats of mail files?) Do automatic "take newmail.rc" whenever mm detects new incoming mail (for spam removal.) It would be REALLY nice if the newmail.rc file only had to operate on the new messages, rather than the whole file. I didn't look at doing that... Be less anal about adding reply-to: fields if the From: field contains a reasonable-looking address. (it was NOT helpful that mm kept adding "Reply-to: billw@internal-mail-host.cisco.com" when my From field already had "billw@cisco.com") Add "unto" search keyword ("head unseen unto billw"; very useful!) increase string sizes. Things I want: Wildcards of at least a primitive kind for "dont-type-headers" flush useless headers (on request, and/or automatically) in the mail file. By the time a message has been kept after reading for a month or so, I surely no longer need a couple Kbytes of "received" lines, right? Read ("examine") compressed mail files. Better spam filtering capabilities. Color output, especially in some form of "Headers" ? multi-file search. It is MM's search capabilities, more than any other feature, that keeps me using it. I can type a complex search like read to billw before 1-jun-2005 sub "CSCd" text "tty_printf" and get results faster than I can wade through the first level of "easy to use" search menus on a modern GUI mail reader. But I want more. Check optimization for typical modern-sized emails and mail files. A one-year archive for me seems to run about 200Mbytes these days, with "many" messages exceeding 50kbytes BillW From sra@hactrn.net Thu Aug 4 04:34:00 2005 Flags: 000000000001 Return-Path: Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by elderberry.cc.columbia.edu (8.13.0/8.13.0) with SMTP id j748Xw9Y014259; Thu, 4 Aug 2005 04:33:59 -0400 (EDT) Received: from cyteen.hactrn.net ([66.92.66.68]) by lingling.panda.com with TCP/SMTP; Thu, 4 Aug 2005 01:24:10 -0700 (PDT) Received: from thangorodrim.hactrn.net (open-24-185.ietf63.ietf.org [86.255.24.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id C0D6E72 for ; Thu, 4 Aug 2005 04:24:02 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id AC61939 for ; Thu, 4 Aug 2005 08:23:56 +0000 (UTC) Date: Thu, 04 Aug 2005 10:23:55 +0200 From: Rob Austein To: tops-20@lingling.panda.com Subject: Re: News of mm In-Reply-To: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050804082356.AC61939@thangorodrim.hactrn.net> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.166 Status: O X-Status: X-Keywords: X-UID: 234 At Wed, 3 Aug 2005 17:54:57 PDT, William Chops Westfield wrote: > > Alas, the code is pretty sucky by modern C standards. For instance, there > are no function prototypes. gcc's "protoize" command, while quirky and imperfect, does still do about 80% of the job of fixing this sort of problem. Might be worth a try. From beebe@math.utah.edu Thu Aug 4 07:34:23 2005 Flags: 000000000001 Return-Path: Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by dewberry.cc.columbia.edu (8.13.0/8.13.0) with SMTP id j74BYLRJ029379; Thu, 4 Aug 2005 07:34:21 -0400 (EDT) Received: from sunshine2.math.utah.edu ([155.101.96.3]) by lingling.panda.com with TCP/SMTP; Thu, 4 Aug 2005 04:25:42 -0700 (PDT) Received: from psi.math.utah.edu (IDENT:/MVrHjqMHwQce2dC7dWyHXdu4Z8kqluh@psi.math.utah.edu [155.101.96.19]) by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j74BPTcU017098; Thu, 4 Aug 2005 05:25:29 -0600 (MDT) Received: from psi.math.utah.edu (IDENT:AIf39PLnc267MpyWxmGvR/qtvTK6nS5q@localhost [127.0.0.1]) by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j74BPTQf003491; Thu, 4 Aug 2005 05:25:29 -0600 (MDT) Received: (from beebe@localhost) by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j74BPSVw003490; Thu, 4 Aug 2005 05:25:28 -0600 (MDT) Date: Thu, 4 Aug 2005 05:25:28 -0600 (MDT) From: "Nelson H. F. Beebe" To: William "Chops" Westfield Cc: beebe@math.utah.edu, Ken Rossman , tops-20@lingling.panda.com X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: News of mm In-Reply-To: Your message of Wed, 3 Aug 2005 17:54:57 PDT Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Thu, 04 Aug 2005 05:25:29 -0600 (MDT) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.165 Status: O X-Status: X-Keywords: X-UID: 235 William "Chops" Westfield writes on Wed, 3 Aug 2005 17:54:57 PDT about mm: >> ... the code is pretty sucky by modern C standards. For instance, there >> are no function prototypes. That is fixed in the mm-0.94 distribution. I'm a fanatic about having function prototypes: in my experience, adding them to older programs has invariably turned up several bugs of incorrect argument types or numbers of arguments. That is why I routinely build by own C code with C++ compilers, because they are even more picky about argument matching and type coercions. Almost all of mm-0.94/ccmd can be successfully compiled with C++. On the mm-0.94/mm side, there is a type conflict in a header file used by most of the code that makes C++ choke. I could probably fix the remaining C++ problems in an hour or two, and will likely do so when I merge Bill's changes in. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From beebe@math.utah.edu Thu Aug 4 18:58:18 2005 Flags: 000000000001 Return-Path: Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by tepin.cc.columbia.edu (8.13.0/8.13.0) with SMTP id j74MwGsT027614; Thu, 4 Aug 2005 18:58:17 -0400 (EDT) Received: from sunshine2.math.utah.edu ([155.101.96.3]) by lingling.panda.com with TCP/SMTP; Thu, 4 Aug 2005 15:49:23 -0700 (PDT) Received: from psi.math.utah.edu (IDENT:X24Rk7yW3KaY2Z9S//Y5+DtCQ++Hd6VB@psi.math.utah.edu [155.101.96.19]) by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j74MnGFW005848; Thu, 4 Aug 2005 16:49:16 -0600 (MDT) Received: from psi.math.utah.edu (IDENT:k9FuJnnkytS4ta8Kuu9TT4Wbpfhqqczu@localhost [127.0.0.1]) by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j74MnGJ5008188; Thu, 4 Aug 2005 16:49:16 -0600 (MDT) Received: (from beebe@localhost) by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j74MnFat008187; Thu, 4 Aug 2005 16:49:15 -0600 (MDT) Date: Thu, 4 Aug 2005 16:49:15 -0600 (MDT) From: "Nelson H. F. Beebe" To: William "Chops" Westfield , tops-20@lingling.panda.com Cc: beebe@math.utah.edu X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: News of mm In-Reply-To: Your message of Thu, 4 Aug 2005 14:48:15 PDT Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Thu, 04 Aug 2005 16:49:16 -0600 (MDT) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.169 Status: O X-Status: X-Keywords: X-UID: 236 William "Chops" Westfield asks on Thu, 4 Aug 2005 14:48:15 PDT: >> ... >> Did anyone fix the bug where text being composed in emacs dissappears on the >> way back to MM, if the tmp file size is between 800 and 1200 bytes or so? >> Unfortunately, the version I'm using now has a bunch of tmp files made >> permanent in efforts to track and work around that problem... >> ... We used to see that a fair amount, and for that reason, I disabled the deletion of the temporary files to allow recovery: % ls -l ~/.mm* -rw------- 1 beebe wheel 1241 Aug 1 18:52 /u/sy/beebe/.mm-outgoing.22323.~1~ -rw------- 1 beebe wheel 501 Jul 27 15:34 /u/sy/beebe/.mm-outgoing.22323.~2~ ... I clean them up manually now and then. However, I've been running on Solaris 9 for many months now, sending 100--300 messages a day in mm-0.94, and have not had a single message lost between mm and emacs (21.3.1). Pieter also uses mm heavily, but is away on vacation just now, so I cannot ask him whether he has seen any message loss in recent months. Pieter and I spent quite some time trying to track down the loss, and decided that it looked much like a race condition in a signal handler. An rcsdiff of exit.c against the original 1.1 version shows that there are a fair number of macroized debug print statements that I inserted to try to track down the problem, but no substantive code changes. Thus, it is possible that Solaris 9, or the rebuild of mm under that system, fixed the problem. We have just three systems left running Solaris 8, most of the rest are at Solaris 9, and a few are at Solaris 10. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From fdc@columbia.edu Sun Aug 7 10:23:42 2005 Flags: 000000000001 Return-Path: Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by feta.cc.columbia.edu (8.13.0/8.13.0) with SMTP id j77ENe8H013037; Sun, 7 Aug 2005 10:23:41 -0400 (EDT) Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sun, 7 Aug 2005 07:14:20 -0700 (PDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j77EDxQr015480; Sun, 7 Aug 2005 10:13:59 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id j77EDwB6015479; Sun, 7 Aug 2005 10:13:58 -0400 (EDT) Date: Sun, 7 Aug 2005 10:13:58 EDT From: Frank da Cruz To: William "Chops" Westfield Cc: "Nelson H. F. Beebe" , beebe@math.utah.edu, Ken Rossman , tops-20@lingling.panda.com Subject: Re: News of mm In-Reply-To: Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.164 Status: O X-Status: X-Keywords: X-UID: 237 > Did anyone fix the bug where text being composed in emacs dissappears on the > way back to MM, if the tmp file size is between 800 and 1200 bytes or so? > Unfortunately, the version I'm using now has a bunch of tmp files made > permanent in efforts to track and work around that problem... > I meant to answer this earlier. This was my primary reason for attacking the code a few years ago. My messages were being truncated more and more often upon return from EMACS (on Solaris 2.5.1, over NFS). It was not a problem with EMACS or MM, but with NFS. I added debugging, delays, the retention of temp files, and all kinds of heuristics until finally it stopped happening. It isn't pretty but I haven't lost a message since then. What I did is described in the 0.91 edit history. ftp://kermit.columbia.edu/kermit/mm/notes-fdc.txt - Frank From fdc@columbia.edu Fri Aug 26 11:21:33 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j7QFLXnN010932 for ; Fri, 26 Aug 2005 11:21:33 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j7QFLWLJ013305; Fri, 26 Aug 2005 11:21:32 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id j7QFLWbZ013304; Fri, 26 Aug 2005 11:21:32 -0400 (EDT) Date: Fri, 26 Aug 2005 11:21:32 EDT From: Frank da Cruz To: "Nelson H. F. Beebe" Subject: Re: News of mm In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: O X-Status: X-Keywords: X-UID: 238 > Frank da Cruz asks: > > >> The main thing that worries me is the 8-bit changes. Since you > >> say they didn't work, I assume that you backed them out? > > They were all in a separate development branch that I versioned mm-0.93, > and then abandoned. The mm-0.94 version is derived from the mm-0.92 one. > I know you're in China and won't be back for a couple weeks, but thought I'd send this in case I forget later. I downloaded mm-0.94 from your ftp site, built it (on Solaris9), and it doesn't have any of my stuff in it -- the DOWNLOAD command, the CONTENT-TYPE command, the modified temp-file handling, etc. Are you sure you based your work on 0.92? Maybe it was somebody else's 0.92! When you get a chance, let me know. Maybe I downloaded the wrong thing. If necessary I suppose I can fit all my stuff back into yours and get us back in sync. - Frank From beebe@sunshine2.math.utah.edu Fri Aug 26 11:59:26 2005 Flags: 000000000001 Return-Path: Received: from sunshine2.math.utah.edu (sunshine2.math.utah.edu [155.101.96.3]) by jujube.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j7QFxM5i008828 for ; Fri, 26 Aug 2005 11:59:25 -0400 (EDT) Received: from sunshine2.math.utah.edu (IDENT:BR4EuTF+KcHm2+HUJ/934pS3ALwIpE9W@localhost [127.0.0.1]) by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j7QFxMT4006060 for ; Fri, 26 Aug 2005 09:59:22 -0600 (MDT) Received: (from beebe@localhost) by sunshine2.math.utah.edu (8.13.4/8.13.4/Submit) id j7QFxMvG006059 for fdc@columbia.edu; Fri, 26 Aug 2005 09:59:22 -0600 (MDT) Date: Fri, 26 Aug 2005 09:59:22 -0600 (MDT) Message-Id: <200508261559.j7QFxMvG006059@sunshine2.math.utah.edu> To: fdc@columbia.edu Auto-Submitted: auto-replied X-Mailer: vacation 1.50 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Subject: Not answering mail From: beebe@math.utah.edu (via the vacation program) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [127.0.0.1]); Fri, 26 Aug 2005 09:59:22 -0600 (MDT) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.170 Status: O X-Status: X-Keywords: X-UID: 239 I will be away from Salt Lake City from Friday 19 August 2005 until Monday 19 September 2005 Your mail regarding "Re: News of mm" will be read when I return. Because of my very heavy mail volume, responses may be delayed by weeks, or may prove impossible if your message requires more time time than I can afford. From fdc@columbia.edu Tue Sep 20 14:33:17 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8KIXH6g029769; Tue, 20 Sep 2005 14:33:17 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8KIXGUC010431; Tue, 20 Sep 2005 14:33:16 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id j8KIXGGQ010430; Tue, 20 Sep 2005 14:33:16 -0400 (EDT) Date: Tue, 20 Sep 2005 14:33:16 EDT From: Frank da Cruz To: Melissa Metz Subject: Re: MM and Cyrus In-Reply-To: <82f36d4dc837d78b466373990f0cf84d@columbia.edu> Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: O X-Status: X-Keywords: X-UID: 240 > As you know, one of our outstanding Cyrus issues is MM compatibility. > We don't want to tell MM users they are not compatible. I think MM can > work "with" Cyrus, by POP'ing mail into the UNIX space from Cyrus. > (This is technically working *around* Cyrus.) It would be using the > pop version of movemail we used to use way back when. This came as > part of emacs RMAIL But I haven't got anyone who could look into this. > We did enable kerberos on the Cyrus servers, so it should work if you > have a ticket and connect to mail.columbia.edu. > > Any chance you could look into this, as an interested MM user? We > could set you up with a test account or you could just send test > messages to fdc@cyrusfe.cc.columbia.edu. > I don't even pretend to understand the issues. We're moving to Cyrus because of... performance? But Cyrus is different... how? It demands an interface that standard Unix mail programs don't support? Is it that we need a Kerberized version of movemail? - Frank From fdc@columbia.edu Tue Sep 20 15:04:47 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8KJ4kmS010602 for ; Tue, 20 Sep 2005 15:04:46 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j8KJ4iu3014410; Tue, 20 Sep 2005 15:04:44 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id j8KJ4hZt014409; Tue, 20 Sep 2005 15:04:43 -0400 (EDT) Date: Tue, 20 Sep 2005 15:04:43 EDT From: Frank da Cruz To: Mark Crispin , Nelson Beebe Subject: [Melissa Metz : Re: MM and Cyrus] Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: O X-Status: X-Keywords: X-UID: 241 I've done a fair amount of hacking on MM itself, but I never did anything at all with movemail. Now it looks like I'll have to. Can either of you guys shed any light on the following? Thanks! (Mark, I know you think I should just give up and switch to Pine, but I can't help it, I love MM, always have, like I love EMACS and Kermit :-) - Frank --------------- On Sep 20, 2005, at 2:33 PM, Frank da Cruz wrote: >> As you know, one of our outstanding Cyrus issues is MM compatibility. We >> don't want to tell MM users they are not compatible. I think MM can work >> "with" Cyrus, by POP'ing mail into the UNIX space from Cyrus. (This is >> technically working *around* Cyrus.) It would be using the pop version >> of movemail we used to use way back when. This came as part of emacs >> RMAIL But I haven't got anyone who could look into this. >> >> We did enable kerberos on the Cyrus servers, so it should work if you >> have a ticket and connect to mail.columbia.edu. >> >> Any chance you could look into this, as an interested MM user? We could >> set you up with a test account or you could just send test messages to >> fdc@cyrusfe.cc.columbia.edu. > > I don't even pretend to understand the issues. We're moving to Cyrus > because of... performance? But Cyrus is different... how? It demands > an interface that standard Unix mail programs don't support? > > Is it that we need a Kerberized version of movemail? > > - Frank From: Melissa Metz Cc: Melissa Metz Subject: Re: MM and Cyrus Date: Tue, 20 Sep 2005 14:56:48 -0400 To: Frank da Cruz X-Mailer: Apple Mail (2.622) We are moving to Cyrus due to performance, mostly, and because it allows us to use cheaper disks which means we don't have to limit administrators to 20 MB (ridiculous). Cyrus supports standard mail interfaces. It does not support direct access, which MM uses (i.e. it looks in /var/mail for the incoming messages), because it keeps the mail in a "database" (mh-like) format, with index files etc. It supports POP and IMAP access. MM uses a program called movemail to move the mail from spool (setuid I think) so it doesn't really need to know how to get the mail itself. We used to use movemail in POP mode, where it would POP the mail from the incoming mail server. Right now movemail is using NFS mode, where it actually file locks the spool, copies the mail from spool into a file calling ~/incoming (or something like that), then empties the spool file. If we were using the POP form of movemail, MM would not know it was talking to Cyrus and it would be happy. For the most part it would be Cyrus-free. So the problem at hand is to figure out how to get movemail to use POP again -- e.g. do we need to download a different movemail or just configure of the current one. I think it had to do with setting your spool file to something like pop:mail.columbia.edu, but I don't recall precisely. The movemail we used to use was kerberized, so I figure any you find today still would be. Sorry to be a bit vague about this. --Melissa From fdc@columbia.edu Mon Oct 24 14:22:58 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9OIMvnE024793 for ; Mon, 24 Oct 2005 14:22:57 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j9OIMsEi009261; Mon, 24 Oct 2005 14:22:55 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id j9OIMsKE009260; Mon, 24 Oct 2005 14:22:54 -0400 (EDT) Date: Mon, 24 Oct 2005 14:22:54 EDT From: Frank da Cruz To: "Nelson H. F. Beebe" Subject: Re: Intel confusion over IA-32 and EM64T In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: O X-Status: X-Keywords: X-UID: 242 Hi Nelson, I see you are communicado again. Did you get my previous message about MM? Columbia is about to make it inoperative here unless I can get it working with IMAP or POP3 and I was wondering if you had already crossed that road. Also while you were gone I sat down to replace my version of MM with yours but discovered that none of my changes of the past few years were in it. Did I miss something? - Frank P.S. Welcome back! From fdc@columbia.edu Fri Nov 18 16:16:33 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jAILGX5G019926 for ; Fri, 18 Nov 2005 16:16:33 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jAILGJt6009119; Fri, 18 Nov 2005 16:16:19 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jAILGJMX009116; Fri, 18 Nov 2005 16:16:19 -0500 (EST) Date: Fri, 18 Nov 2005 16:16:19 -0500 (EST) Message-Id: <200511182116.jAILGJMX009116@sesame.cc.columbia.edu> From: Frank da Cruz To: Ian Beckwith Subject: Debian Movemail Reply-to: fdc@columbia.edu X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: O X-Status: X-Keywords: X-UID: 243 Hi Ian, I have a really stupid question. Back in the old days it was easy to find source code, like actual source files on the net in plain old out-in-the-open .c and .h files. Nowadays everything is packaged within an inch of its life inside of code management archives, RPMs, and debs and whatnot until it's almost impossible to find what you're looking for. I need an up-to-date version of movemail for POP3 (I think it comes with EMACS), so I can save MM (do you know what that is?) from extinction at Columbia, as CU cuts off the old direct-access mail system. It will be used on Red Hat Linux AS4 and on Solaris 9. Can you give me a clue where to find it? I know it's in the Debian archives but it's all debs and diffs. Any clues? Thanks. - Frank From fdc@columbia.edu Mon Nov 21 13:08:55 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jALI8sab024006; Mon, 21 Nov 2005 13:08:55 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jALI8sPF018170; Mon, 21 Nov 2005 13:08:54 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jALI8sji018169; Mon, 21 Nov 2005 13:08:54 -0500 (EST) Date: Mon, 21 Nov 2005 13:08:54 EST From: Frank da Cruz To: Joe Brennan Subject: Accessing POP server Cc: Melissa Metz Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: O X-Status: X-Keywords: X-UID: 244 Melissa asked me to ask you. I need to create a new movemail for mm. The Gnu one is hopeless. But I can write one from scratch using my favorite tool :-) I need to know how to access the pop server. It's pop.columbia.edu? What ports can I use? Is there a clear-text port? I assume there are also secure ones, what kinds? SSL? Kerberos? On which ports? Thanks! - Frank From ianb@nessie.mcc.ac.uk Mon Nov 21 18:57:33 2005 Flags: 000000000005 Return-Path: Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by dewberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jALNvTDk009873 for ; Mon, 21 Nov 2005 18:57:32 -0500 (EST) Received: from nessie.mcc.ac.uk ([130.88.200.20]) by serenity.mcc.ac.uk with esmtp (Exim 4.51 (FreeBSD)) id 1EeLXL-000MEE-8w for fdc@columbia.edu; Mon, 21 Nov 2005 23:57:27 +0000 Received: (from ianb@localhost) by nessie.mcc.ac.uk (8.11.6/8.11.6) id jALNvMY44384 for fdc@columbia.edu; Mon, 21 Nov 2005 23:57:22 GMT (envelope-from ianb) Date: Mon, 21 Nov 2005 23:57:21 +0000 From: Ian Beckwith To: Frank da Cruz Subject: Re: Debian Movemail Message-ID: <20051121235721.A43890@nessie.mcc.ac.uk> References: <20051121005425.A79507@nessie.mcc.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from fdc@columbia.edu on Mon, Nov 21, 2005 at 05:25:14PM -0500 X-UoM: Scanned by the University Mail System. See http://www.mcc.ac.uk/cos/email/scanning for details. X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.165 Status: O X-Status: X-Keywords: X-UID: 245 On Mon, Nov 21, 2005 at 05:25:14PM -0500, Frank da Cruz wrote: > > Short answer: > > > > http://www.uk.debian.org/debian/pool/main/m/mailutils/mailutils_0.6.90.orig.tar.gz > > > Can't get there from from here! (But it doesn't matter.) um.. maybe the uk mirror only accepts connections from within the uk in future, try www.us.debian.org > POP3 is simple enough I decided to implement in Kermit. That way I get > the network connection, SSL, etc, for free. First I'll try it as a Kermit > script; if there's something wrong with that approach, I'll put it in Kermit > itself. Anyway, thanks. Who know that movemail would have grown into > such a monster! You probably don't need this now you are implementing it yourself, but fetchmail might do what you want. http://fetchmail.berlios.de Ian. -- Ian Beckwith - ianb@nessie.mcc.ac.uk - http://nessie.mcc.ac.uk/~ianb/ GPG fingerprint: AF6C C0F1 1E74 424B BCD5 4814 40EC C154 A8BA C1EA From fdc@bacon.cc.columbia.edu Sat Dec 3 12:07:04 2005 Flags: 000000000001 Return-Path: Received: from bacon.cc.columbia.edu (bacon.cc.columbia.edu [128.59.59.185]) by jujube.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3H73AR006424 for ; Sat, 3 Dec 2005 12:07:03 -0500 (EST) Received: from bacon.cc.columbia.edu (localhost [127.0.0.1]) by bacon.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id jB3H73ge011441; Sat, 3 Dec 2005 12:07:03 -0500 Received: (from fdc@localhost) by bacon.cc.columbia.edu (8.13.1/8.13.1/Submit) id jB3H72Sl011438; Sat, 3 Dec 2005 12:07:02 -0500 Date: Sat, 3 Dec 2005 12:07:02 -0500 From: Frank da Cruz To: "Nelson H. F. Beebe" Subject: Re: News of mm In-Reply-To: Your message of Thu, 4 Aug 2005 16:49:15 -0600 (MDT) Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.28.170 Status: O X-Status: X-Keywords: X-UID: 246 Hi Nelson. I'm working on MM this weekend. I guess it's on me to reconcile my version and yours. Here's what I've been doing: http://www.columbia.edu/~fdc/mm/ (Still working on it, not finished yet.) I tried building yours again just to make sure I didn't miss anything but I still don't see any of my changes from version 0.91. I noticed that my version no longer builds at all under RH Linux AS4; the compilation bombs out instantly with prototype mismatches. So I built yours there to see what would happen. It did build successfully (I'm sending this to you now from the resulting binary), but it wasn't exactly clean, the log is enclosed (not attached :-) below. - Frank $ make OS=gnu-linux all ccmdmd.c: In function `intson': ccmdmd.c:884: warning: `sigblock' is deprecated (declared at ccmdmd.c:58) ccmdmd.c:886: warning: passing arg 2 of `signal' from incompatible pointer type ccmdmd.c:886: warning: assignment from incompatible pointer type ccmdmd.c:888: warning: passing arg 2 of `signal' from incompatible pointer type ccmdmd.c:890: warning: passing arg 2 of `signal' from incompatible pointer type ccmdmd.c:890: warning: assignment from incompatible pointer type ccmdmd.c:892: warning: passing arg 2 of `signal' from incompatible pointer type ccmdmd.c:893: warning: `sigsetmask' is deprecated (declared at ccmdmd.c:61) ccmdmd.c:896: warning: passing arg 2 of `signal' from incompatible pointer type ccmdmd.c:896: warning: assignment from incompatible pointercc -g -DDIRENTLIB -DSYSV -D_BSD_SOURCE -DHAVE_BCOPY -DHAVE_GNU_LINUX -DHAVE_MKSTEMP -DHAVE_UNSETENV -DHAVE_VPRINTF -c -o ccmdst.o ccmdst.c cc -g -DDIRENTLIB -DSYSV -D_BSD_SOURCE -DHAVE_BCOPY -DHAVE_GNU_LINUX -DHAVE_MKSTEMP -DHAVE_UNSETENV -DHAVE_VPRINTF -c -o ccmdut.o ccmdut.c cc -g -DDIRENTLIB -DSYSV -D_BSD_SOURCE -DHAVE_BCOPY -DHAVE_GNU_LINUX -DHAVE_MKSTEMP -DHAVE_UNSETENV -DHAVE_VPRINTF -c -o cmcfm.o cmcfm.c cc -g -DDIRENTLIB -DSYSV -D_BSD_SOURCE -DHAVE_BCOPY -DHAVE_GNU_LINUX -DHAVE_MKSTEMP -DHAVE_UNSETENV -DHAVE_VPRINTF -c -o cmchar.o cmchar.c cc -g -DDIRENTLIB -DSYSV -D_BSD_SOURCE -DHAVE_BCOPY -DHAVE_GNU_LINUX -DHAVE_MKSTEMP -DHAVE_UNSETENV -DHAVE_VPRINTF -c -o cmfil.o cmfil.c cc -g -DDIRENTLIB -DSYSV -D_BSD_SOURCE -DHAVE_BCOPY -DHAVE_GNU_LINUX -DHAVE_MKSTEMP -DHAVE_UNSETENV -DHAVE_VPRINTF -c -o cmfld.o cmfld.c cc -g -DDIRENTLIB -DSYSV -D_BSD_SOURCE -DHAVE_BCOPY -DHAVE_GNU_LINUX -DHAVE_MKSTEMP -DHAVE_UNSETENV -DHAVE_VPRINTF -c -o cmgrp.o cmgrp.c cc -g -DDIRENTLIB -DSYSV -D_BSD_SOURCE -DHAVE_BCOPY -DHAVE_GNU_LINUX -DHAVE_MKSTEMP -DHAVE_UNSETENV -DHAVE_VPRINTF Makefile:711: warning: overriding commands for target `gnu-linux' Makefile:704: warning: ignoring old commands for target `gnu-linux' Makefile:711: warning: overriding commands for target `gnu-linux' Makefile:704: warning: ignoring old commands for target `gnu-linux' action.c:12: warning: 'rcsid' defined but not used address.c:135: warning: cast discards qualifiers from pointer target type address.c:147: warning: cast discards qualifiers from pointer target type address.c:153: warning: cast discards qualifiers from pointer target type address.c:159: warning: cast discards qualifiers from pointer target type address.c:165: warning: cast discards qualifiers from pointer target type address.c:177: warning: cast discards qualifiers from pointer target type address.c:183: warning: cast discards qualifiers from pointer target type address.c:189: warning: cast discards qualifiers from pointer target type address.c:194: warning: cast discards qualifiers from pointer target type address.c:200: warning: cast discards qualifiers from pointer target type address.c:205: warning: cast discards qualifiers from pointer target type address.c:212: warning: cast discards qualifiers from pointer target type address.c:218: warning: cast discards qualifiers from pointer target type address.c:249: warning: cast discards qualifiers from pointer target type address.c:255: warning: cast discards qualifiers from pointer target type address.c:261: warning: cast discards qualifiers from pointer target type address.c:269: warning: cast discards qualifiers from pointer target type address.c:288: warning: cast discards qualifiers from pointer target type address.c:12: warning: 'rcsid' defined but not used alias.c: In function `free_alias': alias.c:101: warning: cast discards qualifiers from pointer target type alias.c: At top level: alias.c:12: warning: 'rcsid' defined but not used babyl.c:10: warning: 'rcsid' defined but not used browse.c:12: warning: 'rcsid' defined but not used cmds.c:12: warning: 'rcsid' defined but not used compat.c:11: warning: 'rcsid' defined but not used dates.c:10: warning: 'rcsid' defined but not used debug.c:10: warning: 'rcsid' defined but not used display.c:12: warning: 'rcsid' defined but not used doinit.c:12: warning: 'rcsid' defined but not used dt.c: In function `mkdate': dt.c:228: warning: passing arg 2 of `gettimeofday' from incompatible pointer type dt.c: At top level: dt.c:12: warning: 'rcsid' defined but not used edit.c: In function `do_edit_seqmsg': edit.c:176: warning: cast discards qualifiers from pointer target type edit.c: In function `gnuemacs_edit_outgoing': edit.c:350: warning: cast discards qualifiers from pointer target type edit.c: In function `spell_text': edit.c:811: warning: cast discards qualifiers from pointer target type edit.c:816: warning: cast discards qualifiers from pointer target type edit.c:825: warning: cast discards qualifiers from pointer target type edit.c:829: warning: cast discards qualifiers from pointer target type edit.c: At top level: edit.c:12: warning: 'rcsid' defined but not used exit.c:12: warning: 'rcsid' defined but not used file.c:14: warning: 'rcsid' defined but not used formattab.c:11: warning: 'rcsid' defined but not used headers.c: In function `skipheader': headers.c:69: warning: cast discards qualifiers from pointer target type headers.c:74: warning: cast discards qualifiers from pointer target type headers.c: In function `findheader': headers.c:133: warning: cast discards qualifiers from pointer target type headers.c: In function `search': headers.c:348: warning: cast discards qualifiers from pointer target type headers.c: At top level: headers.c:12: warning: 'rcsid' defined but not used help.c: In function `free_ktab': help.c:480: warning: cast discards qualifiers from pointer target type help.c: At top level: help.c:12: warning: 'rcsid' defined but not used init.c: In function `initialize': init.c:212: warning: passing arg 2 of `gettimeofday' from incompatible pointer type init.c: At top level: init.c:12: warning: 'rcsid' defined but not used keywords.c: In function `parse_old_keywords': keywords.c:267: warning: cast discards qualifiers from pointer target type keywords.c: In function `parse_current_keywords': keywords.c:448: warning: cast discards qualifiers from pointer target type keywords.c: At top level: keywords.c:12: warning: 'rcsid' defined but not used mailrc.c:11: warning: 'rcsid' defined but not used mbox.c: In function `mbox_wrmsg': mbox.c:286: warning: cast discards qualifiers from pointer target type mbox.c:294: warning: cast discards qualifiers from pointer target type mbox.c: At top level: mbox.c:10: warning: 'rcsid' defined but not used mh.c:11: warning: 'rcsid' defined but not used misc.c:12: warning: 'rcsid' defined but not used mm.c:12: warning: 'rcsid' defined but not used more.c:12: warning: 'rcsid' defined but not used move.c:12: warning: 'rcsid' defined but not used mtxt.c:10: warning: 'rcsid' defined but not used newmail.c:12: warning: 'rcsid' defined but not used parse.c:48: warning: cast discards qualifiers from pointer target type parse.c: In function `parse_keylist': parse.c:752: warning: cast discards qualifiers from pointer target type parse.c: In function `parse_filelist': parse.c:809: warning: cast discards qualifiers from pointer target type parse.c: In function `parse_keyword': parse.c:1094: warning: cast discards qualifiers from pointer target type parse.c: At top level: parse.c:12: warning: 'rcsid' defined but not used parsemsg.c:61: warning: cast discards qualifiers from pointer target type parsemsg.c:12: warning: 'rcsid' defined but not used pop2.c:11: warning: 'rcsid' defined but not used pop3.c:11: warning: 'rcsid' defined but not used print.c: In function `parse_listfile': print.c:187: warning: cast discards qualifiers from pointer target type print.c: At top level: print.c:12: warning: 'rcsid' defined but not used rd.c:11: warning: 'rcsid' defined but not used read.c:12: warning: 'rcsid' defined but not used send.c:12: warning: 'rcsid' defined but not used sendcmds.c:12: warning: 'rcsid' defined but not used sendmail.c:12: warning: 'rcsid' defined but not used seq.c:158: warning: cast discards qualifiers from pointer target type seq.c:161: warning: cast discards qualifiers from pointer target type seq.c:164: warning: cast discards qualifiers from pointer target type seq.c:166: warning: cast discards qualifiers from pointer target type seq.c:170: warning: cast discards qualifiers from pointer target type seq.c:174: warning: cast discards qualifiers from pointer target type seq.c:177: warning: cast discards qualifiers from pointer target type seq.c:181: warning: cast discards qualifiers from pointer target type seq.c:12: warning: 'rcsid' defined but not used set.c:96: warning: initialization makes integer from pointer without a cast set.c:98: warning: initialization makes integer from pointer without a cast set.c:99: warning: initialization makes integer from pointer without a cast set.c:105: warning: initialization makes integer from pointer without a cast set.c:114: warning: initialization makes integer from pointer without a cast set.c:116: warning: initialization makes integer from pointer without a cast set.c:12: warning: 'rcsid' defined but not used signals.c:11: warning: 'rcsid' defined but not used support.c:12: warning: 'rcsid' defined but not used token.c:10: warning: 'rcsid' defined but not used usage.c:11: warning: 'rcsid' defined but not used whoami.c:12: warning: 'rcsid' defined but not used mkversion.c:11: warning: 'rcsid' defined but not used In file included from version.c:21: cmds.h:10: warning: initialization discards qualifiers from pointer target type version.c:11: warning: 'rcsid' defined but not used mm.h:15: warning: 'mm_rcsid' defined but not used config.h:12: warning: 'config_rcsid' defined but not used s-gnulinux.h:13: warning: 's_gnulinux_rcsid' defined but not used osfiles.h:13: warning: 'osfiles_rcsid' defined but not used compat.h:13: warning: 'compat_rcsid' defined but not used chartype.h:13: warning: 'chart_rcsid' defined but not used pathnames.h:13: warning: 'pathnames_rcsid' defined but not used address.h:13: warning: 'addr_rcsid' defined but not used seq.h:13: warning: 'seq_rcsid' defined but not used extern.h:13: warning: 'extern_rcsid' defined but not used parse.h:13: warning: 'parse_rcsid' defined but not used keytab.h:13: warning: 'keytab_rcsid' defined but not used cmds.h:10: warning: 'cmds_rcsid' defined but not used message.h:13: warning: 'msg_rcsid' defined but not used babyl.h:13: warning: 'babyl_rcsid' defined but not used rd.h:13: warning: 'rd_rcsid' defined but not used set.h:13: warning: 'set_rcsid' defined but not used help.h:13: warning: 'help_rcsid' defined but not used sys-prof.c:12: warning: 'rcsid' defined but not used make[3]: Warning: File `Makefile' has modification time 1.5 s in the future regex.c: In function `print_compiled_pattern': regex.c:757: warning: int format, long unsigned int arg (arg 2) regex.c:757: warning: int format, long unsigned int arg (arg 3) regex.c: In function `regex_compile': regex.c:1680: warning: suggest explicit braces to avoid ambiguous `else' regex.c:1700: warning: suggest explicit braces to avoid ambiguous `else' regex.c: In function `compile_range': regex.c:2307: warning: cast discards qualifiers from pointer target type regex.c:2308: warning: cast discards qualifiers from pointer target type regex.c: In function `re_match_2': regex.c:3498: warning: unsigned int format, pointer arg (arg 2) regex.c:3893: warning: unsigned int format, pointer arg (arg 2) regex.c:3893: warning: cast discards qualifiers from pointer target type regex.c:3893: warning: unsigned int format, pointer arg (arg 2) regex.c:3893: warning: cast discards qualifiers from pointer target type regex.c:3893: warning: unsigned int format, different type arg (arg 2) regex.c:3893: warning: unsigned int format, pointer arg (arg 2) regex.c:3893: warning: unsigned int format, pointer arg (arg 2) regex.c:3893: warning: cast discards qualifiers from pointer target type regex.c:3893: warning: unused variable `destination' regex.c:3957: warning: cast discards qualifiers from pointer target type regex.c:3957: warning: cast discards qualifiers from pointer target type regex.c:4039: warning: unsigned int format, pointer arg (arg 3) regex.c:4041: warning: unsigned int format, pointer arg (arg 2) regex.c:4041: warning: cast discards qualifiers from pointer target type regex.c:4041: warning: unsigned int format, pointer arg (arg 2) regex.c:4041: warning: cast discards qualifiers from pointer target type regex.c:4041: warning: unsigned int format, different type arg (arg 2) regex.c:4041: warning: unsigned int format, pointer arg (arg 2) regex.c:4041: warning: unsigned int format, pointer arg (arg 2) regex.c:4041: warning: unused variable `destination' regex.c:4062: warning: unsigned int format, pointer arg (arg 3) regex.c:4094: warning: unsigned int format, pointer arg (arg 2) regex.c:4094: warning: cast discards qualifiers from pointer target type regex.c:4094: warning: unsigned int format, pointer arg (arg 2) regex.c:4094: warning: cast discards qualifiers from pointer target type regex.c:4094: warning: unsigned int format, different type arg (arg 2) regex.c:4094: warning: unsigned int format, pointer arg (arg 2) regex.c:4094: warning: unsigned int format, pointer arg (arg 2) regex.c:4094: warning: cast discards qualifiers from pointer target type regex.c:4094: warning: unused variable `destination' regex.c:4200: warning: declaration of 'failure_id' shadows a previous local regex.c:3323: warning: shadowed declaration is here regex.c:4200: warning: unsigned int format, pointer arg (arg 2) regex.c:4200: warning: unsigned int format, pointer arg (arg 2) regex.c:4200: warning: unsigned int format, pointer arg (arg 2) regex.c:4200: warning: int format, long unsigned int arg (arg 2) regex.c:4200: warning: int format, long unsigned int arg (arg 2) regex.c:4200: warning: unsigned int format, different type arg (arg 2) regex.c:4200: warning: unsigned int format, pointer arg (arg 2) regex.c:4200: warning: unsigned int format, pointer arg (arg 2) regex.c:4213: warning: unsigned int format, pointer arg (arg 2) regex.c:4233: warning: unsigned int format, pointer arg (arg 2) regex.c:4233: warning: cast discards qualifiers from pointer target type regex.c:4233: warning: unsigned int format, pointer arg (arg 2) regex.c:4233: warning: cast discards qualifiers from pointer target type regex.c:4233: warning: unsigned int format, different type arg (arg 2) regex.c:4233: warning: unused variable `destination' regex.c:4246: warning: unsigned int format, pointer arg (arg 2) regex.c:4246: warning: cast discards qualifiers from pointer target type regex.c:4246: warning: unsigned int format, pointer arg (arg 2) regex.c:4246: warning: cast discards qualifiers from pointer target type regex.c:4246: warning: unsigned int format, different type arg (arg 2) regex.c:4246: warning: unused variable `destination' regex.c:4262: warning: unsigned int format, pointer arg (arg 2) regex.c:4266: warning: unsigned int format, pointer arg (arg 2) regex.c:4296: warning: unsigned int format, pointer arg (arg 2) regex.c:4414: warning: declaration of 'failure_id' shadows a previous local regex.c:3323: warning: shadowed declaration is here regex.c:4414: warning: unsigned int format, pointer arg (arg 2) regex.c:4414: warning: unsigned int format, pointer arg (arg 2) regex.c:4414: warning: unsigned int format, pointer arg (arg 2) regex.c:4414: warning: unsigned int format, different type arg (arg 2) regex.c:4414: warning: unsigned int format, pointer arg (arg 2) regex.c:4414: warning: unsigned int format, pointer arg (arg 2) regex.c: In function `re_comp': regex.c:4805: warning: return discards qualifiers from pointer target type regex.c:4813: warning: return discards qualifiers from pointer target type regex.c:4818: warning: return discards qualifiers from pointer target type regex.c:4830: warning: cast discards qualifiers from pointer target type make[3]: warning: Clock skew detected. Your build may be incomplete. make[3]: Warning: File `Makefile' has modification time 1.1 s in the future make[3]: warning: Clock skew detected. Your build may be incomplete. mm-trans.c:10: warning: 'rcsid' defined but not used DEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -c signals.c gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -c support.c gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -c token.c gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -c usage.c gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -c whoami.c /bin/rm -f mkversion gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -DDEBUG -o mkversion mkversion.c whoami.o compat.o dates.o ../ccmd/ccmd.a -lcurses chmod ug+w version.h ./mkversion +e Updating version.h for Columbia MM 0.94.0(25) gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -c version.c /bin/rm -f mm gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -DDEBUG -o mm action.o address.o alias.o babyl.o browse.o cmds.o compat.o dates.o debug.o display.o doinit.o dt.o edit.o exit.o file.o formattab.o headers.o help.o init.o keywords.o mailrc.o mbox.o mh.o misc.o mm.o more.o move.o mtxt.o newmail.o novice.o parse.o parsemsg.o pop2.o pop3.o print.o rd.o read.o send.o sendcmds.o sendmail.o seq.o set.o signals.o support.o token.o usage.o whoami.o version.o ../ccmd/ccmd.a -lcurses gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -c sys-prof.c /bin/rm -f sys-prof gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -DDEBUG -o sys-prof sys-prof.o formattab.o ../ccmd/ccmd.a -lcurses (cd regex-0.12; \ CC='gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs' ./configure ; \ make CC='gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs' CFLAGS='-DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -DREGEX_MALLOC' regex.o) loading cache ./config.cache checking for gcc... (cached) cc -Xc checking whether we are using GNU C... (cached) no checking for a BSD compatible install... (cached) /opt/local/bin/install -c checking for POSIXized ISC... no checking how to run the C preprocessor... (cached) cc -Xc -E checking for minix/config.h... (cached) no checking for AIX... no checking for -lsun... (cached) no checking for -lseq... (cached) no checking for -lgen... (cached) no checking for getmntent... (cached) no checking whether cross-compiling... (cached) yes checking for ANSI C header files... (cached) yes checking for string.h... (cached) yes checking for working alloca.h... (cached) no checking for alloca... (cached) no checking whether alloca needs Cray hooks... (cached) no checking stack direction for C alloca... (cached) 0 checking for working const... (cached) yes checking for prefix by ... checking for gcc... (cached) /opt/local/bin/gcc creating ./config.status creating Makefile creating doc/Makefile creating test/Makefile make[3]: Entering directory `/hmt/prost/kd/fdc/mm/utah/mm-0.94/mm/regex-0.12' gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -DREGEX_MALLOC -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DC_ALLOCA=1 -DSTACK_DIRECTION=0 -I. -I. -c regex.c make[3]: Leaving directory `/hmt/prost/kd/fdc/mm/utah/mm-0.94/mm/regex-0.12' (cd regex-0.12/test; \ make CC='gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs' CFLAGS='-DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE' printchar.o) make[3]: Entering directory `/hmt/prost/kd/fdc/mm/utah/mm-0.94/mm/regex-0.12/test' gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -I. -I. -I../. -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DC_ALLOCA=1 -DSTACK_DIRECTION=0 -DDEBUG -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -c printchar.c make[3]: Leaving directory `/hmt/prost/kd/fdc/mm/utah/mm-0.94/mm/regex-0.12/test' gcc -Wall -Wshadow -Wcast-qual -Wpointer-arith -Wwrite-strings -Wnested-externs -DDEBUG -I../ccmd -DUSAGE -DS_FILE=\"s-gnulinux.h\" -g -DHAVE_GNU_LINUX -DHAVE_BCOPY -DHAVE_UNSETENV -DHAVE_VPRINTF -D_BSD_SOURCE -DDEBUG -o mm-trans mm-trans.c regex-0.12/regex.o regex-0.12/test/printchar.o ../ccmd/ccmd.a -lcurses make[2]: Leaving directory `/hmt/prost/kd/fdc/mm/utah/mm-0.94/mm' make[1]: Leaving directory `/hmt/prost/kd/fdc/mm/utah/mm-0.94/mm' (end) From fdc@columbia.edu Sat Dec 3 13:01:37 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3I1bqu017990 for ; Sat, 3 Dec 2005 13:01:37 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3I1a0M026820; Sat, 3 Dec 2005 13:01:36 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB3I1ajx026819; Sat, 3 Dec 2005 13:01:36 -0500 (EST) Date: Sat, 3 Dec 2005 13:01:36 EST From: Frank da Cruz To: Mark Crispin Subject: MS Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: O X-Status: X-Keywords: X-UID: 247 Hi Mark, where do find MS and cclient? I'm assuming that MS would "just work" with Cyrus, since it's an IMAP client (assuming it can be built on Solaris). At the moment I'm getting Columbia MM to work with Cyrus by providing a movemail replacement that's a POP3/TLS client. I'm a little bummed out that Nelson Beebe did so much work on Columbia MM without first taking the current version, and that he hasn't responded to any of my mail about this. So now we have my version, his, yours (which is not exactly Columbia MM, but close), and I suppose Bill Westfield's, and who knows what other ones. Just trying to sort this out for myself, it helps to write it down: http://www.columbia.edu/~fdc/mm/ Thanks. - Frank From mrc@CAC.Washington.EDU Sat Dec 3 13:40:31 2005 Flags: 000000000015 Return-Path: Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by dewberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3IeRIG020999 for ; Sat, 3 Dec 2005 13:40:30 -0500 (EST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB3IeQ0a023739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 3 Dec 2005 10:40:27 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB3IeI86014085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 3 Dec 2005 10:40:26 -0800 Date: Sat, 3 Dec 2005 10:40:17 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Frank da Cruz Subject: Re: MS In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.165 Status: O X-Status: X-Keywords: X-UID: 248 On Sat, 3 Dec 2005, Frank da Cruz wrote: > Hi Mark, where do find MS and cclient? I'm assuming that MS would > "just work" with Cyrus, since it's an IMAP client (assuming it can be > built on Solaris). UW IMAP toolkit (including c-client): ftp://ftp.cac.washington.edu/mail/imap.tar.Z MS: ftp://ftp.cac.washington.edu/mail/ms.tar.Z I have done no work at all on MS in over 10 years, or have even tried to build it on modern machines. I certainly never tried on Solaris (ugh!). > So now we have my version, his, yours (which is > not exactly Columbia MM, but close), and I suppose Bill Westfield's, and who > knows what other ones. MS is not a version of Columbia MM. It is simply a very basic IMAP client with a TOPS-20 MM (not Columbia MM) like interface. It uses Columbia CCMD, that's all; it does not use any Columbia MM code. Its utility was long subsumed by Pine. There's a lot that MS does not do, including things that TOPS-20 MM and Columbia MM do. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From fdc@columbia.edu Sat Dec 3 13:43:12 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3IhCbX029358 for ; Sat, 3 Dec 2005 13:43:12 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3Ih9D1002170; Sat, 3 Dec 2005 13:43:09 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB3Ih9Dq002169; Sat, 3 Dec 2005 13:43:09 -0500 (EST) Date: Sat, 3 Dec 2005 13:43:09 EST From: Frank da Cruz To: Mark Crispin Subject: Re: MS In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: O X-Status: X-Keywords: X-UID: 249 > UW IMAP toolkit (including c-client): > ftp://ftp.cac.washington.edu/mail/imap.tar.Z > MS: ftp://ftp.cac.washington.edu/mail/ms.tar.Z > > I have done no work at all on MS in over 10 years, or have even tried to > build it on modern machines. I certainly never tried on Solaris (ugh!). > Nothing is easy. > > So now we have my version, his, yours (which is not exactly Columbia MM, > > but close), and I suppose Bill Westfield's, and who knows what other > > ones. > > MS is not a version of Columbia MM. It is simply a very basic IMAP client > with a TOPS-20 MM (not Columbia MM) like interface. It uses Columbia > CCMD, that's all; it does not use any Columbia MM code. > Right, that's what I figured. > Its utility was long subsumed by Pine. There's a lot that MS does not > do, including things that TOPS-20 MM and Columbia MM do. > Understood, still want to see it :-) Thanks. - Frank From fdc@columbia.edu Sat Dec 3 14:39:18 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3JdI5G002762 for ; Sat, 3 Dec 2005 14:39:18 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3JdHBB009313; Sat, 3 Dec 2005 14:39:17 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB3JdGxx009308; Sat, 3 Dec 2005 14:39:16 -0500 (EST) Date: Sat, 3 Dec 2005 14:39:16 EST From: Frank da Cruz To: Mark Crispin Subject: Re: MS In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: O X-Status: X-Keywords: X-UID: 250 > On Sat, 3 Dec 2005, Frank da Cruz wrote: > >> I have done no work at all on MS in over 10 years, or have even tried to > >> build it on modern machines. I certainly never tried on Solaris (ugh!). > > Nothing is easy. > > I'm surprised that you guys are still using Solaris. I guess that you > must be suckers for punishment. After years of repeated mistreatment by > SUN and equally repeated second-changes so they would stay in the running > on the next major round of hardware purchases, we gave up on them. > I'm just a user, I'm not in charge of anything any more. But in fact, we (they) are building up a parallel universe on Linux and will switch over at some point. Most people have Mac OS X on the desktop, but I have Windows because I have to support Kermit 95 (I'm the only left left, everybody else has been laid off). > We still have some bits and pieces of SVR4 UNIX (AIX no less, another > horror story there) but the last holdouts are being exterminated. > Otherwise, we're a Linux shop. I never tried building the 1988 version of > CCMD (which is what I have) on Linux. > Somewhere between Red Hat 7.1 and AS4.2, it became impossible. But Nelson's version builds OK. > If you get MS working on modern systems (Linux, Mac OS X) I'd be > interested. > I'll let you know! - Frank From mrc@CAC.Washington.EDU Sat Dec 3 15:25:15 2005 Flags: 000000000001 Return-Path: Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by marionberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3KPBUj024162 for ; Sat, 3 Dec 2005 15:25:14 -0500 (EST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB3KPAoG000848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 3 Dec 2005 12:25:10 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB3KP87s018939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 3 Dec 2005 12:25:10 -0800 Date: Sat, 3 Dec 2005 12:25:07 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Frank da Cruz Subject: Re: MS In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.167 Status: O X-Status: X-Keywords: X-UID: 251 On Sat, 3 Dec 2005, Frank da Cruz wrote: > I'm just a user, I'm not in charge of anything any more. Are congratulations or condolences in order? > But in fact, we > (they) are building up a parallel universe on Linux and will switch over at > some point. Most people have Mac OS X on the desktop, but I have Windows > because I have to support Kermit 95 (I'm the only left left, everybody else > has been laid off). I use both the Windows and Mac OS X desktop on a daily basis; my laptop and office desktop are both Windows, whereas the home desktop is Mac. I find that there's still too much of the "Apple Kool-Aid" in the Mac world for my taste, and I basically just use the Mac as a UNIX/X environment. Safari is about the only Mac program that I run. So Kermit is no longer a big thing at Columbia? I guess that the world has changed quite a bit since Kermit's heyday. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From fdc@columbia.edu Sat Dec 3 16:14:58 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3LEwZD013678 for ; Sat, 3 Dec 2005 16:14:58 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3LEu4h022858; Sat, 3 Dec 2005 16:14:56 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB3LEuw7022857; Sat, 3 Dec 2005 16:14:56 -0500 (EST) Date: Sat, 3 Dec 2005 16:14:56 EST From: Frank da Cruz To: Mark Crispin Subject: Re: MS In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: O X-Status: X-Keywords: X-UID: 252 > On Sat, 3 Dec 2005, Frank da Cruz wrote: > > It starts, but "?Can't open connection to any server". > > Both mtest and ms have "mailhost" wired in as the SMTP server. You'll > have to edit the source code to change that, or define mailhost in your > DNS or host table as your SMTP server. In ms, it's the hostlist table. > You'll probably also want to edit newlist. > OK, thanks. > So what exactly is it that you do these days? > I am the Kermit Project, I do everything from writing software to tech support to documentation to being webmaster to taking orders and packing up boxes and lugging them to UPS or Fedex. It used to be 7-8 people. It's a comedown, but it still beats the ratrace of useless meetings, task forces, working groups, white papers, and all the rest. At least what I do is real. Also I have various hobbies: http://www.columbia.edu/acis/history/ <-- History of computing http://www.columbia.edu/kermit/postal.html <-- internat'l postal addressing http://www.columbia.edu/kermit/utf8.html <-- Unicode But nobody would pay me to do any of that either. > I'm still doing the same sorts of things that I was doing 17 years ago, > although the bureaucracy is now much more complex in the past. > That's how it goes. Max Weber's law of organizations, the bureaucratize themselves into oblivion. > So is it still a proprietary product or has it been put into open source > or??? > The Windows version is proprietary, but the non-Windows-specific parts of it are based on C-Kermit, which is out in the open, if not Open Source (TM). I would make it all Open Source if Columbia would agree to pay my salary and let me keep doing this another 4-5 years, but they won't do that because it would cost them money. As matters stand, I pay my own salary out of income. Which is why Kermit has kind of an unusual license: http://www.columbia.edu/kermit/license.html Btw Kermit 95 is really kind of a neat terminal emulator, I'm especially proud of this: http://www.columbia.edu/kermit/glass.html - Frank From fdc@columbia.edu Sat Dec 3 16:32:08 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3LW7Qf018051 for ; Sat, 3 Dec 2005 16:32:07 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB3LW43e025187; Sat, 3 Dec 2005 16:32:04 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB3LW4ZF025186; Sat, 3 Dec 2005 16:32:04 -0500 (EST) Date: Sat, 3 Dec 2005 16:32:04 EST From: Frank da Cruz To: Mark Crispin Subject: Re: MS In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: O X-Status: X-Keywords: X-UID: 253 > Both mtest and ms have "mailhost" wired in as the SMTP server. You'll > have to edit the source code to change that, or define mailhost in your > DNS or host table as your SMTP server. In ms, it's the hostlist table. > You'll probably also want to edit newlist. > OK, next hurdle... MTest>s To: fdc@columbia.edu cc: Subject: testing 1 2 3 Msg (end with a line with only a '.'): this is a test using mtest. . Sending... [Trying IP address [128.59.48.36]] ?Connection failed to mail.columbia.edu,25: Connection refused [Trying IP address [128.59.48.2]] ?Connection failed to pop-vif.cc.columbia.edu,25: Connection refused ?No such host as mailhost [Trying IP address [127.0.0.1]] ?Can't connect to localhost,25: Connection refused [Can't open connection to any server] MTest>check It seems nobody around here accepts connections on port 25. To send mail, you have to feed it to sendmail through a pipe. - Frank From fdc@columbia.edu Mon Dec 5 13:38:48 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB5IcnQU020699 for ; Mon, 5 Dec 2005 13:38:49 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB5Icmgc022308; Mon, 5 Dec 2005 13:38:48 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB5Icmfu022307; Mon, 5 Dec 2005 13:38:48 -0500 (EST) Date: Mon, 5 Dec 2005 13:38:48 EST From: Frank da Cruz To: Mark Crispin Subject: Re: MS In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: > On Mon, 5 Dec 2005, Frank da Cruz wrote: > > and now I can send mail. > > Good. One problem down. > > > How about reading mail? I think it must be > > contacting our IMAP server since it takes a long time to start up. > > It opens local INBOX (that too is wired within ms). You have to do a GET > command to open an IMAP mailbox. Try > GET {imapserver.example.com}INBOX > OK, that works! And I see that if I give a subsequent GET command (with no args) it gets any messages that arrived since the last one, without having to reauthenticate. Perfect. > If it's taking a while to start up, could it be a DNS delay looking up the > local host name? > Our servers are really really clogged, hence the transition to Cyrus. > > Do I have to rebuild c-client also? > > No. Any problems are almost certainly within ms, not c-client. Remember, > c-client is also used by Pine, imapd, ipop3d, etc. > You're right of course but it might have been that people here hacked it up. It wouldn't be the first time... OK, thanks, now we have another toy! - Frank From MRC@CAC.Washington.EDU Mon Dec 5 14:25:11 2005 Flags: 000000000011 Return-Path: Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by dewberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB5JPG8F002694 for ; Mon, 5 Dec 2005 14:25:20 -0500 (EST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB5JPFWD016577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Dec 2005 11:25:16 -0800 X-Auth-Received: from Shimo-Tomobiki.panda.com (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB5JPDep023158 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 5 Dec 2005 11:25:15 -0800 Date: Mon, 5 Dec 2005 11:25:11 -0800 From: Mark Crispin To: Frank da Cruz Subject: Re: MS In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing Sender: mrc@ndcms.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.165 Status: On Mon, 5 Dec 2005, Frank da Cruz wrote: > OK, that works! And I see that if I give a subsequent GET command > (with no args) it gets any messages that arrived since the last one, without > having to reauthenticate. Perfect. Don't do another GET. That re-SELECTs the mailbox and thus forfeits all the hard-won IMAP state in c-client. Just do CHECK. Or just wait until it notices the new mail on its own. You only need to do another GET for POP3 sessions. >> If it's taking a while to start up, could it be a DNS delay looking up the >> local host name? > Our servers are really really clogged, hence the transition to Cyrus. The startup delay has nothing to do with IMAP servers. There's only a few things that happen at startup. I'll bet that if you run ms under gdb and then stop it when it's taking a while to start up, the stack will show what is taking so long. I'll be that it's doing a DNS lookup of the local name. Cyrus is a good server. You were using my server up to now, right? The Cyrus developers work pretty closely with me; we're not really in any kind of competition. My server's focus is general utility and installation/maintenance ease. Cyrus is a specialized server, for a special audience. If a site looks like a "Cyrus kind of site" I will be the first to recommend that they consider it. Whatever you do, avoid the Courier server. I'm not a member of the maildir religion anyway; but for those who are in that church they should look at Dovecot and not Courier. Courier violates IMAP protocol all over the place. >>> Do I have to rebuild c-client also? >> No. Any problems are almost certainly within ms, not c-client. Remember, >> c-client is also used by Pine, imapd, ipop3d, etc. > You're right of course but it might have been that people here hacked it up. > It wouldn't be the first time... I doubt that any local hack to c-client would make a difference. More likely, it's that ms has lots of stuff wired into it. It doesn't have any configuration file. ms really is, at best, a half-finished program. It looks a lot like MM in interface, but half of the work in a program is in the transition from "toy" to "production quality" and ms never got that. My efforts went first into MailManager on the NeXT and then later my contributions towards Pine. You really should take a good look at Pine. I know that it doesn't look at all like MM; but deep inside Pine, MM's heart is beating. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From MRC@CAC.Washington.EDU Mon Dec 5 15:40:08 2005 Flags: 000000000011 Return-Path: Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by elderberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB5KeEnq019048 for ; Mon, 5 Dec 2005 15:40:18 -0500 (EST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB5KeEi6012707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Dec 2005 12:40:14 -0800 X-Auth-Received: from Shimo-Tomobiki.panda.com (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB5KeAUw013224 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 5 Dec 2005 12:40:13 -0800 Date: Mon, 5 Dec 2005 12:40:08 -0800 From: Mark Crispin To: Frank da Cruz Subject: Re: MS In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing Sender: mrc@ndcms.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.166 Status: On Mon, 5 Dec 2005, Frank da Cruz wrote: > The kind of work nobody wants to pay anybody to do any more, kind of like > Kermit. I like developing universally useful software, like many of us from > the old days, and very few of us get to do it any more, at least not for pay. > You're the lucky one. We have a very unique combination of good people and good management at UW. I sometimes worry that it may all vanish one day, but fortunately most of the people who make those decisions seem happy with us. The greatest danger is that as an organization we are becoming too large and risk-adverse. > RMS > has to go off on a crazy tangent, etc. Here I must disagree. RMS chose his course, for reasons that are far less noble than he (or his acolytes) would have you believe. RMS happened to be at the right place and the right time. RMS is far more power-mad than any of the people that he's damned over the years. He talks a good talk about his idealized communistic world of unlimited freedom, but like most communists he has no intention whatsoever of actually allowing such freedom. Rather, he covets totalitarian power to run things "for the good of everybody else." In my opinion, RMS has been incredibly damaging to free software and open > I don't really care, but it's amazing what a mess > everything is. Like security. SCP for this, TLS for that, SSH for this, > GSSAPI for that... A few years ago we had a coherent Kerberos-based security > architecture with single network login. Now it's all gone to crap. Nobody > even understands it. We live in a different world, with far more serious threats than anything we ever faced in the past. Fortunately, it's not quite as bad as you think. For what it's worth, there are three basic security mechanisms: Kerberos (GSSAPI) TLS (SSL) SSH (SCP) In theory, any of these can do the job of the other two. I consider SSH in particular to be pointless; it could/should have been done via TLS secured TELNET. Although Kerberos can do encryption and TLS can do authentication, the world has evolved with Kerberos to do client authentication and TLS to do encryption and server authentication. TLS is far more lightweight than Kerberos (thus making it easier to deploy) but TLS client certificates don't scale well so Kerberos works better for that. GSSAPI is just a UNIX API for security software, just as SSPI is used for Windows. It's mostly used for Kerberos (OpenSSL is the preferred TLS API), although it really is as general and powerful as SSPI. However, for the most part, you can forget all that and think "GSSAPI == KerberosV5". SSL is just the old name for earlier versions of TLS. SCP is just a file copying mode of SSH. > I know but this is not just for me. There are quite a few MM stalwarts left > at Columbia (and elsewhere) who can't live without it. For myself, no > matter how good Pine is, I just really can't abide menus, arrow keys, and > all the rest. There's a definite learning curve here, true. However, in general it is almost always possible to do everything you can do in MM in Pine, and with fewer keystrokes. > I can fly like the wind with MM, Pine slows me down and, as > far as I know, doesn't do half the stuff I normally do with MM (searching > with combined criteria, etc). You can do it. However, that feature may be turned off in the default "rubber room" mode. There's quite a lot in Pine, much more than MM ever did, but it's hidden unless you enable the feature. > For example, how do you suspend > it? Sometimes I realize I need to do something else before I can send the > message and Ctrl-Z doesn't do anything. Ah, you're definitely in rubber room mode. It prevents you from doing Ctrl-Z to save you from yourself. The feature to enable is "enable-suspend". I like setting "use-subshell-for-suspend" as well, which makes Ctrl-Z be effectively like a PUSH command in MM. > Oh yeah, and also I want my editor to be real EMACS, not Pico. Set "alternative-editor" to emacs. There's an option to declare that you always want the alternative editor, although I prefer going into Pico by default and only go into the alternative editor when it's something complex. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From fdc@columbia.edu Mon Dec 5 17:22:26 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB5MMTrI003749 for ; Mon, 5 Dec 2005 17:22:29 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB5MMQTi021052; Mon, 5 Dec 2005 17:22:26 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB5MMQQd021051; Mon, 5 Dec 2005 17:22:26 -0500 (EST) Date: Mon, 5 Dec 2005 17:22:26 EST From: Frank da Cruz To: Mark Crispin Subject: Re: MS In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: > > RMS has to go off on a crazy tangent, etc. > > Here I must disagree. RMS chose his course... > I was trying to say it nicely :-) > For what it's worth, there are three basic security mechanisms: > Kerberos (GSSAPI) > TLS (SSL) > SSH (SCP) > Right, I know all about this; we have implemented all of them in Kermit 95 (and SRP as well). > In theory, any of these can do the job of the other two. I consider SSH > in particular to be pointless; it could/should have been done via TLS > secured TELNET. > We fought long and hard against SSH and, of course, lost. At Columbia we had Telnet and FTP secured by Kerberos IV, Kerberos V, and SSL/TLS. That was a few years ago; now we have actually taken those services away and force people to use different authentication methods to access different services, so there is an unmanageable proliferation of certificates, public and private keys, etc etc. I consider public/private key authentication to be a disaster because it is not centrally manageable. If I hack into your Windows PC (how hard can THAT be?) and grab your SSH keys, and decrypt them offline, I own your world, and there is nothing anybody can do about it. No certificate revocations, no ticket expirations, etc etc. > Although Kerberos can do encryption and TLS can do authentication, the > world has evolved with Kerberos to do client authentication and TLS to do > encryption and server authentication. TLS is far more lightweight than > Kerberos (thus making it easier to deploy) but TLS client certificates > don't scale well so Kerberos works better for that. > Right. Columbia doesn't bother with client certs at all. > You can do it. However, that feature may be turned off in the default > "rubber room" mode. There's quite a lot in Pine, much more than MM ever > did, but it's hidden unless you enable the feature. > You can bet that they don't enable anything in the Columbia version. Since the mid-90s the trend here has been strictly to dumb down everything. That's one of the reasons, for example, why Columbia stopped recommending Kermit as its terminal emulator for Windows. Too complicated, does too many things. > > For example, how do you suspend > > it? Sometimes I realize I need to do something else before I can send the > > message and Ctrl-Z doesn't do anything. > > Ah, you're definitely in rubber room mode. It prevents you from doing > Ctrl-Z to save you from yourself. > Perfect. > The feature to enable is "enable-suspend". I like setting > "use-subshell-for-suspend" as well, which makes Ctrl-Z be effectively like > a PUSH command in MM. > Not to be perfectly stupid, but where do I put "enable-suspend"? You mean I can have a configuration file containing text commands? (Sorry.) > > Oh yeah, and also I want my editor to be real EMACS, not Pico. > > Set "alternative-editor" to emacs. There's an option to declare that you > always want the alternative editor, although I prefer going into Pico by > default and only go into the alternative editor when it's something > complex. > Learn something every day! Thanks. - Frank From fdc@columbia.edu Mon Dec 5 17:44:59 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB5MixlU003154; Mon, 5 Dec 2005 17:44:59 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB5Mixr9023884; Mon, 5 Dec 2005 17:44:59 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB5MixWQ023883; Mon, 5 Dec 2005 17:44:59 -0500 (EST) Date: Mon, 5 Dec 2005 17:44:59 EST From: Frank da Cruz To: emailtech-wg@columbia.edu Subject: The MS IMAP client Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: I got Mark Crispin's MS program working. As noted earlier, this is an MM-like program (more like the original DEC-20 MM than Columbia MM) that's an IMAP client. I updated my page with instructions for testing: http://www.columbia.edu/~fdc/mm/ - Frank From fdc@columbia.edu Thu Dec 8 11:34:50 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8GYoQb024080; Thu, 8 Dec 2005 11:34:50 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8GYoSC016084; Thu, 8 Dec 2005 11:34:50 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8GYodf016083; Thu, 8 Dec 2005 11:34:50 -0500 (EST) Date: Thu, 8 Dec 2005 11:34:50 -0500 (EST) From: Frank da Cruz To: emailtech-wg@columbia.edu Subject: MM locks Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: Yesterday's MM does not lock the mail file. This is because the locking code was taken out of the 0.94 version at the U of Utah, for reasons explained in the last three paragraphs of this document: http://www.columbia.edu/~fdc/mm/utah.html My question is: should I leave it without locks, thus eliminating the help-desk calls when an MM process is orphaned on Cunix, or put them back? Or... Should I change it to use file-based locks, which users themselves can clean up? Maybe I just answered my own question. - Frank From fdc@columbia.edu Thu Dec 8 11:47:03 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8GlIrh018807 for ; Thu, 8 Dec 2005 11:47:18 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8Gl4ve017717; Thu, 8 Dec 2005 11:47:04 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8Gl3N4017715; Thu, 8 Dec 2005 11:47:03 -0500 (EST) Date: Thu, 8 Dec 2005 11:47:03 -0500 (EST) From: Frank da Cruz To: tops20@lingling.panda.com Subject: Announcing MM 0.95 Beta Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: It wasn't as hard as I thought it would be, reconciling Nelson Beebe's modernized MM code with my version. I'm calling the result 0.95. I updated my MM page accordingly: http://www.columbia.edu/~fdc/mm/ I haven't done a huge amount of testing except on Solaris, where it has been working just fine under heavy use with an 11MB mail file since yesterday. But I did build it successfully on RH Linux AS4.2, and was able to send and read mail with it. I presume it will also build and run on all the other platforms where Nelson says it will, including Mac OS X, HP-UX, Tru64, etc, but I'd like some verification. The source package is here: ftp://kermit.columbia.edu/kermit/mm/test/mm-ccmd-0.95-20051207.tar.gz Nelson, if you're reading this I'd appreciate hearing if it's usable at your place. Whoever is responsible for the installation at Panix should check it out there, etc. This is not a final release, just a first beta. - Frank From fdc@columbia.edu Thu Dec 8 12:47:04 2005 Flags: 000000000001 Return-Path: Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by feta.cc.columbia.edu (8.13.0/8.13.0) with SMTP id jB8I1KKO004397; Thu, 8 Dec 2005 13:01:23 -0500 (EST) Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Thu, 8 Dec 2005 09:47:11 -0800 (PST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8Hl4H6025564; Thu, 8 Dec 2005 12:47:04 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8Hl4rv025562; Thu, 8 Dec 2005 12:47:04 -0500 (EST) Date: Thu, 8 Dec 2005 12:47:04 -0500 (EST) From: Frank da Cruz To: tops-20@lingling.panda.com Subject: Announcing MM 0.95 Beta Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.164 Status: This is to announce the merger of Nelson Beebe's modernized MM code with my version. I'm calling the result 0.95 (= 0.91 + 0.94). Nelson's version is mainly an updating to modern coding standards to allow MM to be built on many platforms with modern compilers, libs, and header files, plus some bug fixes; he explains it here: http://www.columbia.edu/~fdc/mm/utah.html My version has the new features listed here: http://www.columbia.edu/~fdc/mm/ including downloading messages to desktop, a method for sending 8-bit mail, etc, and (this past week) a POP interface. I haven't done a huge amount of testing except on Solaris, where it has been working just fine under heavy use with an 11MB mail file. But I did build it successfully on RH Linux AS4.2, and was able to send and read mail with it. I presume it will also build and run on all the other platforms where Nelson says it will, including Mac OS X, HP-UX, Tru64, etc, but I'd like some verification. The source package is here: ftp://kermit.columbia.edu/kermit/mm/test/mm-ccmd-0.95-20051208.tar.gz Nelson, if you're reading this I'd appreciate hearing if it's usable at your place. Whoever is responsible for the installation at Panix should check it out there, etc. This is not a final release, just a first beta. - Frank From mrc@CAC.Washington.EDU Thu Dec 8 13:22:43 2005 Flags: 000000000011 Return-Path: Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by elderberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8IMk9X010715 for ; Thu, 8 Dec 2005 13:22:49 -0500 (EST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB8IMjOx012315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Dec 2005 10:22:45 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB8IMhrr012418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Dec 2005 10:22:45 -0800 Date: Thu, 8 Dec 2005 10:22:43 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Frank da Cruz Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.166 Status: On Thu, 8 Dec 2005, Frank da Cruz wrote: > My version has the new features listed here: > http://www.columbia.edu/~fdc/mm/ Please make the correction I requested to this web page. I never used MS as my "primary email client for years"; it was only for a few months between the time I wrote MS in November 1988 and MailManager for the NeXT in early 1989. Otherwise, it implies much more behind MS than actually exists. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From fdc@columbia.edu Thu Dec 8 13:25:33 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8IPbdY016635 for ; Thu, 8 Dec 2005 13:25:37 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8IPXOH000550; Thu, 8 Dec 2005 13:25:33 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8IPXCC000534; Thu, 8 Dec 2005 13:25:33 -0500 (EST) Date: Thu, 8 Dec 2005 13:25:33 -0500 (EST) From: Frank da Cruz To: Mark Crispin Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: > On Thu, 8 Dec 2005, Frank da Cruz wrote: > > My version has the new features listed here: > > http://www.columbia.edu/~fdc/mm/ > > Please make the correction I requested to this web page. I never used MS > as my "primary email client for years"; it was only for a few months > between the time I wrote MS in November 1988 and MailManager for the NeXT > in early 1989. > I did (before I sent the email) - hit the reload button :-) Anyway index.html is just a symlink to the current beta version, so if your cache is overaggressive, then visit the real file at: http://www.columbia.edu/~fdc/mm/beta02.html (real name will change from time to time). - Frank From fdc@columbia.edu Thu Dec 8 13:28:06 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8IS7o2017283 for ; Thu, 8 Dec 2005 13:28:07 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8IS6Na000892; Thu, 8 Dec 2005 13:28:06 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8IS6J9000891; Thu, 8 Dec 2005 13:28:06 -0500 (EST) Date: Thu, 8 Dec 2005 13:28:06 -0500 (EST) From: Frank da Cruz To: Mark Crispin Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: > Otherwise, it implies much more behind MS than actually exists. > I forgot to say, send me whatever working you want; I'll put it in. Some people here were excited to hear about MS because it's an MM-like program that's an IMAP client AND it's simple. At Columbia, "simple" is not a drawback. - Frank From phil@ultimate.com Thu Dec 8 13:49:58 2005 Flags: 000000000011 Return-Path: Received: from mx.tripadvisor.com (mx.tripadvisors.com [151.203.96.35]) by feta.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8Io5ZA020239 for ; Thu, 8 Dec 2005 13:50:08 -0500 (EST) Received: from c-66-30-204-193.hsd1.ma.comcast.net (c-66-30-204-193.hsd1.ma.comcast.net [66.30.204.193]) by mx.tripadvisor.com (8.13.3/8.13.3) with ESMTP id jB8Inx4H024930 for ; Thu, 8 Dec 2005 13:50:04 -0500 (EST) (envelope-from phil@ultimate.com) Received: (from phil@localhost) by ultimate.com (8.13.4/8.13.4) id jB8Inw4h020017 for fdc@columbia.edu; Thu, 8 Dec 2005 13:49:58 -0500 (EST) Date: Thu, 8 Dec 2005 13:49:58 -0500 (EST) From: Phil Budne Message-Id: <200512081849.jB8Inw4h020017@ultimate.com> To: fdc@columbia.edu Subject: Re: Announcing MM 0.95 Beta X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.164 Status: Neat! P.S. I didn't know MS was still available, and worked. I thought MRC had disowned it (and tells people to use Pine instead)! phil From fdc@columbia.edu Thu Dec 8 13:54:50 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8IssWt003737 for ; Thu, 8 Dec 2005 13:54:54 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8Isslh004330; Thu, 8 Dec 2005 13:54:54 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8Isoo0004329; Thu, 8 Dec 2005 13:54:50 -0500 (EST) Date: Thu, 8 Dec 2005 13:54:50 -0500 (EST) From: Frank da Cruz To: Phil Budne Subject: Re: Announcing MM 0.95 Beta In-Reply-To: <200512081849.jB8Inw4h020017@ultimate.com> Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: > Neat! > > P.S. > I didn't know MS was still available, and worked. I thought MRC > had disowned it (and tells people to use Pine instead)! > Me included! He keeps saying it's just a toy, has no features, etc, but it's pretty usable, and now that the secret is out, maybe people will add some of those features. The first big gap I noticed was that there doesn't seem to be any way of getting a message out of the IMAP jail onto the local disk. - Frank From smj@cirr.com Thu Dec 8 14:06:57 2005 Flags: 000000000011 Return-Path: Received: from egsner.cirr.com (mail.cirr.com [192.67.63.1]) by dewberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8J6xNc025052 for ; Thu, 8 Dec 2005 14:07:02 -0500 (EST) Received: from egsner.cirr.com (smj@localhost [127.0.0.1]) by egsner.cirr.com (8.13.5/8.13.4/$Revision: 1.29 $) with ESMTP id jB8J6w42024621 for ; Thu, 8 Dec 2005 13:06:58 -0600 (CST) Received: (from smj@localhost) by egsner.cirr.com (8.13.5/8.13.3) id jB8J6vud026429 for fdc@columbia.edu; Thu, 8 Dec 2005 13:06:57 -0600 (CST) From: "Stephen M. Jones" Message-Id: <200512081906.jB8J6vud026429@egsner.cirr.com> Subject: Re: Announcing MM 0.95 Beta To: fdc@columbia.edu (Frank da Cruz) Date: Thu, 8 Dec 2005 13:06:57 -0600 (CST) In-Reply-To: X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-2.0.2 (egsner.cirr.com [127.0.0.1]); Thu, 08 Dec 2005 13:06:58 -0600 (CST) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.165 Status: Very cool... we've got quite a few users of MM on 'SDF' who will be happy to hear about this new version. I'll let the NetBSD pkgsrc folks know its active so the port can be updated. From fdc@columbia.edu Thu Dec 8 14:24:21 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8JOOVA002831 for ; Thu, 8 Dec 2005 14:24:24 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8JOLda005969; Thu, 8 Dec 2005 14:24:21 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8JOLWR005968; Thu, 8 Dec 2005 14:24:21 -0500 (EST) Date: Thu, 8 Dec 2005 14:24:21 -0500 (EST) From: Frank da Cruz To: William "Chops" Westfield Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Cc: Nelson Beebe Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: > The awk problems seem to stem from macos's rather unique handling of > case in filenames. It wasn't doing so good at figuring out cmds.h > and cmds.H weren't the same file :-) Things went better when I used > .hh instead of .H as the prefix for awk input files. > I verified this just now with MM (Melissa Metz, one of the original CMM authors, who actually has Mac OS X on her desk -- imagine her surprise). Still, I can't see how this could have worked for Nelson Beebe, unless there is some secret setting in Mac OS X to make the file system case senstive. Nelson, you there? - Frank P.S. Warning, there is also a set.H / set.h pair. And token.h/H. From billw@cisco.com Thu Dec 8 14:39:07 2005 Flags: 000000000011 Return-Path: Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by dewberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8JdA10008330 for ; Thu, 8 Dec 2005 14:39:13 -0500 (EST) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2005 11:39:10 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB8Jd8BH016300; Thu, 8 Dec 2005 11:39:08 -0800 (PST) Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA10926; Thu, 8 Dec 2005 11:39:07 -0800 (PST) Sender: Bill Westfield Date: Thu, 8 Dec 2005 11:39:07 PST From: William "Chops" Westfield To: Frank da Cruz Cc: Nelson Beebe Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Your message of Thu, 8 Dec 2005 14:24:21 -0500 (EST) Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.165 Status: > The awk problems seem to stem from macos's rather unique handling of > case in filenames. It wasn't doing so good at figuring out cmds.h > and cmds.H weren't the same file :-) Things went better when I used > .hh instead of .H as the prefix for awk input files. > I verified this just now with MM (Melissa Metz, one of the original CMM authors, who actually has Mac OS X on her desk -- imagine her surprise). Still, I can't see how this could have worked for Nelson Beebe, unless there is some secret setting in Mac OS X to make the file system case senstive. I expect that the true unix afficiandos turn on/off the flag that makes macos case handling more standard? P.S. Warning, there is also a set.H / set.h pair. And token.h/H. Yeah, I got them too. "things went better" means I successfully built an mm binary that reads my (solaris) email archives. Even the 136MB file from 2004, although that resulted in an alarming amount of noise issuing from the disk drives for rather a long time during the read... Current minor issue: ccmd doesn't seem to like filenames (or maybe just directory names) with embedded spaces. I don't think I blame it! BillW From fdc@columbia.edu Thu Dec 8 14:44:29 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8JiVQs008629 for ; Thu, 8 Dec 2005 14:44:31 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8JiTu0006857; Thu, 8 Dec 2005 14:44:29 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8JiT9h006856; Thu, 8 Dec 2005 14:44:29 -0500 (EST) Date: Thu, 8 Dec 2005 14:44:29 -0500 (EST) From: Frank da Cruz To: William "Chops" Westfield Cc: Nelson Beebe Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: > I expect that the true unix afficiandos turn on/off the flag that makes > macos case handling more standard? > Well I guess we can't make them do that so we'll need to change the names of the .H files and all references to them. It was a bad idea to have case-only distinctions anyway, in a program that was originally intended to be (and was) portable to many platforms (including, would you believe, DOS!) I guess the .H/.h thing snuck in during the decade and a half that my back was turned. > P.S. Warning, there is also a set.H / set.h pair. And token.h/H. > > Yeah, I got them too. "things went better" means I successfully built an mm > binary that reads my (solaris) email archives. Even the 136MB file from > 2004, although that resulted in an alarming amount of noise issuing from the > disk drives for rather a long time during the read... > That's promising. And you changed the Makefile to use libtool instead of ar (for Mac OS X only) to build ccmd.a? > Current minor issue: ccmd doesn't seem to like filenames (or maybe just > directory names) with embedded spaces. I don't think I blame it! > Like the doctor says "Don't do that". Anyway, when you're ready, send back your changes. Thanks. - Frank From fdc@columbia.edu Thu Dec 8 14:52:09 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8JqBtu020484 for ; Thu, 8 Dec 2005 14:52:11 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8Jq9NX007201; Thu, 8 Dec 2005 14:52:09 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8Jq9mO007200; Thu, 8 Dec 2005 14:52:09 -0500 (EST) Date: Thu, 8 Dec 2005 14:52:09 -0500 (EST) From: Frank da Cruz To: Mark Crispin Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: > Anyway, I've updated > ftp://ftp.cac.washington.edu/mail/ms.tar.Z > to make it build on Mac OS X, fix the copyrights, and remove the BUG > command. > That was fast. So this is with the new ccmd, right? I was having a side conversation with BillW about Mac OS X -- MM would not build on it because it uses some .H files, with awk scripts to convert them to .h files, but on Mac OS X, they are the same file. I don't think that's an issue with ccmd. - Frank From fdc@columbia.edu Thu Dec 8 15:00:53 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8K13VO015198 for ; Thu, 8 Dec 2005 15:01:03 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8K13Z7007598; Thu, 8 Dec 2005 15:01:03 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8K0rar007573; Thu, 8 Dec 2005 15:00:53 -0500 (EST) Date: Thu, 8 Dec 2005 15:00:53 -0500 (EST) From: Frank da Cruz To: Phil Budne Subject: Re: Announcing MM 0.95 Beta In-Reply-To: <200512081953.jB8Jra4G020721@ultimate.com> Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: > > The first big gap I noticed was that there doesn't seem to be any > > way of getting a message out of the IMAP jail onto the local disk. > > I never noticed! But I don't think I ever REALLY used as anything > other than an IMAP test tool! Doesn't the c-client library support > local mailboxes? A "copy" command should solve that problem.... > The COPY command copies from one IMAP mailbox to another. Maybe if I wasn't using IMAP then it would work as expected, but then I'd be using MM, not MS :-) > I seem to recall that at least one IMAP feature was added when I > complained I couldn't do some operation that I always did in "mm" > > I still use mm regularly (in a monthly script that sorts mailboxes > after merging them), but I'd think an IMAP aware tool would be the > direction of the future! > Except for people like me who want my mail files where I can see them, put them in EMACS, grep through them, etc. > Something I always meant to do in columbia "mm" was to see if I could > use mmap(), the way TOPS-20 MM used "PMAP", so that mailboxes didn't > need to be read and written, if only flags changed. I suppose > machines are fast enough now so that's less of an issue (tho I can't > imaging dealing with gigabyte mailboxes is fast!) > I don't think mmap is very portable... > Keep up the good work! > phil > Thanks, I'll try. > P.S. I disagree with Nelson's assertion that GNU autoconf is the only > "right" way to make software portable. It's certainly better than the > 1980's "ifdef platform" method, but it still makes a mess (GNU emacs' > terminal handling code was one place that always made my skin crawl). > I saw the light when I saw C news, which pushed all the mess out into > function libraries, and tried to keep the main code clean. > Well for MM (and Kermit) it's just too late. It's 80s code! Nobody is ever going to clean it up. But I agree that autoconf is not so wonderful. I say a few words about that somewhere... Oh yeah, here: http://www.columbia.edu/kermit/ckcplm.html#x3 - Frank From fdc@columbia.edu Thu Dec 8 15:01:54 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8K1t5O023247 for ; Thu, 8 Dec 2005 15:01:55 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8K1sP8007603; Thu, 8 Dec 2005 15:01:54 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8K1sEq007602; Thu, 8 Dec 2005 15:01:54 -0500 (EST) Date: Thu, 8 Dec 2005 15:01:54 -0500 (EST) From: Frank da Cruz To: Mark Crispin Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: > > I was having a side conversation with BillW about Mac OS X -- MM would not > > build on it because it uses some .H files, with awk scripts to convert them > > to .h files, but on Mac OS X, they are the same file. I don't think that's > > an issue with ccmd. > > It built for me on Mac OS X. I haven't tried installing it though. > I suspect there is some kind of file-system selection that turns case sensitivity on or off. Evidently some people have it one way, others the other. - Frank From billw@cisco.com Thu Dec 8 15:10:43 2005 Flags: 000000000001 Return-Path: Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by dewberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8KAsjJ022447 for ; Thu, 8 Dec 2005 15:10:57 -0500 (EST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2005 12:10:54 -0800 X-IronPort-AV: i="3.99,231,1131350400"; d="scan'208"; a="375799885:sNHT28748236" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jB8KAqQK008801; Thu, 8 Dec 2005 12:10:52 -0800 (PST) Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA16666; Thu, 8 Dec 2005 12:10:43 -0800 (PST) Sender: Bill Westfield Date: Thu, 8 Dec 2005 12:10:43 PST From: William "Chops" Westfield To: Frank da Cruz Cc: Nelson Beebe , billw@cisco.com Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Your message of Thu, 8 Dec 2005 14:44:29 -0500 (EST) Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.165 Status: It was a bad idea to have case-only distinctions anyway, in a program that was originally intended to be (and was) portable to many platforms That was my feeling as well... And you changed the Makefile to use libtool instead of ar (for Mac OS X only) to build ccmd.a? No. Not yet, anyway. This would have introduced a platform dependence in a place where there isn't one currently, and I at least want to understand why using 'ar' didn't work right before I go to that extreme. I just manually built the ccmd.a using libtool (it IS comforting to know that that works!) I suspect that the use of ranlib here is a bit old-fashioned. At something like 500k total (including symbols), ccmd seems well withing modern limits for the size of libraries included wholesale in applications :-( BillW From MRC@CAC.Washington.EDU Thu Dec 8 16:16:01 2005 Flags: 000000000001 Return-Path: Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by elderberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8LG14B028459 for ; Thu, 8 Dec 2005 16:16:04 -0500 (EST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB8LG00A001192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Dec 2005 13:16:00 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id jB8LG02N002408 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 8 Dec 2005 13:16:00 -0800 Date: Thu, 8 Dec 2005 13:16:01 -0800 (Pacific Standard Time) From: Mark Crispin To: Frank da Cruz Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing Sender: mrc@ndcms.cac.washington.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.166 Status: On Thu, 8 Dec 2005, Frank da Cruz wrote: > I suspect there is some kind of file-system selection that turns case > sensitivity on or off. Evidently some people have it one way, others the > other. That could be. I just run as standard a UNIX environment as I can under Mac OS X Tiger. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From fdc@columbia.edu Thu Dec 8 16:34:39 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8LYhGO013253 for ; Thu, 8 Dec 2005 16:34:43 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8LYeme011918; Thu, 8 Dec 2005 16:34:41 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8LYdN6011913; Thu, 8 Dec 2005 16:34:39 -0500 (EST) Date: Thu, 8 Dec 2005 16:34:39 -0500 (EST) From: Frank da Cruz To: Mark Crispin Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: > Anyway, I've updated > ftp://ftp.cac.washington.edu/mail/ms.tar.Z > to make it build on Mac OS X, fix the copyrights, and remove the BUG > command. > Hmmm, not quite as smooth as before! When I build this on Solaris (with the new ccmd) I get: [~/mm/ms/ms] cat make.sh make "CCMD=../../work/ccmd" "LOCALFLAGS=-DCOLUMBIA" [~/mm/ms/ms] [~/mm/ms/ms] ./make.sh `cat ../imap/c-client/CCTYPE` -I../imap/c-client -I../../work/ccmd `cat ../imap/c-client/CFLAGS` -DCOLUMBIA -c -o ms.o ms.c `cat ../imap/c-client/CCTYPE` -I../imap/c-client -I../../work/ccmd `cat ../imap/c-client/CFLAGS` -DCOLUMBIA -o ms ms.o ../../work/ccmd/ccmd.a ../imap/c-client/c-client.a -ltermlib `cat ../imap/c-client/LDFLAGS` ild: (undefined symbol) sigblock -- referenced in the text segment of ../../work/ccmd/ccmd.a(ccmdmd.o) ild: (undefined symbol) sigsetmask -- referenced in the text segment of ../../work/ccmd/ccmd.a(ccmdmd.o) make: *** [ms] Error 5 If I build yesterday's MS with the new ccmd I get: [~/mm/ms/ms] cat make.sh make "CCMD=../../work/ccmd" [~/mm/ms/ms.1] ./make.sh `cat ../imap-2000/c-client/CCTYPE` -I../imap-2000/c-client -I../../work/ccmd `cat ../imap-2000/c-client/CFLAGS` -c -o ms.o ms.c "ms.c", line 99: identifier redeclared: main current : function(int, pointer to pointer to char) returning void previous: function(int, pointer to pointer to char) returning int : "../../work/ccmd/ccmd.h", line 385 "ms.c", line 2696: cannot recover from previous errors cc: acomp failed for ms.c make: *** [ms.o] Error 2 [~/mm/ms/ms.1] If I build today's MS with the old ccmd I get: success, builds and runs OK. If I build yesterday's MS with the old ccmd I get: success, builds and runs OK. Haven't tried to figure this out yet since today's MM builds OK with with today's ccmd. The only changes I made were to ms.c: static char *hostlist[] = { /* SMTP server host list */ #ifdef COLUMBIA "localhost/submit", "imap/submit", #else "mailhost", "localhost", #endif /* COLUMBIA */ 0 }; and this to the makefile: CFLAGS = -I$C -I$(CCMD) `cat $C/CFLAGS` $(LOCALFLAGS) to allow local CFLAGS to be included on the make command line. - Frank From beebe@math.utah.edu Thu Dec 8 16:41:37 2005 Flags: 000000000011 Return-Path: Received: from sunshine2.math.utah.edu (sunshine2.math.utah.edu [155.101.96.3]) by feta.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8Lfh2d022059 for ; Thu, 8 Dec 2005 16:41:47 -0500 (EST) Received: from psi.math.utah.edu (IDENT:jq+hOSW1OKcZz24yoHUz67UzQtRKCuB9@psi.math.utah.edu [155.101.96.19]) by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id jB8LfbQN025954; Thu, 8 Dec 2005 14:41:37 -0700 (MST) Received: from psi.math.utah.edu (IDENT:NHpoDplcXBMHlgslTTfXiQ2rWCI0XmBV@localhost [127.0.0.1]) by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id jB8Lfbdi029281; Thu, 8 Dec 2005 14:41:37 -0700 (MST) Received: (from beebe@localhost) by psi.math.utah.edu (8.13.4/8.13.4/Submit) id jB8LfbTS029280; Thu, 8 Dec 2005 14:41:37 -0700 (MST) Date: Thu, 8 Dec 2005 14:41:37 -0700 (MST) From: "Nelson H. F. Beebe" To: Frank da Cruz Cc: beebe@math.utah.edu, sysstaff@math.utah.edu X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Your message of Thu, 8 Dec 2005 11:47:03 -0500 (EST) Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Thu, 08 Dec 2005 14:41:38 -0700 (MST) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.164 Status: >> ftp://kermit.columbia.edu/kermit/mm/test/mm-ccmd-0.95-20051208.tar.gz I was busy yesterday on another project, and didn't read email. I'm catching up now, and have just grabbed the test code at the above address, and am starting builds. I'm REALLY impressed at how quickly you were able to merge our divergent versions: it is terrific progress! I'll be giving the new version a solid workout in the next few days (assuming it builds), first on Solaris, and then I'll try AMD64 GNU/Linux. We really would like to have a rock-solid version for GNU/Linux systems to point people to. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From fdc@columbia.edu Thu Dec 8 16:49:30 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8LqQ0a016706 for ; Thu, 8 Dec 2005 16:52:26 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8Lntww012562; Thu, 8 Dec 2005 16:51:03 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8LnUc8012559; Thu, 8 Dec 2005 16:49:30 -0500 (EST) Date: Thu, 8 Dec 2005 16:49:30 -0500 (EST) From: Frank da Cruz To: "Nelson H. F. Beebe" Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Cc: sysstaff@math.utah.edu Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: > >> ftp://kermit.columbia.edu/kermit/mm/test/mm-ccmd-0.95-20051208.tar.gz > > I was busy yesterday on another project, and didn't read email. I'm > catching up now, and have just grabbed the test code at the above > address, and am starting builds. > > I'm REALLY impressed at how quickly you were able to merge our > divergent versions: it is terrific progress! > All in one day, boy did my hands hurt. > I'll be giving the new version a solid workout in the next few days > (assuming it builds), first on Solaris, and then I'll try AMD64 GNU/Linux. > We really would like to have a rock-solid version for GNU/Linux systems to > point people to. > Glad to hear from you! As you have seen, apparently there are issues with Mac OS X. And then just now I tried building Mark Crispin's MS program (which previously I had built easily with the old ccmd) with the new ccmd, and it didn't do so well. When I build MS on Solaris 9 with the new ccmd I get: [~/mm/ms/ms] cat make.sh make "CCMD=../../work/ccmd" "LOCALFLAGS=-DCOLUMBIA" [~/mm/ms/ms] [~/mm/ms/ms] ./make.sh `cat ../imap/c-client/CCTYPE` -I../imap/c-client -I../../work/ccmd `cat ../imap/c-client/CFLAGS` -DCOLUMBIA -c -o ms.o ms.c `cat ../imap/c-client/CCTYPE` -I../imap/c-client -I../../work/ccmd `cat ../imap/c-client/CFLAGS` -DCOLUMBIA -o ms ms.o ../../work/ccmd/ccmd.a ../imap/c-client/c-client.a -ltermlib `cat ../imap/c-client/LDFLAGS` ild: (undefined symbol) sigblock -- referenced in the text segment of ../../work/ccmd/ccmd.a(ccmdmd.o) ild: (undefined symbol) sigsetmask -- referenced in the text segment of ../../work/ccmd/ccmd.a(ccmdmd.o) make: *** [ms] Error 5 If I build yesterday's MS with the new ccmd I get: [~/mm/ms/ms] cat make.sh make "CCMD=../../work/ccmd" [~/mm/ms/ms.1] ./make.sh `cat ../imap-2000/c-client/CCTYPE` -I../imap-2000/c-client -I../../work/ccmd `cat ../imap-2000/c-client/CFLAGS` -c -o ms.o ms.c "ms.c", line 99: identifier redeclared: main current : function(int, pointer to pointer to char) returning void previous: function(int, pointer to pointer to char) returning int : "../../work/ccmd/ccmd.h", line 385 "ms.c", line 2696: cannot recover from previous errors But MS still builds OK with the old ccmd (both his previous version and his new version from today). The new MM builds OK with the new ccmd, so I really do not understand what all the hollering about sigsetmask and sigblock is about... Anyway I will hold off making any changes until I hear from you. You might want to coordinate with BillW and maybe MRC. - Frank From beebe@math.utah.edu Thu Dec 8 16:58:14 2005 Flags: 000000000011 Return-Path: Received: from sunshine2.math.utah.edu (sunshine2.math.utah.edu [155.101.96.3]) by dewberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8LwI3W012423 for ; Thu, 8 Dec 2005 16:58:21 -0500 (EST) Received: from psi.math.utah.edu (IDENT:IGWkM/EUSuwK7alrN5MVpJs/LNj9UcY9@psi.math.utah.edu [155.101.96.19]) by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id jB8LwFuh026746; Thu, 8 Dec 2005 14:58:15 -0700 (MST) Received: from psi.math.utah.edu (IDENT:3QLWeefRYN6kDbQkBSBCiYhC4sTxDtfD@localhost [127.0.0.1]) by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id jB8LwE7I029506; Thu, 8 Dec 2005 14:58:14 -0700 (MST) Received: (from beebe@localhost) by psi.math.utah.edu (8.13.4/8.13.4/Submit) id jB8LwECu029505; Thu, 8 Dec 2005 14:58:14 -0700 (MST) Date: Thu, 8 Dec 2005 14:58:14 -0700 (MST) From: "Nelson H. F. Beebe" To: Frank da Cruz , William "Chops" Westfield Cc: beebe@math.utah.edu X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Your message of Thu, 8 Dec 2005 14:24:21 -0500 (EST) Message-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Thu, 08 Dec 2005 14:58:15 -0700 (MST) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.165 Status: >> Still, I can't see how this could have worked for Nelson Beebe, unless >> there is some secret setting in Mac OS X to make the file system case >> sensitive. This issue confuses many users. Apple is officially moving towards a UFS-style case-sensitive filesystem, but even with the latest Mac OS X 10.4, the older HFS+ case-insensitive filesystem still exists, and I suspect that it is the default. There are third-party Mac software packages that refuse to install on UFS filesystems. Other packages have errors (files mentioned in installation scripts with inconsistent letter casing) that we have patched (most recently, Adobe Acrobat Professional 7.0). I'm sure that we'll hit more of this problem on Mac OS X. Let me put in a plug for a great little tool that Frank da Cruz wrote many years ago: xxu (TOPS-20 to Unix). It renames UPPERCASED files to lowercase, except for special cases like README and Makefile. Our Solaris executable of xxu was last compiled on 7-May-1996, and I still use it several times a year. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From fdc@columbia.edu Thu Dec 8 17:07:37 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8M7dFU000563 for ; Thu, 8 Dec 2005 17:07:39 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB8M7bkb013318; Thu, 8 Dec 2005 17:07:37 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB8M7bup013317; Thu, 8 Dec 2005 17:07:37 -0500 (EST) Date: Thu, 8 Dec 2005 17:07:37 -0500 (EST) From: Frank da Cruz To: "Nelson H. F. Beebe" cc: William "Chops" Westfield Subject: Re: Announcing MM 0.95 Beta In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: > Let me put in a plug for a great little tool that Frank da Cruz wrote > many years ago: xxu (TOPS-20 to Unix). It renames UPPERCASED files to > lowercase, except for special cases like README and Makefile. Our > Solaris executable of xxu was last compiled on 7-May-1996, and I still > use it several times a year. > It won't help in this case though. We need to change *.H (and all references to them) to *.hh or somesuch (as Bill has already done), to avoid the problem no matter what version of the OS or file system people have. Bill also had an issue with ar on Mac OS X, as you saw. - Frank P.S. Btw, I might have to put mail file locking back in MM as a feature selectable at compile time. I'm not sure the Columbia sysadmins and/or help desk will go for the lockless way. Although I'm thinking of maybe using file-based locks rather than OS-based ones, because then at least users can fix stale locks themselves rather than having to pray for it. We also need to preserve the various site-specific code sections, like PANIX, COLUMBIA, etc (which I took some care to do). From rossman@columbia.edu Fri Dec 9 15:47:05 2005 Flags: 000000000011 Return-Path: Received: from breadfruit.cc.columbia.edu (breadfruit.cc.columbia.edu [128.59.28.101]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB9Kl6FM020770; Fri, 9 Dec 2005 15:47:06 -0500 (EST) Received: from breadfruit.cc.columbia.edu (localhost [127.0.0.1]) by breadfruit.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB9Kl6oB025339; Fri, 9 Dec 2005 15:47:06 -0500 (EST) Received: (from www@localhost) by breadfruit.cc.columbia.edu (8.13.0/8.13.0/Submit) id jB9Kl5gF025338; Fri, 9 Dec 2005 15:47:05 -0500 (EST) Received: from us-proxy.att.com (us-proxy.att.com [192.128.133.68]) by cubmail.cc.columbia.edu (IMP) with HTTP for ; Fri, 09 Dec 2005 15:47:05 -0500 Message-ID: <1134161225.4399ed49e47cd@cubmail.cc.columbia.edu> Date: Fri, 09 Dec 2005 15:47:05 -0500 From: rossman@columbia.edu To: Frank da Cruz Subject: Re: Announcing MM 0.95 Beta References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-Originating-IP: 192.128.133.68 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: Hi Frank, Your web page note covering the changes in MM invites folks to let you know if anyone wants to test MacOSX or Linux versions of mm. Being as how now MacOSX and Linux are my two favorite operating systems, in that order, I'd like to test both. I pulled down the source code that was made available at this point in time, and tried compiling, but ran into errors on both platforms, and pretty much right out of the starting gate. I think ccmd compiled OK in one or both instances, but mm had problems with both platforms. Maybe I didn't set things up right or maybe I didn't have the right sources, or was missing some important information. In any case, I'd love to have a working mm/ccmd for both of the aforementioned platforms as those are the two I am using the most these days. Where do I go for the latest sources and what else might I need to know? Thanks! Ken P.S. -- Maybe mm will one day even make it to V1.0 status??? :-) From fdc@columbia.edu Fri Dec 9 15:59:23 2005 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB9KxiYJ013115; Fri, 9 Dec 2005 15:59:44 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jB9KxiNx002839; Fri, 9 Dec 2005 15:59:44 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id jB9KxNbW002833; Fri, 9 Dec 2005 15:59:23 -0500 (EST) Date: Fri, 9 Dec 2005 15:59:23 -0500 (EST) From: Frank da Cruz To: rossman@columbia.edu Subject: Re: Announcing MM 0.95 Beta In-Reply-To: <1134161225.4399ed49e47cd@cubmail.cc.columbia.edu> Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Status: > Your web page note covering the changes in MM invites folks to > let you know if anyone wants to test MacOSX or Linux versions > of mm. Being as how now MacOSX and Linux are my two favorite > operating systems, in that order, I'd like to test both. > > I pulled down the source code that was made available at this > point in time, and tried compiling, but ran into errors on > both platforms, and pretty much right out of the starting gate. > Yes, I found out about the Mac OS X ones. It turns out that the scheme of blah.H -> awk -> blah.h doesn't work there because the file system is case insensitive. This will be fixed in the next Beta (by renaming all *.H to *.hh or somesuch, and fixing up all references to them). > I think ccmd compiled OK in one or both instances, but mm had > problems with both platforms. Maybe I didn't set things up > right or maybe I didn't have the right sources, or was missing > some important information. > I still need to write up build instructions, but it built OK for me on Linux (RH AS4.2). You should have a directory with two parallel subdirectories: ccmd and mm (the latter is actually a whole tree). Making ccmd is straightforward, just cd to ccmd and "make gnu-linux" (that's what Nelson Beebe calls, not just Linux). Then cd ../mm and do another "make gnu-linux". Depending on when you picked up the tarball, there might have been some extraneous binaries left over in the mm directory. "make clean" doesn't get them; you'll have to: rm -f mm argsort mkdefines mkversion mm-trans mmversion sys-prof movemail Probably the mm makefile should including this under "make clean". At the moment I'm waiting for Nelson to get back to me with whatever changes he makes before I put up the next beta. I have no idea when that will be. Soon I hope. - Frank From brennan@columbia.edu Fri Jan 6 14:15:00 2006 Flags: 000000000001 Return-Path: Received: from sodor.cc.columbia.edu (sodor.cc.columbia.edu [128.59.39.201]) (user=brennan mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k06JF0H4005716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 6 Jan 2006 14:15:00 -0500 (EST) Date: Fri, 06 Jan 2006 14:15:00 -0500 From: Joseph Brennan To: Frank da Cruz Subject: Re: Remail Message-ID: <90CA74EE2C457EF9375DE352@sodor.cc.columbia.edu> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: --On Friday, January 6, 2006 13:13 -0500 Frank da Cruz wrote: > Hi Joe. Did something change recently? It used to be that if I received > a message that was for somebody else (say fdc3, which happens all the > time), I could remail it to them and it would look to them as if the > message came straight from the original sender and they could reply to it > without surprises. > > Now when I remail a message, something changes the From: line to me, so > when the remailed-to person replies to the message, the reply comes to me > instead to who they wanted it to go to. Also in their message list, they > see me as the author instead of the real author. > > Maybe it's something they did to MM at Utah, but before I go digging in > the code, I thought I'd ask first if it was happening in the mail servers. > > Thanks. > > - Frank > Must be MM. Nothing on the server rewrites a From: header. Joe From fdc@columbia.edu Mon Jan 9 18:30:05 2006 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k09NU5Tr024674; Mon, 9 Jan 2006 18:30:05 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k09NU53b003697; Mon, 9 Jan 2006 18:30:05 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id k09NU5If003696; Mon, 9 Jan 2006 18:30:05 -0500 (EST) Date: Mon, 9 Jan 2006 18:30:05 EST From: Frank da Cruz To: mailtech-wg@columbia.edu Subject: New MM/POP Beta Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: In the regular place. I installed it earlier today and haven't heard any screams. http://www.columbia.edu/~fdc/mm/ Mail-file locking is back, I fixed the REMAIL command to work like it used to (and like it's supposed to), and I juggled some filenames so it should be less tricky to build it on Mac OS X. For file locking, I just put back the kernel locks like MM always used. But when the mail spool goes away -- or for that matter, even now -- is there any other mail client that uses the same locking convention? If not, then I don't have to worry about MM interoperating with anything other than itself -- at least not after the final cutover to Cyrus -- in which case I can use lockfiles which contain info about the host, date/time, process, etc, that created the lock, and a command to let users clear stale locks. - Frank From fdc@columbia.edu Tue Jan 10 13:14:42 2006 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0AIEm0Q026644 for ; Tue, 10 Jan 2006 13:14:48 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0AIEgPo025069; Tue, 10 Jan 2006 13:14:42 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id k0AIEgfQ025068; Tue, 10 Jan 2006 13:14:42 -0500 (EST) Date: Tue, 10 Jan 2006 13:14:42 EST From: Frank da Cruz To: Ed Ravin cc: support@panix.com, klh@panix.com Subject: New MM on Panix Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: Hi Ed, I've been working on a new MM release, details here: http://www.columbia.edu/~fdc/mm/ I put a copy on Panix in ~fdc/mm and built it using: make netbsd DEBUG="-DMM_PANIX" I think I have all the MM_PANIX code still in place (in mm/newmail.c) and I tried to replicate the Panix setup in mm/config.h. As far as I can tell, everything is OK, but it doesn't pick up new mail, even though it seems to be looking in the right place, in my case: /net/u/1/f/fdc/.maildir/ I have, according to MM's SHOW command: set default-mail-type mbox set editor emacs set help-file /pkg/mm-0.91p1/libdata/mm-0.91/mm.help set help-dir /pkg/mm-0.91p1/libdata/mm-0.91/help set incoming-mail ~/.maildir/ set mail-directory . set mail-file ~/mbox set mmail-path /pkg/mm-0.91p1/libdata/mm-0.91/mmail.el set movemail-path /usr/local/bin/mdmovemail which seem to agree with what /usr/local/bin/mm shows me. But it still doesn't pick up new mail. I'd like the forthcoming release to work on Panix, so I'd appreciate it if you would take a look and see what I might have missed. You'll notice that the changes are massive; the C has been modernized to let it be built on most every Unix platform, which is a big step, but makes it hard to compare with the previous version. - Frank P.S. I'm cc'ing this to support in case you're not the right person, and klh who probably would be interested. From klh@panix.com Tue Jan 10 22:37:22 2006 Flags: 000000000001 Return-Path: Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by elderberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0C3bMwJ023404 for ; Wed, 11 Jan 2006 22:37:25 -0500 (EST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail2.panix.com (Postfix) with ESMTP id 6F3339D8A0; Wed, 11 Jan 2006 22:37:22 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k0C3bMQ22220; Wed, 11 Jan 2006 22:37:22 -0500 (EST) Date: Wed, 11 Jan 2006 22:37:22 EST From: Ken Harrenstien To: Frank da Cruz Cc: Ed Ravin , support@panix.com, klh@panix.com Subject: Re: New MM on Panix In-Reply-To: Your message of Tue, 10 Jan 2006 13:14:42 EST Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.166 Status: > Hi Ed, I've been working on a new MM release, details here: > > http://www.columbia.edu/~fdc/mm/ > > I put a copy on Panix in ~fdc/mm and built it using: > > make netbsd DEBUG="-DMM_PANIX" > > I think I have all the MM_PANIX code still in place (in mm/newmail.c) and I > tried to replicate the Panix setup in mm/config.h. As far as I can tell, > everything is OK, but it doesn't pick up new mail, even though it seems to > be looking in the right place, in my case: > > /net/u/1/f/fdc/.maildir/ > > I have, according to MM's SHOW command: > > set default-mail-type mbox > set editor emacs > set help-file /pkg/mm-0.91p1/libdata/mm-0.91/mm.help > set help-dir /pkg/mm-0.91p1/libdata/mm-0.91/help > set incoming-mail ~/.maildir/ > set mail-directory . > set mail-file ~/mbox > set mmail-path /pkg/mm-0.91p1/libdata/mm-0.91/mmail.el > set movemail-path /usr/local/bin/mdmovemail > > which seem to agree with what /usr/local/bin/mm shows me. But it still > doesn't pick up new mail. > > I'd like the forthcoming release to work on Panix, so I'd appreciate it > if you would take a look and see what I might have missed. > > You'll notice that the changes are massive; the C has been modernized to > let it be built on most every Unix platform, which is a big step, but makes > it hard to compare with the previous version. > > - Frank > > P.S. I'm cc'ing this to support in case you're not the right person, and > klh who probably would be interested. Indeed I am. There was a problem some months ago when panix changed things out from under my running MM, resulting in the spawning of hundreds of forks trying to run a movemail-path that was no longer there. So I'm now very suspicious of anything involving movemail. Suggest trying a "trace" with the follow-fork option and seeing what it shows for an attempt to pick up new mail. Oh, netbsd doesn't have that? No truss either? Uh... ktrace? --Ken From elr@panix.com Wed Jan 11 23:45:56 2006 Flags: 000000000001 Return-Path: Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by jujube.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0C4juwg008438 for ; Wed, 11 Jan 2006 23:45:59 -0500 (EST) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 59E7B9D9CD; Wed, 11 Jan 2006 23:45:56 -0500 (EST) Received: (from eravin@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k0C4juV12756; Wed, 11 Jan 2006 23:45:56 -0500 (EST) Date: Wed, 11 Jan 2006 23:45:56 -0500 From: Ed Ravin To: Ken Harrenstien Cc: Frank da Cruz , support@panix.com, "Ed Ravin [staff]" Subject: Re: New MM on Panix Message-ID: <20060112044556.GG18581@panix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Y-Z: 1, 2, 3? User-Agent: Mutt/1.5.10i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.170 Status: Frank: Panix's tech staff are just recovering from our office move. We'll be catching up on things in the upcoming weeks, and one of our programmers will take a look at the new MM version. Ken: the system trace syntax on NetBSD would be "ktrace -i " and then "kdump | less" after the command has exited. A recent addition is "ktruss" (or "ktruss -i" to follow forks) which works more or less like Solaris's "truss". Unlike "ktrace", it doesn't leave behind a giant file named "ktrace.out" that you have to clean up afterwards. -- Ed On Wed, Jan 11, 2006 at 10:37:22PM -0500, Ken Harrenstien wrote: > > Hi Ed, I've been working on a new MM release, details here: > > > > http://www.columbia.edu/~fdc/mm/ > > > > I put a copy on Panix in ~fdc/mm and built it using: > > > > make netbsd DEBUG="-DMM_PANIX" > > > > I think I have all the MM_PANIX code still in place (in mm/newmail.c) and I > > tried to replicate the Panix setup in mm/config.h. As far as I can tell, > > everything is OK, but it doesn't pick up new mail, even though it seems to > > be looking in the right place, in my case: > > > > /net/u/1/f/fdc/.maildir/ > > > > I have, according to MM's SHOW command: > > > > set default-mail-type mbox > > set editor emacs > > set help-file /pkg/mm-0.91p1/libdata/mm-0.91/mm.help > > set help-dir /pkg/mm-0.91p1/libdata/mm-0.91/help > > set incoming-mail ~/.maildir/ > > set mail-directory . > > set mail-file ~/mbox > > set mmail-path /pkg/mm-0.91p1/libdata/mm-0.91/mmail.el > > set movemail-path /usr/local/bin/mdmovemail > > > > which seem to agree with what /usr/local/bin/mm shows me. But it still > > doesn't pick up new mail. > > > > I'd like the forthcoming release to work on Panix, so I'd appreciate it > > if you would take a look and see what I might have missed. > > > > You'll notice that the changes are massive; the C has been modernized to > > let it be built on most every Unix platform, which is a big step, but makes > > it hard to compare with the previous version. > > > > - Frank > > > > P.S. I'm cc'ing this to support in case you're not the right person, and > > klh who probably would be interested. > > Indeed I am. > > There was a problem some months ago when panix changed things out from > under my running MM, resulting in the spawning of hundreds of forks > trying to run a movemail-path that was no longer there. So I'm now > very suspicious of anything involving movemail. > > Suggest trying a "trace" with the follow-fork option and seeing > what it shows for an attempt to pick up new mail. Oh, netbsd doesn't > have that? No truss either? Uh... ktrace? > > --Ken > -- From klh@panix.com Tue Jan 10 23:52:10 2006 Flags: 000000000001 Return-Path: Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by jujube.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0C4qAFX009428 for ; Wed, 11 Jan 2006 23:52:13 -0500 (EST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail2.panix.com (Postfix) with ESMTP id AB2F49DA7F; Wed, 11 Jan 2006 23:52:10 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k0C4qBj20019; Wed, 11 Jan 2006 23:52:11 -0500 (EST) Date: Wed, 11 Jan 2006 23:52:10 EST From: Ken Harrenstien To: Ed Ravin Cc: Ken Harrenstien , Frank da Cruz , support@panix.com, "Ed Ravin [staff]" Subject: Re: New MM on Panix In-Reply-To: Your message of Wed, 11 Jan 2006 23:45:56 -0500 Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.170 Status: > Frank: Panix's tech staff are just recovering from our office move. > We'll be catching up on things in the upcoming weeks, and one of > our programmers will take a look at the new MM version. > > Ken: the system trace syntax on NetBSD would be "ktrace -i " > and then "kdump | less" after the command has exited. A recent addition > is "ktruss" (or "ktruss -i" to follow forks) which works more or less > like Solaris's "truss". Unlike "ktrace", it doesn't leave behind a giant > file named "ktrace.out" that you have to clean up afterwards. > > -- Ed Cool, thanks! Normally I'd already have tried to debug this myself, but am still recovering from having kids. Will have time in, oh, 15 years or so... --Ken > > On Wed, Jan 11, 2006 at 10:37:22PM -0500, Ken Harrenstien wrote: > > > Hi Ed, I've been working on a new MM release, details here: > > > > > > http://www.columbia.edu/~fdc/mm/ > > > > > > I put a copy on Panix in ~fdc/mm and built it using: > > > > > > make netbsd DEBUG="-DMM_PANIX" > > > > > > I think I have all the MM_PANIX code still in place (in mm/newmail.c) and I > > > tried to replicate the Panix setup in mm/config.h. As far as I can tell, > > > everything is OK, but it doesn't pick up new mail, even though it seems to > > > be looking in the right place, in my case: > > > > > > /net/u/1/f/fdc/.maildir/ > > > > > > I have, according to MM's SHOW command: > > > > > > set default-mail-type mbox > > > set editor emacs > > > set help-file /pkg/mm-0.91p1/libdata/mm-0.91/mm.help > > > set help-dir /pkg/mm-0.91p1/libdata/mm-0.91/help > > > set incoming-mail ~/.maildir/ > > > set mail-directory . > > > set mail-file ~/mbox > > > set mmail-path /pkg/mm-0.91p1/libdata/mm-0.91/mmail.el > > > set movemail-path /usr/local/bin/mdmovemail > > > > > > which seem to agree with what /usr/local/bin/mm shows me. But it still > > > doesn't pick up new mail. > > > > > > I'd like the forthcoming release to work on Panix, so I'd appreciate it > > > if you would take a look and see what I might have missed. > > > > > > You'll notice that the changes are massive; the C has been modernized to > > > let it be built on most every Unix platform, which is a big step, but makes > > > it hard to compare with the previous version. > > > > > > - Frank > > > > > > P.S. I'm cc'ing this to support in case you're not the right person, and > > > klh who probably would be interested. > > > > Indeed I am. > > > > There was a problem some months ago when panix changed things out from > > under my running MM, resulting in the spawning of hundreds of forks > > trying to run a movemail-path that was no longer there. So I'm now > > very suspicious of anything involving movemail. > > > > Suggest trying a "trace" with the follow-fork option and seeing > > what it shows for an attempt to pick up new mail. Oh, netbsd doesn't > > have that? No truss either? Uh... ktrace? > > > > --Ken > > > > -- > From jld@panix.com Thu Jan 12 17:35:28 2006 Flags: 000000000005 Return-Path: Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by elderberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k0CMZSU6008588 for ; Thu, 12 Jan 2006 17:35:31 -0500 (EST) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 4B3FF13A87A; Thu, 12 Jan 2006 17:35:28 -0500 (EST) Received: (from jld@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id k0CMZSl06621; Thu, 12 Jan 2006 17:35:28 -0500 (EST) Date: Thu, 12 Jan 2006 17:35:28 -0500 From: "Jed Davis [staff]" To: fdc@columbia.edu Cc: Ken Harrenstien Subject: MM Maildir patch Message-ID: <20060112223528.GC24694@panix.com> References: <20060112215121.GC7190.req@panix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20060112215121.GC7190.req@panix.com> X-User-Agent-Host: NetBSD panix5.panix.com 2.0.3 i386 User-Agent: Mutt/1.5.10i X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.166 Status: --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 12, 2006 at 04:51:21PM -0500, Victoria O'Staff wrote: > ----- Forwarded message from Frank da Cruz ----- > From: Frank da Cruz > To: Ed Ravin > cc: support@panix.com, klh@panix.com > Subject: New MM on Panix > > I think I have all the MM_PANIX code still in place (in mm/newmail.c) and I > tried to replicate the Panix setup in mm/config.h. As far as I can tell, > everything is OK, but it doesn't pick up new mail, even though it seems to > be looking in the right place, in my case: > > /net/u/1/f/fdc/.maildir/ The problem is that, if it's just checking the mtime on that directory, that won't work: new mail is created in the "tmp" subdirectory and moved >From there to the "new" subdirectory, which will touch those dirs but not the top-level maildir. I have a patch for 0.91's newmail.c which... isn't the cleanest approach, I'll freely admit, but does work; I'm attaching it to this message. (I've been meaning to send it on for a while now, but there's been a lot of stuff on my various lists; sorry about that.) I also had to fix some uses of old-style varargs elsewhere, as NetBSD 2's cc doesn't support them, but it sounds like that's also been fixed upstream. -- Jed Davis [staff] jld@panix.com --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mm-maildir-newmail.patch" --- newmail.c.orig 2005-09-22 19:47:10.000000000 -0400 +++ newmail.c 2005-09-22 21:39:50.000000000 -0400 @@ -147,6 +147,28 @@ for(im = incoming_mail; im && *im; im++) { /* loop over inboxes */ if (stat(*im,&sbuf) < 0) continue; +#ifdef MM_PANIX + /* Minimal support for the Maildir format. */ + if (S_ISDIR(sbuf.st_mode)) { + static const char* mdsubdirs[] = { "/cur", "/new", "/tmp" }; + size_t iml = strlen(*im); + char *mdp = malloc(iml + 4 /*subdir*/ + 1 /*null*/); + struct stat mdbuf; + int sdi; + + strcpy(mdp, *im); + for (sdi=0; sdi<(sizeof(mdsubdirs)/sizeof(mdsubdirs[0])); ++sdi) { + strcpy(mdp + iml, mdsubdirs[sdi]); + if (stat(mdp, &mdbuf) < 0) goto out; + if (!S_ISDIR(mdbuf.st_mode)) goto out; + if (sbuf.st_mtime < mdbuf.st_mtime) + sbuf.st_mtime = mdbuf.st_mtime; + } + type = 0xDEADBEEF; + goto noprobe; + out: free(mdp); + } +#endif switch (mail_probe (*im, &type)) { /* can we read this? */ case PR_NAME: if (!quiet) @@ -166,6 +188,9 @@ continue; } +#ifdef MM_PANIX + noprobe: +#endif if (!getting_mail) { if (sbuf.st_mtime > oldbuf.st_mtime || !quiet) { printf("You have new mail in %s.\n", *im); --SUOF0GtieIMvvwua-- From mrc@CAC.Washington.EDU Fri Jan 13 13:32:10 2006 Flags: 000000000001 Return-Path: Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by jujube.cc.columbia.edu (8.13.0/8.13.0) with SMTP id k0DIonSf001307; Fri, 13 Jan 2006 13:50:52 -0500 (EST) Received: from mxout3.cac.washington.edu ([140.142.32.166]) by lingling.panda.com with TCP/SMTP; Fri, 13 Jan 2006 10:32:27 -0800 (PST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0DIWG0O001178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jan 2006 10:32:17 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k0DIWBtC003605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Jan 2006 10:32:15 -0800 Date: Fri, 13 Jan 2006 10:32:10 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Jon Solomon cc: tops-20@lingling.panda.com Subject: Re: MM In-Reply-To: <14089729014.10.JSOL@toad.xkl.com> Message-ID: References: <14089729014.10.JSOL@toad.xkl.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.170 Status: On Thu, 12 Jan 2006, Jon Solomon wrote: > I noticed this while debugging a problem receiving mail here. > I have an MM.CMD which says "reply-to jsol@mit.edu". When I do > @mm send, it fails to check mm.cmd, so the reply-to address never > gets put in the mail. I can get around it by doing @mmsend. This has always been the case. MM.CMD is a set of commands that are run when you do a normal MM startup, not when you send mail from the command line. You absolutely do not want mail file filter actions in a MM.CMD to take place when you are sending from the command line! The real problem in MM is that the FROM and REPLY-TO commands should never have been commands; they should have been SET options and thus subject to MM.INIT. The reason why they are commands is that they do various stuff to their arguments instead of just setting a string. Fortunately, there is a workaround. If you want a default Reply-To for all cases, you can use HEADER-OPTIONS to accomplish that. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From fdc@columbia.edu Wed Feb 8 12:31:11 2006 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k18HVBE1023776; Wed, 8 Feb 2006 12:31:11 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k18HVBRk011859; Wed, 8 Feb 2006 12:31:11 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id k18HVBLY011858; Wed, 8 Feb 2006 12:31:11 -0500 (EST) Date: Wed, 8 Feb 2006 12:31:11 EST From: Frank da Cruz To: Melissa Metz Subject: Re: Fwd: REMINDER: Columbia Email Unavailable Thu, 02/09 12am-4am In-Reply-To: <872B6C9C-1989-4D6C-98C4-4EFA4D50E913@columbia.edu> Cc: emailtech-wg@columbia.edu Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Status: > FYI, I was asked to send reminder messages, in case users forget > their Cyrus move in the week before they get moved. Don't be > surprised if someone mentions it. I sent the first set yesterday > (for Thursday), and am sending more now for Friday. > Does somebody want to mention MM on the Cyrus configuration page? http://www.columbia.edu/acis/email/cyrus/config/ I have had zero feedback after announcing the new MM a few months ago: http://www.columbia.edu/~fdc/mm/ I've been using exclusively with Pop for the past 8 weeks or so, it's OK. - Frank From alan@columbia.edu Wed Feb 8 13:26:46 2006 Flags: 000000000001 Return-Path: Received: from [129.24.224.158] ([129.24.224.158]) (user=alan mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k18IQkuP002422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Feb 2006 13:26:47 -0500 (EST) Message-ID: <43EA37E6.7010301@columbia.edu> Date: Wed, 08 Feb 2006 13:26:46 -0500 From: Alan Crosswell User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Frank da Cruz CC: Melissa Metz , emailtech-wg@columbia.edu Subject: Re: Fwd: REMINDER: Columbia Email Unavailable Thu, 02/09 12am-4am References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: That's because you are close to the last user of MM. We don't officially support MM. /a Frank da Cruz wrote: >> FYI, I was asked to send reminder messages, in case users forget >> their Cyrus move in the week before they get moved. Don't be >> surprised if someone mentions it. I sent the first set yesterday >> (for Thursday), and am sending more now for Friday. >> > Does somebody want to mention MM on the Cyrus configuration page? > > http://www.columbia.edu/acis/email/cyrus/config/ > > I have had zero feedback after announcing the new MM a few months ago: > > http://www.columbia.edu/~fdc/mm/ > > I've been using exclusively with Pop for the past 8 weeks or so, > it's OK. > > - Frank > From fdc@columbia.edu Thu Feb 9 09:56:34 2006 Flags: 000000000001 Return-Path: Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k19EuYLs015216; Thu, 9 Feb 2006 09:56:34 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k19EuYtV012599; Thu, 9 Feb 2006 09:56:34 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id k19EuYKs012598; Thu, 9 Feb 2006 09:56:34 -0500 (EST) Date: Thu, 9 Feb 2006 9:56:34 EST From: Frank da Cruz To: Eric Weaver Cc: bug-mm@columbia.edu, eric@columbia.edu, unix@columbia.edu Subject: Re: ld.so.1: emacs: fatal: libpng.so.3 In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: > ld.so.1: emacs: fatal: libpng.so.3: open failed: No such file or > directory > Temp file kept: /u/11/e/eric/.mm-outgoing.29570 > Sounds like EMACS is not finding some lib it needs. What happens if you log in on a different host? > the above error just now occured on host banana when at MM's "send" > prompt, I typed edit. > > and I just tried a direct emacs (like from the shell without MM > involved and it failed... calling help desk now..) /Eric > Why don't you try the new MM? I've been using it for a couple months without incident. You're going to have to switch anyway when your Cyrus cutover comes around. http://www.columbia.edu/~fdc/mm/ - Frank From dcl@columbia.edu Thu Feb 9 10:03:22 2006 Flags: 000000000001 Return-Path: Received: from escargot.cc.columbia.edu (escargot.cc.columbia.edu [128.59.39.35]) by elderberry.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k19F3M27015066; Thu, 9 Feb 2006 10:03:22 -0500 (EST) Received: by escargot.cc.columbia.edu (Postfix, from userid 117) id 103FF29D789; Thu, 9 Feb 2006 10:03:22 -0500 (EST) From: Don Lanini To: eric@columbia.edu Cc: bug-mm@columbia.edu, eric@columbia.edu, unix@columbia.edu In-reply-to: (message from Eric Weaver on Thu, 9 Feb 2006 9:26:24 EST) Subject: Re: ld.so.1: emacs: fatal: libpng.so.3 References: Message-Id: <20060209150322.103FF29D789@escargot.cc.columbia.edu> Date: Thu, 9 Feb 2006 10:03:22 -0500 (EST) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.28.166 Status: This was me doing opium updates including libpng. The library was unavaialble only during the upgrade for the individual machine itself and lasted ~4-5 minutes. No one should be getting this error anymore. /d ------------------------------------------------------------------------------- ld.so.1: emacs: fatal: libpng.so.3: open failed: No such file or directory Temp file kept: /u/11/e/eric/.mm-outgoing.29570 the above error just now occured on host banana when at MM's "send" prompt, I typed edit. and I just tried a direct emacs (like from the shell without MM involved and it failed... calling help desk now..) /Eric From brennan@columbia.edu Fri Feb 10 13:55:59 2006 Flags: 000000000001 Return-Path: Received: from sodor.cc.columbia.edu (sodor.cc.columbia.edu [128.59.39.201]) (user=brennan mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k1AItwRI013139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Feb 2006 13:55:59 -0500 (EST) Date: Fri, 10 Feb 2006 13:55:59 -0500 From: Joseph Brennan To: Frank da Cruz Subject: Re: MM? Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Status: --On Friday, February 10, 2006 13:26 -0500 Frank da Cruz wrote: > Alan says I am the last user of MM, and therefore instructions for > converting MM to Cyrus should not be posted. Do you agree? How do > we know who is using MM? You look at message IDs of sent mail? > > - Frank > Yes, counted on cunix hosts, there were 4 MM messages yesterday and 7 the day before. I hadn't noticed how low it was now. Joe From MAILER-DAEMON@columbia.edu Thu Nov 9 09:37:55 2006 Flags: 000000000005 Date: Thu, 09 Nov 2006 09:37:55 AM -0500 From: Mail System Internal Data Subject: Your mail has been moved Message-ID: <1234567890@columbia.edu> Status: Your mail has been moved to Columbia's new mail system, called mail.columbia.edu. If you connect to the new system for the first time and don't see all of your mail folders, don't worry -- it may be that the migration of ALL of your messages is not yet complete. People with large amounts of mail are the most likely to have this happen, as it takes longer to move large numbers of messages. If you are using Pine or Cubmail, the program will automatically connect you to the new mail system once the move is complete. If you are using another mail program, you need to reconfigure the name of the mail server in your preferences. Find the box with imap.columbia.edu or pop.columbia.edu and change it to mail.columbia.edu. You may also need to blank out an "IMAP directory" setting -- different programs call it different things. The online instructions, at will show you exactly what to look for. People at the Medical Center campus should be especially sure to review these instructions, as you are very likely to need to change this second setting, to remove the "mail/" that is probably part of your current settings. If you need help or have other questions, see: Additionally, local help is available: MEDICAL CENTER: People on the Medical Center campus requiring assistance can visit the following web site and you will be able to connect online to live consulting assistance: BARNARD: Barnard faculty, students and staff should call the Barnard Help Desk (212-854-7172) for assistance. Please see this Barnard web page for additional information: TEACHERS COLLEGE: Visit the Academic Computing office in 234 Horace Mann, call 212-678-3302 or email . From MAILER-DAEMON@columbia.edu Thu Nov 9 09:37:55 2006 Flags: 000000000005 Date: Thu, 09 Nov 2006 09:37:55 AM -0500 From: Mail System Internal Data Subject: Your mail has been moved Message-ID: <1234567890@columbia.edu> Status: Your mail has been moved to Columbia's new mail system, called mail.columbia.edu. If you connect to the new system for the first time and don't see all of your mail folders, don't worry -- it may be that the migration of ALL of your messages is not yet complete. People with large amounts of mail are the most likely to have this happen, as it takes longer to move large numbers of messages. If you are using Pine or Cubmail, the program will automatically connect you to the new mail system once the move is complete. If you are using another mail program, you need to reconfigure the name of the mail server in your preferences. Find the box with imap.columbia.edu or pop.columbia.edu and change it to mail.columbia.edu. You may also need to blank out an "IMAP directory" setting -- different programs call it different things. The online instructions, at will show you exactly what to look for. People at the Medical Center campus should be especially sure to review these instructions, as you are very likely to need to change this second setting, to remove the "mail/" that is probably part of your current settings. If you need help or have other questions, see: Additionally, local help is available: MEDICAL CENTER: People on the Medical Center campus requiring assistance can visit the following web site and you will be able to connect online to live consulting assistance: BARNARD: Barnard faculty, students and staff should call the Barnard Help Desk (212-854-7172) for assistance. Please see this Barnard web page for additional information: TEACHERS COLLEGE: Visit the Academic Computing office in 234 Horace Mann, call 212-678-3302 or email . From eric@columbia.edu Fri Nov 17 14:21:18 2006 Flags: 000000000011 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Fri, 17 Nov 2006 14:21:19 -0500 X-Sieve: CMU Sieve 2.3 Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id kAHJLJWr027065 for ; Fri, 17 Nov 2006 14:21:19 -0500 Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kAHJLIi0003577; Fri, 17 Nov 2006 14:21:18 -0500 (EST) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kAHJLIe3007138; Fri, 17 Nov 2006 14:21:18 -0500 (EST) Received: (from eric@localhost) by banana.cc.columbia.edu (8.13.7/8.12.3/Submit) id kAHJLI00007137; Fri, 17 Nov 2006 14:21:18 -0500 (EST) Date: Fri, 17 Nov 2006 14:21:18 EST From: Eric Weaver To: Frank da Cruz Cc: eric@columbia.edu Subject: Re: setting reply append/prepend In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 What I was looking for was a way to have MM put my typein above vs below the original msg body: my response... > original > msg text vs. > original > msg text my response... In Thunderbird, for example, under "Composition & Addressing" is the option "Automatically quote the original message when replying", then either "start my reply above the quote" or "start my reply below the quote" or "select the quote". MM seems to only do "below". Most folks use "above" for reader expediency. Also, noticing the "use-editor-always" variable in your response, I tried setting it to yes think that it would save me some keystrokes, but then when I forward a message none of the emacs buffers contain the original msg which impedes composing a comment about it. Bummer... /ew >> Is there a setting (or other control method) in MM for determining >> whether the reply text is appended or prepended? I thought that there >> was but can't find it. >> >When you say "reply sender including" or "reply all including", you get >a new message with the reply original text marked with "> ". You can put >your reply anywhere you want. I recommend: > > set editor emacs > set use-editor-always yes > >For what it's worth, here are all the customizations in my .mminit: > > set autowrap-column -1 > set append-new-mail true > set clear-screen yes > set crt-filter more > set default-mail-type mbox > set default-send-command send > set dont-type-headers received, message-id, mailed-by, (etc etc...) > set editor emacs > set expunge-on-bye always > set mail-file ~/MAIL/mail.txt > set new-file-mode 600 > set personal-name Frank da Cruz > set print-filter textps | lpr -h -Pwatson6 > set reply-all yes > set suspend-on-exit yes > set suspend-on-quit yes > set terse-text-prompt yes > set user-headers Content-Type > set use-editor-always yes > >- Frank From fdc@columbia.edu Fri Nov 17 14:35:50 2006 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Fri, 17 Nov 2006 14:35:51 -0500 X-Sieve: CMU Sieve 2.3 Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id kAHJZpIm029934 for ; Fri, 17 Nov 2006 14:35:51 -0500 Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kAHJZojd006772; Fri, 17 Nov 2006 14:35:50 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kAHJZoA3016754; Fri, 17 Nov 2006 14:35:50 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id kAHJZo6q016753; Fri, 17 Nov 2006 14:35:50 -0500 (EST) Date: Fri, 17 Nov 2006 14:35:50 EST From: Frank da Cruz To: Eric Weaver Subject: Re: setting reply append/prepend In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 > What I was looking for was a way to have MM put my typein above vs below the > original msg body: > > my response... > > > original > > msg text > > vs. > > > original > > msg text > > my response... > Right, I know. Like I said, this is solved by "set use-editor-always yes". > Also, noticing the "use-editor-always" variable in your response, I tried > setting it to yes think that it would save me some keystrokes, but then > when I forward a message none of the emacs buffers contain the original > msg which impedes composing a comment about it. Bummer... > Yes, but it's always been that way for FORWARD; I complained about it many years ago and I forget the answer but apparently it was too hard to fix. The workaround is: MM-Read> forward user@host (enter editor) (exit editor manually) MM-Send> edit (back in editor with forwarded message) It's a minor pain but I've grown quite used to it. About SORT, I haven't had a chance to look into it yet, but I can tell you I never touched the SORT command! I see your point, it no longer offers any option of what to sort by. Somebody deliberately removed this. I suspect it was Nelson Beebe at the U of Utah in his gigantic cleanup. He did some other things like that, such as removing mail-file locking (I put it back), but I didn't notice the change to SORT. But on the whole Nelson's changes were extremely valuable because before them, MM could be built only for Solaris; now you can build it for Linux, FreeBSD, Mac OS X, almost anything. I'll add this to my list, but I don't get much chance to work on MM these days! - Frank From eric@columbia.edu Sat Nov 18 09:31:35 2006 Flags: 000000000011 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Sat, 18 Nov 2006 09:31:35 -0500 X-Sieve: CMU Sieve 2.3 Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id kAIEVZC5022597 for ; Sat, 18 Nov 2006 09:31:35 -0500 Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kAIEVZNN014279; Sat, 18 Nov 2006 09:31:35 -0500 (EST) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kAIEVZdp001705; Sat, 18 Nov 2006 09:31:35 -0500 (EST) Received: (from eric@localhost) by banana.cc.columbia.edu (8.13.7/8.12.3/Submit) id kAIEVZf0001704; Sat, 18 Nov 2006 09:31:35 -0500 (EST) Date: Sat, 18 Nov 2006 9:31:35 EST From: Eric Weaver To: Frank da Cruz Cc: eric@columbia.edu Subject: Re: setting reply append/prepend In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 My response text always starts after the original msg text, regardless of using an editor or text-input and regardless of the value for use-editor-always. I've checked by emacs init files and see nothing that would force the point/mark initially to the bottom; so, maybe you have something in effect to force it to the top? If not MM var, then maybe emacs code or shell env variable? While on the topic, do you have any emacs code that detects that running under MM so that one can make MM-specific settings to those emacs buffers? Thanks for the "forward" info. I've not yet decided which way I'll proceed wrt it. Too bad about the sort, but then I don't use non-chrono sorts often; not a major loss. But if someone hacks it back in, it'll be nice. /Eric >> What I was looking for was a way to have MM put my typein above vs below the >> original msg body: >> >> my response... >> >> > original >> > msg text >> >> vs. >> >> > original >> > msg text >> >> my response... >> >Right, I know. Like I said, this is solved by "set use-editor-always yes". > >> Also, noticing the "use-editor-always" variable in your response, I tried >> setting it to yes think that it would save me some keystrokes, but then >> when I forward a message none of the emacs buffers contain the original >> msg which impedes composing a comment about it. Bummer... >> >Yes, but it's always been that way for FORWARD; I complained about it >many years ago and I forget the answer but apparently it was too hard to >fix. The workaround is: > > MM-Read> forward user@host > (enter editor) > (exit editor manually) > MM-Send> edit > (back in editor with forwarded message) > >It's a minor pain but I've grown quite used to it. > >About SORT, I haven't had a chance to look into it yet, but I can tell you >I never touched the SORT command! I see your point, it no longer offers any >option of what to sort by. Somebody deliberately removed this. I suspect >it was Nelson Beebe at the U of Utah in his gigantic cleanup. He did some >other things like that, such as removing mail-file locking (I put it back), >but I didn't notice the change to SORT. But on the whole Nelson's changes >were extremely valuable because before them, MM could be built only for >Solaris; now you can build it for Linux, FreeBSD, Mac OS X, almost anything. > >I'll add this to my list, but I don't get much chance to work on MM these >days! > >- Frank From fdc@columbia.edu Sat Nov 18 11:53:02 2006 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Sat, 18 Nov 2006 11:53:03 -0500 X-Sieve: CMU Sieve 2.3 Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id kAIGr3J8002943 for ; Sat, 18 Nov 2006 11:53:03 -0500 Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kAIGr35T025562; Sat, 18 Nov 2006 11:53:03 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kAIGr2xt018709; Sat, 18 Nov 2006 11:53:02 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id kAIGr2ZG018708; Sat, 18 Nov 2006 11:53:02 -0500 (EST) Date: Sat, 18 Nov 2006 11:53:02 EST From: Frank da Cruz To: Eric Weaver Subject: Re: setting reply append/prepend In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 > My response text always starts after the original msg text, regardless of > using an editor or text-input and regardless of the value for > use-editor-always. > OK, maybe the cursor is at the end but all you have to do is ESC < to put the cursor at the top (two keystrokes). > While on the topic, do you have any emacs code that detects that running > under MM so that one can make MM-specific settings to those emacs buffers? > You can tell that EMACS knows it's running under MM because a lot of things are set up in a special way -- separate buffers for original message, the message being composed, and the headers, for example. When MM starts EMACS, it instructs EMACS to execute "mmail.el", which you can find here: /opt/ACISmm/lib/mmail.el If you want to change how it works, you can copy this file into your own space, e.g.: cd mkdir emacs cp /opt/ACISmm/lib/mmail.el ~/emacs/ and in your .mminit: set mmail-path ~/emacs/mmail.el and then modify your copy of mmail.el to do whatever you want. > Thanks for the "forward" info. I've not yet decided which way I'll > proceed wrt it. > > Too bad about the sort, but then I don't use non-chrono sorts often; not a > major loss. But if someone hacks it back in, it'll be nice. > OK. - Frank From eric@columbia.edu Sat Jan 20 11:23:45 2007 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Sat, 20 Jan 2007 11:23:46 -0500 X-Sieve: CMU Sieve 2.3 Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id l0KGNkAW010024 for ; Sat, 20 Jan 2007 11:23:46 -0500 Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0KGNkqS027413; Sat, 20 Jan 2007 11:23:46 -0500 (EST) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0KGNjU3021271; Sat, 20 Jan 2007 11:23:45 -0500 (EST) Received: (from eric@localhost) by banana.cc.columbia.edu (8.13.7/8.12.3/Submit) id l0KGNjKi021270; Sat, 20 Jan 2007 11:23:45 -0500 (EST) Date: Sat, 20 Jan 2007 11:23:45 EST From: Eric Weaver To: Frank da Cruz Cc: eric@columbia.edu Subject: Re: first word From causes problems In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Retested... it quoted the From. It works. Thanks! /ew >> mm=/p/kd/fdc/mm-pop/mm >> PATH=/p/kd/fdc/mm-pop:$PATH $mm >> >Try it now. > >- Frank From eric@columbia.edu Sat Jan 20 11:42:47 2007 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Sat, 20 Jan 2007 11:42:48 -0500 X-Sieve: CMU Sieve 2.3 Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id l0KGgmnZ011874 for ; Sat, 20 Jan 2007 11:42:48 -0500 Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54]) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0KGglKv029220; Sat, 20 Jan 2007 11:42:47 -0500 (EST) Received: from banana.cc.columbia.edu (localhost [127.0.0.1]) by banana.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0KGgll3023193; Sat, 20 Jan 2007 11:42:47 -0500 (EST) Received: (from eric@localhost) by banana.cc.columbia.edu (8.13.7/8.12.3/Submit) id l0KGglqJ023192; Sat, 20 Jan 2007 11:42:47 -0500 (EST) Date: Sat, 20 Jan 2007 11:42:47 EST From: Eric Weaver To: fdc@columbia.edu Cc: eric@columbia.edu Subject: [askcuit@columbia.edu: Re: first word From causes problems] Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Fyi, here's the note that I got from UHD. /ew --------------- Return-Path: Received: from knockwurst.cc.columbia.edu ([unix socket]) by knockwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Fri, 19 Jan 2007 14:45:41 -0500 X-Sieve: CMU Sieve 2.3 Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by knockwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id l0JJjfXK020926 for ; Fri, 19 Jan 2007 14:45:41 -0500 Received: from pineapple.cc.columbia.edu (pineapple.cc.columbia.edu [128.59.29.164]) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0JJjfvq017872; Fri, 19 Jan 2007 14:45:41 -0500 (EST) Received: from pineapple.cc.columbia.edu (localhost [127.0.0.1]) by pineapple.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0JJjfQM029707; Fri, 19 Jan 2007 14:45:41 -0500 (EST) Received: from localhost (ml2751@localhost) by pineapple.cc.columbia.edu (8.13.7/8.12.3/Submit) with ESMTP id l0JJjfd0029704; Fri, 19 Jan 2007 14:45:41 -0500 (EST) X-Authentication-Warning: pineapple.cc.columbia.edu: ml2751 owned process doing -bs Date: Fri, 19 Jan 2007 14:45:41 -0500 (EST) From: askcuit@columbia.edu Sender: ml2751@columbia.edu Reply-To: askcuit@columbia.edu To: Eric Weaver Subject: Re: first word From causes problems In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Unfortunately, we no longer officially support MM. Michael Lain Associate Technology Service Technician Client Services Center CUIT Client Services Columbia University Online Support (24 hours): http://www.columbia.edu/cuit/support/ Help Desk Phone Support: 212-854-1919 (M-Th 8a-11p, F 8a-7p, Sat 10a-6p, Sun 3p-11p) CUNIX Password Reset At: 213 Butler, 323 IAB, 251 Mudd Walk-in Support: 102 Philosophy (M-F 10a-6p) Note: Many walk-in services require an appointment in advance On Fri, 19 Jan 2007, Eric Weaver wrote: > If the word "From" (not "from") is the first word in the body of the > message, MM splits the mail... The headers become one message, the first line > of the body gets tossed (well, MM tries to parse it into header stuff), and the > non-first lines become a second message. /Eric > > From fdc@columbia.edu Mon Jan 22 11:21:53 2007 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Mon, 22 Jan 2007 11:21:54 -0500 X-Sieve: CMU Sieve 2.3 Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id l0MGLs5j023378 for ; Mon, 22 Jan 2007 11:21:54 -0500 Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0MGLrem005115; Mon, 22 Jan 2007 11:21:54 -0500 (EST) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l0MGLrX0012006; Mon, 22 Jan 2007 11:21:53 -0500 (EST) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id l0MGLrof012005; Mon, 22 Jan 2007 11:21:53 -0500 (EST) Date: Mon, 22 Jan 2007 11:21:53 EST From: Frank da Cruz To: Eric Weaver Subject: Re: MM not prompting for password In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 > Sometimes MM does not prompt for my password when I issue "get". I've not > done extensive testing to isolate the conditions, but it seems to be when > I've done a get recently (ie. on the order of seconds or minutes, not > hours). > So you're talking about "Method 1" (running the POP script from within MM every time you want to fetch mail?). I must confess, I like Method 1 so little that I haven't used it since I finished coding it. Anyway, when you start MM in this configuration $ touch ~/.mm-use-pop MM> set movemail-path /p/kd/fdc/mm-pop/pop.ksc it asks for your password once when you start it and is supposed to remember it until you exit/quit/bye. > At those times when it does not reprompt, it does not pull in my mail. > Well, it is not supposed to reprompt, but it *is* supposed to get your mail. > I know that there are mail msgs waiting in cyrus at that time because I > have a Thunderbird window open at the same time. > And Thunderbird is not grabbing the mail itself? - Frank From billw@cisco.com Mon Jun 11 02:58:31 2007 Flags: 000000000011 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Tue, 12 Jun 2007 12:10:34 -0400 X-Sieve: CMU Sieve 2.3 Received: from jujube.cc.columbia.edu (jujube.cc.columbia.edu [128.59.28.170]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id l5CGAYTr030956 for ; Tue, 12 Jun 2007 12:10:34 -0400 Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by jujube.cc.columbia.edu (8.13.7/8.13.6) with SMTP id l5CGASs5021445; Tue, 12 Jun 2007 12:10:33 -0400 (EDT) Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 08:59:44 -0700 (PDT) X-Return-Path: X-Received: from sj-iport-3.cisco.com ([171.71.176.72]) by lingling.panda.com with TCP/SMTP; Mon, 11 Jun 2007 23:59:27 -0700 (PDT) X-Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 11 Jun 2007 23:59:18 -0700 X-IronPort-AV: i="4.16,410,1175497200"; d="scan'208"; a="492795239:sNHT35618378" X-Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5C6xHwu004541 for ; Mon, 11 Jun 2007 23:59:17 -0700 X-Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5C6xDaI003872 for ; Tue, 12 Jun 2007 06:59:17 GMT X-Received: (from billw@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA18305 for tops-20@lingling.panda.com; Mon, 11 Jun 2007 23:58:31 -0700 (PDT) Sender: Bill Westfield Date: Mon, 11 Jun 2007 23:58:31 PDT From: William "Chops" Westfield To: tops-20@Lingling.Panda.COM Subject: Unix MM... Message-ID: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=124; t=1181631557; x=1182495557; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=billw@cisco.com; z=From:=20William=20=22Chops=22=20Westfield=20 |Subject:=20Unix=20MM... |Sender:=20Bill=20Westfield=20; bh=OO3tOSUGzhWImWD5CmdbIJm3BmBtJLP9K8IUftPdEKk=; b=gZILGvOh7QLYTXu/mVTinK9Tisl3/NiycP7rUdFwtZL89wO0O7SEtx/cqZBkv3iBeKGs3Y+3 A/DSfDLhkUF36qEiAWbMg5Er4v3xfisy/E5Z54l8TLKvQy1j0Jc/Ev3v; Authentication-Results: sj-dkim-2; header.From=billw@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); ReSent-Date: Tue, 12 Jun 2007 08:59:33 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Unix MM... ReSent-Message-ID: X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 128.59.28.170 What the status and current location of the latest version of the C (Columbia, originally) MM for unix? Thanks Bill W From fdc@columbia.edu Tue Jun 12 12:18:16 2007 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Tue, 12 Jun 2007 20:43:56 -0400 X-Sieve: CMU Sieve 2.3 Received: from tepin.cc.columbia.edu (tepin.cc.columbia.edu [128.59.28.169]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id l5D0huMQ025035 for ; Tue, 12 Jun 2007 20:43:56 -0400 Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by tepin.cc.columbia.edu (8.13.7/8.13.6) with SMTP id l5D0hp1i028196; Tue, 12 Jun 2007 20:43:55 -0400 (EDT) Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 17:33:23 -0700 (PDT) X-Return-Path: X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Tue, 12 Jun 2007 09:18:27 -0700 (PDT) X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5CGIKsA015151; Tue, 12 Jun 2007 12:18:20 -0400 (EDT) X-Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id l5CGIGM7015150; Tue, 12 Jun 2007 12:18:16 -0400 (EDT) Date: Tue, 12 Jun 2007 12:18:16 EDT From: Frank da Cruz To: William "Chops" Westfield Cc: TOPS-20 List Moderator , tops-20@Lingling.Panda.COM Subject: Re: Unix MM... In-Reply-To: Message-ID: ReSent-Date: Tue, 12 Jun 2007 17:33:16 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Unix MM... ReSent-Message-ID: X-Spam-Score: 0.5 () CU_RE X-Scanned-By: MIMEDefang 2.48 on 128.59.28.169 > What the status and current location of the latest version of the > C (Columbia, originally) MM for unix? > http://www.columbia.edu/~fdc/mm/ - Frank From fdc@columbia.edu Wed Jun 13 11:05:25 2007 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Wed, 13 Jun 2007 11:05:39 -0400 X-Sieve: CMU Sieve 2.3 Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id l5DF5d49014993 for ; Wed, 13 Jun 2007 11:05:39 -0400 Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5DF5due016466 for ; Wed, 13 Jun 2007 11:05:39 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5DF5Uh1025593; Wed, 13 Jun 2007 11:05:30 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id l5DF5PYb025591; Wed, 13 Jun 2007 11:05:25 -0400 (EDT) Date: Wed, 13 Jun 2007 11:05:25 EDT From: Frank da Cruz To: "Nelson H. F. Beebe" Cc: TOPS-20 List Moderator Subject: Re: Unix MM... In-Reply-To: Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 > William "Chops" Westfield asks > > >> What the status and current location of the latest version of the > >> C (Columbia, originally) MM for unix? > > Frank da Cruz will no doubt respond too. > Yup. As noted, the latest (Dec 2005) Columbia version is here: http://www.columbia.edu/~fdc/mm/ > At Utah, we've been using mm-ccmd-0.95-20060109 for the last 18 > months; this is an autoconfigurized version of mm that builds on many > Unix platforms (Sun Solaris IA-32 and SPARC, SGI IRIX MIPS, DEC OSF/1 > Alpha, GNU/Linux (many architectures), ...). > This one is just a wee bit behind my version. The Columbia and Utah versions diverged rather dramatically around the turn of the millenium; I did a lot of work on bugs and features not knowing that Nelson also doing a lot of work on portability and modernization. Finally in December 2005 I did my best to reconcile the two versions, and the result is evidently the one at Nelson's place: http://www.math.utah.edu/pub/mm/mm-ccmd-0.95.20051208.autoconf.tar.gz ftp://ftp.math.utah.edu/pub/mm/mm-ccmd-0.95.20051208.autoconf.tar.gz However, for some reason it seems we got out of sync again; I did a few minor things since then: fixed some bugs, some code cleanups, copyright notice updates, I restored the mail-file locking mechanism that Nelson took out (this is conditionally compiled) because we need it here. Some filenames were distinct only in casing, e.g. foo.h and foo.H, which doesn't work on case-insensitive file systems; I changed the names where needed, e.g. to foo.hh. I added a command QDELETE (QD) that is the same as DELETE -- people who read a lot of spam through "more" or "less" will understand :-) The differences between Nelson's and my versions are here: ftp://kermit.columbia.edu/kermit/mm/test/mm.diff ftp://kermit.columbia.edu/kermit/mm/test/ccmd.diff ftp://kermit.columbia.edu/kermit/mm/test/notes-fdc.txt (edit history) or by http: http://kermit.columbia.edu/ftp/mm/test/mm.diff http://kermit.columbia.edu/ftp/mm/test/ccmd.diff http://kermit.columbia.edu/ftp/mm/test/notes-fdc.txt (edit history) - Frank From fdc@columbia.edu Wed Jun 13 11:05:25 2007 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Wed, 13 Jun 2007 23:25:20 -0400 X-Sieve: CMU Sieve 2.3 Received: from cayenne.cc.columbia.edu (cayenne.cc.columbia.edu [128.59.28.166]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id l5E3PJ6w019982 for ; Wed, 13 Jun 2007 23:25:19 -0400 Received: from lingling.panda.com (lingling.panda.com [206.124.149.115]) by cayenne.cc.columbia.edu (8.13.7/8.13.6) with SMTP id l5E3PDrO003411; Wed, 13 Jun 2007 23:25:18 -0400 (EDT) Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jun 2007 20:14:04 -0700 (PDT) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jun 2007 20:13:19 -0700 (PDT) X-Return-Path: X-Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jun 2007 08:05:36 -0700 (PDT) X-Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5DF5Uh1025593; Wed, 13 Jun 2007 11:05:30 -0400 (EDT) X-Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.13.7/8.12.8/Submit) id l5DF5PYb025591; Wed, 13 Jun 2007 11:05:25 -0400 (EDT) Date: Wed, 13 Jun 2007 11:05:25 EDT From: Frank da Cruz To: "Nelson H. F. Beebe" Cc: TOPS-20 List Moderator Subject: Re: Unix MM... In-Reply-To: Message-ID: X-ReSent-Date: Wed, 13 Jun 2007 20:13:12 -0700 (PDT) X-ReSent-From: Mark Crispin X-ReSent-To: TOPS-20 Hackers and Yackers X-ReSent-Subject: Re: Unix MM... X-ReSent-Message-ID: ReSent-Date: Wed, 13 Jun 2007 20:13:55 -0700 (PDT) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Unix MM... ReSent-Message-ID: X-Spam-Score: 0.5 () CU_RE X-Scanned-By: MIMEDefang 2.48 on 128.59.28.166 > William "Chops" Westfield asks > > >> What the status and current location of the latest version of the > >> C (Columbia, originally) MM for unix? > > Frank da Cruz will no doubt respond too. > Yup. As noted, the latest (Dec 2005) Columbia version is here: http://www.columbia.edu/~fdc/mm/ > At Utah, we've been using mm-ccmd-0.95-20060109 for the last 18 > months; this is an autoconfigurized version of mm that builds on many > Unix platforms (Sun Solaris IA-32 and SPARC, SGI IRIX MIPS, DEC OSF/1 > Alpha, GNU/Linux (many architectures), ...). > This one is just a wee bit behind my version. The Columbia and Utah versions diverged rather dramatically around the turn of the millenium; I did a lot of work on bugs and features not knowing that Nelson also doing a lot of work on portability and modernization. Finally in December 2005 I did my best to reconcile the two versions, and the result is evidently the one at Nelson's place: http://www.math.utah.edu/pub/mm/mm-ccmd-0.95.20051208.autoconf.tar.gz ftp://ftp.math.utah.edu/pub/mm/mm-ccmd-0.95.20051208.autoconf.tar.gz However, for some reason it seems we got out of sync again; I did a few minor things since then: fixed some bugs, some code cleanups, copyright notice updates, I restored the mail-file locking mechanism that Nelson took out (this is conditionally compiled) because we need it here. Some filenames were distinct only in casing, e.g. foo.h and foo.H, which doesn't work on case-insensitive file systems; I changed the names where needed, e.g. to foo.hh. I added a command QDELETE (QD) that is the same as DELETE -- people who read a lot of spam through "more" or "less" will understand :-) The differences between Nelson's and my versions are here: ftp://kermit.columbia.edu/kermit/mm/test/mm.diff ftp://kermit.columbia.edu/kermit/mm/test/ccmd.diff ftp://kermit.columbia.edu/kermit/mm/test/notes-fdc.txt (edit history) or by http: http://kermit.columbia.edu/ftp/mm/test/mm.diff http://kermit.columbia.edu/ftp/mm/test/ccmd.diff http://kermit.columbia.edu/ftp/mm/test/notes-fdc.txt (edit history) - Frank From eric@columbia.edu Mon Sep 17 10:03:55 2007 Flags: 000000000015 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Mon, 17 Sep 2007 10:03:57 -0400 X-Sieve: CMU Sieve 2.3 Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id l8HE3uL1029272 for ; Mon, 17 Sep 2007 10:03:56 -0400 Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8HE3tBA010255; Mon, 17 Sep 2007 10:03:55 -0400 (EDT) Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l8HE3tQ6024507; Mon, 17 Sep 2007 10:03:55 -0400 (EDT) Received: (from eric@localhost) by mango.cc.columbia.edu (8.14.1/8.12.3/Submit) id l8HE3tJZ024505; Mon, 17 Sep 2007 10:03:55 -0400 (EDT) Date: Mon, 17 Sep 2007 10:03:55 EDT From: Eric Weaver To: bug-mm@columbia.edu Cc: eric@columbia.edu Subject: MM shows wrong day in header cmd output Bug-Report: Bug in Columbia MM, version 0.95.0(68) (SYSV) Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 Sometimes (maybe most-times, I've not [yet] spent time quantifying this one) the output of MM's "header" command shows a date that is different from the date in the message's "Date:" (& other) header line(s). Is this a known bug? Can/will it be fixed? /ew From fdc@columbia.edu Tue Sep 18 10:14:08 2007 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Tue, 18 Sep 2007 10:14:09 -0400 X-Sieve: CMU Sieve 2.3 Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id l8IEE97e021862 for ; Tue, 18 Sep 2007 10:14:09 -0400 Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8IEE81d014534; Tue, 18 Sep 2007 10:14:08 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l8IEE83V011624; Tue, 18 Sep 2007 10:14:08 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.14.1/8.12.8/Submit) id l8IEE8PM011623; Tue, 18 Sep 2007 10:14:08 -0400 (EDT) Date: Tue, 18 Sep 2007 10:14:08 EDT From: Frank da Cruz To: Eric Weaver Subject: Re: MM shows wrong day in header cmd output In-Reply-To: Cc: bug-mm@columbia.edu Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 > Sometimes (maybe most-times, I've not [yet] spent time quantifying this one) > the output of MM's "header" command shows a date that is different from the > date in the message's "Date:" (& other) header line(s). Is this a known bug? > Can/will it be fixed? /ew > There have always been mysterious problems with date skew... The pop up, we fix them, they lay dormant for a few years, and then pop up again. I'll keep my eyes peeled; meanwhile if you pin it down any better let me know. - Frank From mrc@Lingling.Panda.COM Tue Jan 1 19:28:01 2008 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Tue, 01 Jan 2008 19:37:44 -0500 X-Sieve: CMU Sieve 2.3 Received: from calabash.cc.columbia.edu (calabash.cc.columbia.edu [128.59.28.168]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id m020bilh018774 for ; Tue, 1 Jan 2008 19:37:44 -0500 Received: from Lingling.Panda.COM (lingling.panda.com [206.124.149.115]) by calabash.cc.columbia.edu (8.14.1/8.14.1) with SMTP id m020bclO012988; Tue, 1 Jan 2008 19:37:43 -0500 (EST) Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 16:30:07 -0800 (PST) X-Return-Path: X-Received: from pangtzu.panda.com ([206.124.149.117]) by Lingling.Panda.COM with TCP/SMTP; Tue, 1 Jan 2008 16:28:06 -0800 (PST) Date: Tue, 1 Jan 2008 16:28:01 -0800 (PST) From: Mark Crispin Sender: mrc@pangtzu.panda.com To: Thomas DeBellis cc: Tops-20 Wizards Subject: Re: Section 0 word pointers from a non-zero section? In-Reply-To: <477AB8D6.9050303@optonline.net> Message-ID: References: <47798DE5.7070106@optonline.net> <477AB8D6.9050303@optonline.net> User-Agent: Alpine 1.00 (OSX 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII ReSent-Date: Tue, 1 Jan 2008 16:30:00 -0800 (PST) ReSent-From: TOPS-20 List Moderator ReSent-To: TOPS-20 Distribution: ; ReSent-Subject: Re: Section 0 word pointers from a non-zero section? ReSent-Message-ID: ReSent-User-Agent: Alpine 1.00 (OSX 882 2007-12-20) X-Spam-Score: 0.5 () CU_RE X-Scanned-By: MIMEDefang 2.48 on 128.59.28.168 On Tue, 1 Jan 2008, Thomas DeBellis wrote: > In other words, the subroutine does an XMOVEI and rounds that up by a > page (to allow DDT to still work when debugging the code). Once I > determine that the handle has a JFN in it (and do some more checking), > I assume that this is my own executable. I do a FFFP% to get to the > last page of my own executable, add one and then map that post- > ultimate page in. Since the process has the .EXE locked, this works > fine. You blow up when you touch the page (even if you're running > with wheel enabled). What a hack! I just tried it and verified that it does, in fact, work. PMAP is smart enough to check to see if there's a super-index block for the page, but doesn't check if the file page itself has a mapping. However, you're screwed if the filesize is a multiple of 512 pages. > However, I can not remember whether the idea of mapping in a page > beyond the current process' (locked) executable file was my own or > not. Gee, I hope it was! Using the running process's binary instead of a temporary file is almost certainly your idea. As for updating MAPSER to IMAP4, I think not. The RFC 822 parser in MAPSER, while still servicable and better than MM's, is aging and more importantly there's no MIME parser at all. It would make much more sense to build UW imapd for TOPS-20. There's a bunch of other stuff in the IMAP4 base specification than an IMAP2 implementation didn't have to worry about, such as parsing RFC 822 dates (IMAP2 allowed you to treat it as a blob-string). Unicode and charset support is even more daunting. Fortunately, the c-client library already builds fine on TOPS-20, and it wouldn't be too much trauma to get imapd to build as well (I've just never done it). There aren't any TOPS-20 local file drivers, but it would make more sense to port the mix format driver than mtx (which is more or less the TOPS-20 format) since mtx format lacks metadata that IMAP needs. mbx format has the metadata, but it's 12 years old and flat file formats just aren't much good these days. You can't expect to PMAP% an entire mailbox any more, not when people have 3 and 4 digit MB mailboxes. PMAP%ing the mix index, status, and current data file would make a lot of sense, though. However, the entire project makes no sense until we have some solution for SSL/TLS. Sending passwords in the clear is a bad idea on today's Internet. CRAM-MD5 would be easy enough to do (although the session would then be vulnerable to hijacking...have someone demonstrate hunt to you if you want to become very very scared), but we need support in TOPS-20 for a form of LOGIN% that does not validate passwords. I've thought about doing that >From time to time, perhaps something as trivial as adding JUMPE T2,RSKP or, if there's any chance that something already calls LOGIN% with AC2/0, MOVE T1,T2 AOJE T1,RSKP at CHKPSW+1. This ought to be alright since an unlogged in job is effectively WHEEL and CHKPSW is only called from LOGIN%. -- Mark -- http://panda.com/tops-20 TOPS-20: a great improvement over its successors From twp@unchi.org Mon Jun 30 14:35:58 2008 Flags: 000000000015 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Mon, 30 Jun 2008 14:36:20 -0400 X-Sieve: CMU Sieve 2.3 Received: from calabash.cc.columbia.edu (calabash.cc.columbia.edu [128.59.28.168]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id m5UIaJXd001708 for ; Mon, 30 Jun 2008 14:36:19 -0400 Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by calabash.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m5UIa8RA020509 for ; Mon, 30 Jun 2008 14:36:13 -0400 (EDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4801F1000403 for ; Mon, 30 Jun 2008 18:36:08 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (unknown [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 398EB10003F4 for ; Mon, 30 Jun 2008 18:36:08 +0000 (UTC) Received: from yclept.kendall.corp.akamai.com (yclept.kendall.corp.akamai.com [172.16.24.197]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 2976F1000091 for ; Mon, 30 Jun 2008 18:36:08 +0000 (GMT) Message-ID: <4869278E.7010605@unchi.org> Date: Mon, 30 Jun 2008 14:35:58 -0400 From: Tim Pierce User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: fdc@columbia.edu Subject: MM 0.91 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.63 on 128.59.28.168 Hi, Frank - I just learned that a new release of MM was issued in 2002. I'm told that it compiles cleanly on CentOS 4 and that it builds with some compiler hiccupage on recent Debian releases. Was very glad to hear it and am looking forward to trying it out on Ubuntu. In 1997 I spent about a week porting MM to a GNU-based autoconf framework and asked the MM team (whoever was listed as a contact in the README file) if Columbia was willing to release MM under some kind of open-source license so I could distribute a modified version. I was told that if I sent in patches that they would be considered. That sounded very nice, but I confess that at that point I doubted any new release of MM was forthcoming, so did not bother sending in patches. :-) If I were to make MM and CCMD buildable under autoconf, is that work that would interest you or anyone else at Columbia? I'm not promising to do it, but I'm more likely to be motivated to do it if I think that someone may find it useful. And if you're trying desperately not to be the MM maintainer, don't worry, just say so and I won't bug you again, I promise. --twp From fdc@columbia.edu Tue Jul 1 11:58:26 2008 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Tue, 01 Jul 2008 11:58:27 -0400 X-Sieve: CMU Sieve 2.3 Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id m61FwR9g020115 for ; Tue, 1 Jul 2008 11:58:27 -0400 Received: from sesame.cc.columbia.edu (sesame.cc.columbia.edu [128.59.59.56]) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m61FwRDk007399 for ; Tue, 1 Jul 2008 11:58:27 -0400 (EDT) Received: from sesame.cc.columbia.edu (localhost [127.0.0.1]) by sesame.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m61FwQ80014376; Tue, 1 Jul 2008 11:58:26 -0400 (EDT) Received: (from fdc@localhost) by sesame.cc.columbia.edu (8.14.1/8.14.1/Submit) id m61FwQJS014375; Tue, 1 Jul 2008 11:58:26 -0400 (EDT) Date: Tue, 1 Jul 2008 11:58:26 EDT From: Frank da Cruz To: Tim Pierce Subject: Re: MM 0.91 In-Reply-To: <4869278E.7010605@unchi.org> Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 > I just learned that a new release of MM was issued in 2002. > And a bunch more since then! > I'm told that it compiles cleanly on CentOS 4 and that it builds with some > compiler hiccupage on recent Debian releases. Was very glad to hear it > and am looking forward to trying it out on Ubuntu. > Be my guest! > In 1997 I spent about a week porting MM to a GNU-based autoconf > framework and asked the MM team (whoever was listed as a contact in the > README file) if Columbia was willing to release MM under some kind of > open-source license so I could distribute a modified version. I was > told that if I sent in patches that they would be considered. That > sounded very nice, but I confess that at that point I doubted any new > release of MM was forthcoming, so did not bother sending in patches. :-) > As you may know, I was the manager of the group that wrote the Unix version MM (the one we're talking about), and have been using it ever since and in fact I'm using it right now. Now and then something would come up and I'd have to make changes so I could keep on using it. Also I really needed to be able to send and receive 8-bit text (e.g. for Spanish) so I put some work into that. At the same time, Nelson Beebe at the U of Utah "modernized" the code so it would be portable to most current Unix OS's. Then in 2005-06 when the mail delivery method here was about to change, I had to adapt to using POP to fetch new mail, rather that simply noticing that it had magically appeared in a spool directory. (I did NOT add IMAP support because I didn't need it or want it, but maybe somebody else will want to do that.) Finally, I reconciled my sources with Nelson's. Here is the story, with links to the current source code: http://www.columbia.edu/~fdc/mm/ > If I were to make MM and CCMD buildable under autoconf, is that work > that would interest you or anyone else at Columbia? I'm not promising > to do it, but I'm more likely to be motivated to do it if I think that > someone may find it useful. > > And if you're trying desperately not to be the MM maintainer, don't > worry, just say so and I won't bug you again, I promise. > Well, take a look at what's been done since you last looked. As to putting it under an Open Source license, I would say sure, why not, as long as it's not GNU. Something simple like Berkeley: http://www.opensource.org/licenses/bsd-license.php And you're right, I don't have a big urge to work on it personally any more, I mainly just don't want to have to give up using it, so any new builds would need to still preserve any Columbia-specific (or other site-specific) code that is selected by #ifdefs. - Frank From twp@unchi.org Tue Jul 1 12:47:27 2008 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Tue, 01 Jul 2008 12:47:44 -0400 X-Sieve: CMU Sieve 2.3 Received: from longan.cc.columbia.edu (longan.cc.columbia.edu [128.59.28.165]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id m61Gliww028133 for ; Tue, 1 Jul 2008 12:47:44 -0400 Received: from prod-mail-xrelay03.akamai.com (prod-mail-xrelay03.akamai.com [72.247.150.167]) by longan.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m61Glcud028430 for ; Tue, 1 Jul 2008 12:47:43 -0400 (EDT) Received: from prod-mail-xrelay03.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 329E510000B9 for ; Tue, 1 Jul 2008 16:47:38 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (unknown [63.116.109.131]) by prod-mail-xrelay03.akamai.com (Postfix) with ESMTP id 236F710000AE for ; Tue, 1 Jul 2008 16:47:38 +0000 (GMT) Received: from yclept.kendall.corp.akamai.com (yclept.kendall.corp.akamai.com [172.16.24.197]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id CFE06100008D for ; Tue, 1 Jul 2008 16:47:37 +0000 (GMT) Message-ID: <486A5F9F.5080409@unchi.org> Date: Tue, 01 Jul 2008 12:47:27 -0400 From: Tim Pierce User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: Frank da Cruz Subject: Re: MM 0.91 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 () CU_RE X-Scanned-By: MIMEDefang 2.63 on 128.59.28.165 Ooh, I didn't see the releases under your home directory. I'll download those and give them a whirl -- thanks. Frank da Cruz wrote: >> I just learned that a new release of MM was issued in 2002. >> > And a bunch more since then! > >> I'm told that it compiles cleanly on CentOS 4 and that it builds with some >> compiler hiccupage on recent Debian releases. Was very glad to hear it >> and am looking forward to trying it out on Ubuntu. >> > Be my guest! > >> In 1997 I spent about a week porting MM to a GNU-based autoconf >> framework and asked the MM team (whoever was listed as a contact in the >> README file) if Columbia was willing to release MM under some kind of >> open-source license so I could distribute a modified version. I was >> told that if I sent in patches that they would be considered. That >> sounded very nice, but I confess that at that point I doubted any new >> release of MM was forthcoming, so did not bother sending in patches. :-) >> > As you may know, I was the manager of the group that wrote the Unix version > MM (the one we're talking about), and have been using it ever since and in > fact I'm using it right now. Now and then something would come up and I'd > have to make changes so I could keep on using it. Also I really needed to > be able to send and receive 8-bit text (e.g. for Spanish) so I put some > work into that. > > At the same time, Nelson Beebe at the U of Utah "modernized" the code so it > would be portable to most current Unix OS's. > > Then in 2005-06 when the mail delivery method here was about to change, I > had to adapt to using POP to fetch new mail, rather that simply noticing > that it had magically appeared in a spool directory. (I did NOT add IMAP > support because I didn't need it or want it, but maybe somebody else will > want to do that.) > > Finally, I reconciled my sources with Nelson's. Here is the story, with > links to the current source code: > > http://www.columbia.edu/~fdc/mm/ > >> If I were to make MM and CCMD buildable under autoconf, is that work >> that would interest you or anyone else at Columbia? I'm not promising >> to do it, but I'm more likely to be motivated to do it if I think that >> someone may find it useful. >> >> And if you're trying desperately not to be the MM maintainer, don't >> worry, just say so and I won't bug you again, I promise. >> > Well, take a look at what's been done since you last looked. As to putting > it under an Open Source license, I would say sure, why not, as long as it's > not GNU. Something simple like Berkeley: > > http://www.opensource.org/licenses/bsd-license.php > > And you're right, I don't have a big urge to work on it personally any more, > I mainly just don't want to have to give up using it, so any new builds > would need to still preserve any Columbia-specific (or other site-specific) > code that is selected by #ifdefs. > > - Frank From jfriar@columbia.edu Thu Oct 2 23:16:42 2008 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Thu, 02 Oct 2008 23:17:17 -0400 X-Sieve: CMU Sieve 2.3 Received: from calabash.cc.columbia.edu (calabash.cc.columbia.edu [128.59.28.168]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id m933HF83013725; Thu, 2 Oct 2008 23:17:15 -0400 Received: from ricotta.cc.columbia.edu (ricotta.cc.columbia.edu [128.59.59.57]) by calabash.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m933GjV6001568; Thu, 2 Oct 2008 23:16:45 -0400 (EDT) Received: from ricotta.cc.columbia.edu (localhost [127.0.0.1]) by ricotta.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m933GiBI009056; Thu, 2 Oct 2008 23:16:44 -0400 (EDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by ricotta.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m933GhRD009052 for ; Thu, 2 Oct 2008 23:16:43 -0400 (EDT) Received: from [192.168.1.4] (cpe-66-108-253-226.nyc.res.rr.com [66.108.253.226]) (user=jf659 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m933Gg1u004863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 2 Oct 2008 23:16:42 -0400 (EDT) From: John Friar III To: service-alerts@columbia.edu Date: Thu, 02 Oct 2008 23:16:42 -0400 Message-Id: <1223003802.3845.26.camel@bender.thoughtbit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.28.168 X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Subject: [Service-alerts] Cyrus POP3 Outage X-BeenThere: service-alerts@lists.columbia.edu X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: service-alerts-bounces@lists.columbia.edu Errors-To: service-alerts-bounces@lists.columbia.edu Due to a software error, the Cyrus email servers rejected POP3 email connections between 9:13pm - 10:13pm. Approximately 425 POP3 users received connection errors during this time (including automated devices like gmail and cell phones). Users connecting via IMAP were not affected by this problem. -John -- John Friar CUIT Unix Systems _______________________________________________ service-alerts mailing list service-alerts@lists.columbia.edu https://lists.columbia.edu/mailman/listinfo/service-alerts From brennan@columbia.edu Tue Oct 14 11:45:50 2008 Flags: 000000000001 Return-Path: Received: from liverwurst.cc.columbia.edu ([unix socket]) by liverwurst.cc.columbia.edu (Cyrus v2.3-alpha) with LMTPA; Tue, 14 Oct 2008 11:46:55 -0400 X-Sieve: CMU Sieve 2.3 Received: from gorgonzola.cc.columbia.edu (gorgonzola.cc.columbia.edu [128.59.28.174]) by liverwurst.cc.columbia.edu (8.13.1/8.13.1) with ESMTP id m9EFkqq3002033; Tue, 14 Oct 2008 11:46:53 -0400 Received: from ricotta.cc.columbia.edu (ricotta.cc.columbia.edu [128.59.59.57]) by gorgonzola.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9EFkJ6R018432; Tue, 14 Oct 2008 11:46:20 -0400 (EDT) Received: from ricotta.cc.columbia.edu (localhost [127.0.0.1]) by ricotta.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9EFk6mZ020635; Tue, 14 Oct 2008 11:46:06 -0400 (EDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by ricotta.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9EFk6jw020631 for ; Tue, 14 Oct 2008 11:46:06 -0400 (EDT) Received: from sodor.cc.columbia.edu (sodor.cc.columbia.edu [128.59.39.201]) (user=brennan mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9EFk3mJ022890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 14 Oct 2008 11:46:05 -0400 (EDT) Date: Tue, 14 Oct 2008 11:45:50 -0400 From: Joseph Brennan To: service-alerts@columbia.edu Message-ID: <408455CE4E548F8879BEDB28@sodor.cc.columbia.edu> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.28.174 X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6 Subject: [Service-alerts] SMTP server updates X-BeenThere: service-alerts@lists.columbia.edu X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: service-alerts-bounces@lists.columbia.edu Errors-To: service-alerts-bounces@lists.columbia.edu On Wednesday morning October 15 the following changes will be made on the columbia.edu SMTP servers: - The maximum message size will be increased from 30 megs to 60 megs - .forward files will never be checked - Notice will be sent when messages have been queued for 4 hours - Up to 100 hops will be allowed Discussion: While email is a very inefficient way to transfer large files, we are able to accommodate messages larger than 30 megs. On typical recent days there were about 15 messages in the range 30 to 60 megs. 60 megs corresponds to an attached file of about 45 megs. Attachments have to be encoded to push them through a system designed only for text, and the encoding makes them about 30% larger. The Cubmail web client still has a limit of 10 megabytes (sending mail) because upload is slow. At the present time no users or service accounts have effective .forward files, so the change has no effect except to simplify our configuration and make it easier to diagnose routing errors. Mail is queued and re-tried for up to 5 days. Almost all messages are sent within 4 hours; in fact almost all within 1 second. The 4-hour notice is for the sender's information. There is no action the sender can take. The new SMTP standard (RFC 5322) recommends allowing 100 hops. A hop is a transmission from one host to another, each one recorded in a "Received" header line. They are counted to detect loops, as for example when two addresses forward to each other. As email systems have become more complex, in some cases normal message delivery has been approaching the old typical setting of 25 hops. Joseph Brennan Lead Email Systems Engineer Columbia University Information Technology _______________________________________________ service-alerts mailing list service-alerts@lists.columbia.edu https://lists.columbia.edu/mailman/listinfo/service-alerts