Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!uakari.primate.wisc.edu!caesar.cs.montana.edu!ogicse!schaefer From: schaefer@ogicse.ogc.edu (Barton E. Schaefer) Newsgroups: comp.mail.mush Subject: Re: **WARNING** Mush 7.0.0 scrambles mailbox Message-ID: <6200@ogicse.ogc.edu> Date: 15 Dec 89 19:31:29 GMT References: <8912151519.AA05853@xenna.Xylogics.COM> Reply-To: schaefer@ogicse.UUCP (Barton E. Schaefer) Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR Lines: 139 In article <8912151519.AA05853@xenna.Xylogics.COM> loverso@Xylogics.COM (John Robert LoVerso) writes: } [I] have about 450 peices (1.1MB) of mail (some unanswered) in my } maildrop. This morning I was doing to do my monthly cleaning and } see if I can get that number down a bit. When I went back to } message 1, I found that chunks of recent mail (from last week) had } been overlayed onto the beginning of my maildrop - leaving me with } bits and pieces of those messages. This is not good! Some more details, please -- is this before or after an update? (If before, something in the temp file handling is getting confused; if after, then the problem is with writing back to the folder and is even more serious.) Are you using any kind of NFS mounting of your "maildrop"? What sorts of things did you do (sorting, deleting, how many updates, etc.)? Did new mail arrive while you were working? Incidentally, I ran 7.0.1 just now on a 500 message folder amounting to more than 2MB, randomly deleted about 200 messages with assorted "pick" commands, read several other messages, and updated, with no problems. } 1. File completion is too verbose } } In particular, it expands "+" into the pathname of my folder directory, I presume you're complaining about file listing, e.g. with ^D, not just completion. Listing is verbose because it's much more powerful than (say) csh ^D listing -- you can list any globbing pattern, not just the files in a particular directory. Csh ^D displays only the file names, not the preceding path; but what confusion there would be if you typed */*/*^D and got only the "tail" of every path that was generated! Even removing common prefixes is insufficient, because you still might chop off something that was generated by the glob pattern, leaving the user with no idea where the listed files really are. I will look into special-casing to csh-like behavior when there is no glob pattern at all. } Actually, to be more specific, typing +^D just says "/u6/loverso/Mail/" - } I need to type +/^D to get it to list out the individual folders. This } is misleading, because +foo^D lists folders that start with +foo - no "/" } is required. This in intentional. In effect, "+foo" expands to "$folder/foo" but "+" expands only to "$folder". You have to type ~/^D to list files in your home directory; that's the analogy on which listing with +/^D is based. +/foo^D will work, too, so I don't see how the / is "misleading". The reason the / appears at the end of "/u6/loverso/Mail/" has to do with the expansion of "+" by routines that have been around far longer than globbing and completion, and which were too well entrenched to revise. } Additionally, I have many subfolders (over 250 in several levels of } subdirectories). At the minimum, it would be useful to have directories } listed with a trailing "/" on them. This was considered but rejected because it requires a stat() on every file in the listing. On many systems, this would cause a very noticable slowing of the completion routines. } I've looked at the completion code and its very simple (and clean!). Thank you. :-) } Lastly, completion doesn't work for "~w" et al in compose mode. This statement is just plain wrong. Completion works in compose mode. In fact, it works ANYWHERE in compose mode, so don't bind your completion characters to things you habitually type in messages. There DOES have to be a space between the "~w" and whatever you are completing, or mush will try to find a file in your home directory (~) whose name begins with "w" .... } 2. Including headers in forwarded mail } [ In some cases I ] } just want minimal headers included with ~I; I can do this by settin } alwaysignore. However, to get all the headers, I need to unset } this variable. This is a little clumsy. } } I tried to make a map! to handle it, but found map!'s can match } initial newlines (I only want the `command' recognized at BOL). I handle this sort of thing by mapping a control character (somthing not usually typed, like ^F) to newline/tilde-command/newline, e.g. map! \CF '\n~:unset alwaysignore\n~I\n~:set alwaysignore\n' You can leave off the leading "\n" if you're confident you'll only be typing it at the beginning of a line. } 3. From: line handling } I need to change my `From:' at my discretion at certain times. I know } who I am - why do I need to prove it to Mush? If I fill in a From: } line that has my address in a different domain, it tosses it out } (silently). I don't want Mush changing this at all. Put your other selves in the "alts" list; mush will allow the From: line to contain any of your alternate selves, as long as you've told it about them. } For that matter, Mush needn't supply a default From: line nor a default } Date: at all. My MTA does it for me. Perhaps a SMART_MTA define might } be in order? PICKY_MAILER covers this. } BTW, in the BUGS section of the manaul page, comment about "edit_hdrs" } and changing the From: line is out of date. It's not in the BUGS section, but I found it and corrected it. Thanks. } 4. Forwarding vs. resending } I'm butting up against the "resent" mail restriction again. I.e., } if you "mail -f" and never take the message into an editor, the } message goes out as "resent" mail, in which "resent-" headers are } generated. This loses if you have auto_edit set. It "loses"? If by this you mean that -f ignores $autoedit, then I guess that's a loss. Or do you mean that you have no choice of NOT getting autoedit behavior with "mail -ef"? That complaint I could understand, though an editor is required to add anything above a such a message. Why not cmd resend "mail -f" cmd forward "mail -ef" } Note that the "mail" command now has a "-U" switch, it would be nice } if "mail -f" didn't assume this; i.e., the current "mail -f" behavior } would be replaced by "mail -fU". I'll file the suggestion for discussion with Dan. -- Bart Schaefer "Miserable miscreant! Question MY integrity, will you?" "I have to see some *evidence* of it before I can question it." -- Calvin & Hobbes schaefer@cse.ogi.edu (used to be cse.ogc.edu)