Re: MUA statistics
iain truskett wrote: [snip] So, a quick analysis of the stats produces: 12182Mutt 21756Microsoft Outlook Express 31396Mozilla 41336eGroups 51123Internet Mail Service 6948 Microsoft Outlook 7577 QUALCOMM Windows Eudora 8363 Messenger 9225 KMail 10187 Pluto 11148 ANT RISCOS Marcel 12145 Gnus I don't think too many people here will have trouble with those results. I am inclined to think you have a bug... I cannot believe ALL those mutts but ZERO occurrences of elm and pine. Stan
Re: timestamp of mailbox file is not updated
Mutt's current behavior is consistent with elm and other mailers. This is traditional mbox behavior. I happen to like it. Great! Developers, will you change it then? :-) I hope not. There is no need to have the mtime to be updated every time the ctime is updated. (Or, if there is such a need, maybe make a new variable touch_folder_upon_delete or something, with a default of no.) If you have a tool that really needs to see if a file has been altered, it merely needs to look at the ctime rather than the mtime. This is safest behavior, since user programs *can't* set ctime by themselves. (You can check ctime with ls -lc.) Backups and similar programs already need to look at the ctime rather than the mtime anyway, in order to pick up files that have been renamed or moved. Cheers, Stan
Re: Mutt's URL support
At 04:49 PM 9/11/00 -0500, David McNett wrote: -r-xr-xr-x 1 root wheel 1047184 Sep 11 11:31 /usr/local/bin/lynx -r-xr-xr-x 1 root wheel 321608 Jun 4 19:06 /usr/local/bin/links -r-xr-xr-x 1 root wheel 261132 May 22 08:10 /usr/local/bin/w3m This is reason enough for me to prefer w3m for the specific case we're discussing. Table support or no, it's hard to justify the size of lynx for what the original poster wants to do. The byte size of the executable is only peripherally related to the running size of a process. There might well be symbol tables included in some of those but not others, for example. "size" will give a better estimate of what memory will be used when the process is launched. However, since memory may be dynamically allocated, you need to do something like "ps -el" on a running process to see what the actual memory footprint is. OT I have to say, I'll be permanently against "links" because of the choice of name obviously designed to cause confusion with "lynx". /OT really-OT (If size matters so much, I wonder why so many people write perl scripts when (g)awk and/or sed would do the same jobs in a much smaller way.) /r-OT Stan
Re: not quoting signatures on reply
Peter Palfrader wrote:
...
but this should work for all editors (that support +lineno):
set editor="vim +\`awk '/^$/ {print i+2; exit} {i++}' %s\` %s"
It is stolen from Roland Rosenfeld's [EMAIL PROTECTED] great
muttrcs.
Or even better, use the builtin awk variable NR:
set editor="vim +\`awk '/^$/ {print NR+1; exit}' %s\` %s"
Cheers,
Stan
Re: Automatic mail archiving
At 05:26 AM 7/26/00 +0200, Christian Ordig wrote: ... hmmm... do you really want to solve this with mutt? I suppose you're using procmail for delivering your mail into different mailboxes, aren't you? remember procmail can expand Shell expressions when interpreting its config. so why don't use a foldername like folder-`date %m-%Y`/ so every month's mail would be sorted into the month's folder. This sort of thing has been gone over on the procmail mailing list every so often. (A good place to ask about stuff like this.) The best way is not to run the "date" program with every email, but rather extract it using the match operator \/ from the "From " header. Cheers, Stan
Re: How can I display most X- headers but not all
At 11:11 AM 7/25/00 +0530, Suresh Ramasubramanian wrote: Russell Hoover proclaimed on mutt-users that: ignore * # This means "ignore all header lines by default." unignore From: Date Subject To Cc Organization Organisation User-Agent \ X-Mailer X- ignore X-Priority X-MSMail-Priority Hmmm... once you've gone and unignored it, you can hardly ignore it again ;) There might be reasons for wanting to... ignore A unignore AB ignore ABC unignore ABCD ignore ABCDE ... is pretty hard to do another way :-) Or, it might be useful to make some sourced files work out correctly. Stan
Re: Mail-Followup-To and Reply-To
At 11:55 PM 6/29/00 +0300, Mikko Hänninen wrote: [...] I'm also not aware of whether there is any specified way to have Reply-To set to more than one address. You can either have multiple Reply-To headers, one address per header, or you can have multiple addresses in one header. I think that in either case, the behaviour of MUAs is unspecified, so you may and will get random results. Does anyone know more about this? It's perfectly fine, and has been since at least RFC-822 (1982). Of course, that doesn't mean that there aren't broken MUAs out there... Cheers, Stan ps - your post said Reply-To you, but MFT the list and Hugo. What should that combination mean, I wonder?
Re: Suggestion: aka command
At 10:35 AM 6/21/00 +0100, Telsa Gwynne wrote: On Wed, Jun 21, 2000 at 01:00:47AM -0400 or thereabouts, David T-G wrote: Daniel -- I, for one, had trouble following your aka proposal. I did, also. I know this sounds silly, but was Daniel actually looking for the 'alias' setting? Unfortunately I deleted the original post, but I'm pretty sure that it was something like: Given, in some situations (such as replying), what would be: [EMAIL PROTECTED] Convert (via this aka thing) to produce the header: To: Joe Cool [EMAIL PROTECTED] in otherwords, fill in the "unneeded" part of the address. Maybe I just need more explanation... Yeah, I'm guessing a bit, too :) This is sort of a guess as well, since I'm going from memory, but what I think was asked. Stan
Re: mac-binhex40 encoding
At 09:09 PM 1/5/00 -0500, Andrew J. Schorr wrote: Can anyone tell me how to handle a MIME attachment that was encoded using BinHex 4.0? I received an e-mail containing several JPEG photos that were attached as follows: [snip] Content-Type: application/mac-binhex40; name="putin4.jpg" Content-Disposition: attachment; filename="putin4.jpg" (This file must be converted with BinHex 4.0) :#R"eG'PZ0#jUF'F!5P"4dT@9e)!%Ld!X)Mrf2rJ!""+4NP'!!%"!!! [snip] Is there any way of configuring the mailcap file to handle such an attachment automatically? And where does one find a BinHex 4.0 decoder that runs on Solaris and/or Linux? Is uudeview the best bet (I found it on freshmeat.net)? Furthermore, does anybody have any idea why somebody would send photos this way? The message includes the following header line: X-Mailer: Windows Eudora Light Version 1.5.4 (32) The sender of the message is not a sophisticated user. Does anybody know why Windows Eudora would send the file this way? OK, at the moment I am sending this from Eudora 2.2 (32) which is vintage 1995 or so. Still works, Y2K and all. Under "options", for attachments, there are three: MIME BinHex Uuencode as well as a separate choice for whether to include the "attachment" within the message or not. Testing, the MIME choice yields octet-stream, using BASE64 encoding, probably the stuff you can easily handle. BinHex gives exactly the type of stuff that you showed, including the "mac-binhex40". Or perhaps he was just forwarding it from somebody else... Or perhaps he has an options menu and never bothered (or knew) to set it to something else. (I say "perhaps" because Eudora Light is the free version, lacking some features.) Hopefully, you can get him to set it more usefully. Can't help you with how to de-BinHex stuff on Solaris though. Cheers, Stan
Re: mutt, folders procmail
At 05:21 PM 12/11/99 +1100, Craig McVean wrote: Hi to all muttets? I have mutt working quit well Except my .procmailrc is not placing all my mailing lists into theire own mailboxes mutt-users is working nicely. [snip] I'm using Maildir should i be using mbox as my mailbox type? My machine is standalone. and i'm not very puter smart. I believe only the very newest procmail versions (recently released) handle maildir. You may need to upgrade. i have the lists in my muttrc and thats working well. my mbox is getting messy please HELP I'm subscribed to debian-user, gimp-user, and fetchmail-freinds in a vain hope of trying to work it all out :) You might try the procmail list for procmail help! :-) Subscribe at [EMAIL PROTECTED] as noted in the man page on procmail. That's probably a better list than any of the others to get help with procmail. Hope that helps, Stan
Re: bounce and delivered-to line
At 03:07 PM 8/20/99 +0200, Vincent Lefevre wrote:
On Fri, Aug 20, 1999 at 04:40:40 +0300, Mikko Hänninen wrote:
[snip]
Maybe a quick hack would be best here, like writing a script that
would first remove the Delivered-To header and then remail it
manually (eg. "grep -v ^Delivered-To:" piped to qmail-inject with
Well, grep isn't OK, as a Delivered-To: line may also appear in the body,
and it must not be removed.
When grep isn't quite good enough, consider awk. In this case, you
could filter with, for example:
awk 'x{print;next} /^Delivered-To:/{next} /^$/{x=1} {print}'
If you need to worry about continued header lines (it doesn't seem
likely that Delivered-To: would get that long though), then formail
is probably the way to go.
Cheers,
Stan
Re: additional flags
At 11:39 PM 7/2/99 -0600, Kim DeVaughn wrote: [snip] I have a patch that I absolutely could not do without that may be of interest to you. Originally by Sean Ahern, I refer to it as the "flag_text" patch. It allows *you* to add an arbitrary string to any message, which gets stored in an X-header line (so it doesn't work with mh-style mailboxes, or probably other similar style boxes). It allows you to have an index something like: [snip] 22 !info Jul 02 Nathan Stratton ( 32) Re: Showing threads [snip] where the width of the "text_flag" is user definable (with an appropriate pair of macros, the display can be toggled between showing and not showing that field, if one needs to narrow the display, so that more of the subject field is visible, etc). [snip] Then there is the matter of coming up with a scheme to make it work with mh/etc mailboxes ... /kim I love it. My fear is that there may be no way at all with IMAP though, and that's where I'd most find a use for it. Anyone know if IMAP supports any calls to add headers to stored messages? Cheers, Stan
Re: Unfriendly terminal behaviour
At 11:14 AM 6/7/99 -0700, Jeremy Chadwick wrote: Having to go through and manually remove all these spaces, even in vi, is a tedious process and should not have to be done at all. I won't address mutt/slang here, but removing all trailing blanks in vi is hardly tedious: :%s/ *$// If that's too much, you can map it to a single key, for example K: setenv EXINIT=':map K :%s/ *$//^M' (you need to put a "real" control-m in there). Cheers, Stan
Re: Unfriendly terminal behaviour
At 10:47 AM 6/13/99 -0700, Jeremy Chadwick wrote: On 06/13/1999 (13:27:37), [EMAIL PROTECTED] wrote: At 11:14 AM 6/7/99 -0700, Jeremy Chadwick wrote: Having to go through and manually remove all these spaces, even in vi, is a tedious process and should not have to be done at all. I won't address mutt/slang here, but removing all trailing blanks in vi is hardly tedious: :%s/ *$// If that's too much, you can map it to a single key, for example K: setenv EXINIT=':map K :%s/ *$//^M' (you need to put a "real" control-m in there). You obviously did not read the thread. You obviously cannot tell whether I read it or not. I decided not to address the parts already addressed or which my addressing would be pointless in light of my limited knowledge of slang and no environment comparable to yours to play with it in. This is not about trailing blanks in input lines or entered text. This is about DISPLAYED lines via ncurses/slang. It has nothing to do with vi, nor keymaps, nor anything related to the sort. You are the one who brought up the prospect of removing trailing spaces in vi and called it "tedious." See above. (Your context was cutting and pasting the DISPLAYED lines.) I still have yet to receive two things: * An answer to why if this problem has been around for such a long time (and has been discussed before), that why a solution hasn't been provided. I believe it hasn't been provided here because it's been pointed out to be a slang problem. * An actual solution to the problem. I believe it was suggested that a slang upgrade is available, complete with URL. http://www.s-lang.org in case you didn't get that post by rfi from Rich Roth. I don't know whether that upgrade is the solution to this problem or not. Cheers, Stan
messed-up mutt-users headers
Sorry for a bit of metadiscussion, but has anyone else noticed that sometimes we get a few of the list headers moved inside the message? For example: How do I include "" (literal quotes) in a string in muttrc which has to be delimited with "" ? Sender: [EMAIL PROTECTED] Precedence: bulk I notice this because I've been sorting the list mail based on the "Sender:" header, and the header "disappears" when moved into the message body in this manner, causing it to mis-sort. In the three undeleted examples I've still got, the following characteristics apply to all: - The moved headers are Sender: and Precedence: (as above). - The moved headers appear at the end of the first paragraph of the message body. - The message headers now contain a new "Precedence: list" (instead of "Precedence: bulk"). - The message headers all seem to contain: X-Mailer: ELM [version 2.3 PL11] for OS/2 Thanks, Stan
