Header cache patch and searching through multiple mailboxes
[ Dire-Warning: this is a proof of concept script, it works for me on my
system. Other than that I can't say, except that it requires a
development version of mutt and a patch that is labelled by it's author
as "broken"... ]
I have about 50,000 messages in a couple of dozen nfs mounted Maildirs
(all the old stuff is in mbox archives) - Searching all this mail is a
big drag, since mutt can't 'limit' across multiple mailboxes and
grepping through all this junk can take hours.
Michael Elkins' header cache patch is an experiment in speeding up
access to Maildirs by scattering db files everywhere - I have the idea
that eventually these db files can speed-up searching as well.
This script can search those 50,000 email headers and populate a
temporary results folder containing 3,000 messages in about 40 seconds.
It's an *extremely* blunt instrument, but I hope it will inspire
somebody else to write something a bit more elegant and precise.
It can be called with a macro, though you have to switch to the
'=search-results' folder to see the results:
macro index \cL 'search-maildir.pl '
It takes a single perl-regex argument, which it matches against
everything, sort-of like these:
[EMAIL PROTECTED]
'(Newbie Question|unsubscribe|@yahoo.com|@hotmail.com|BIG5)'
--
Bruno
#!/usr/bin/perl
use strict;
use Fcntl;
use DB_File;
use File::Find;
# This script requires the mutt header caching patch from
# http://www.sigpipe.org:8080/mutt/ NOTE: currently this patch is declared
# broken, so this will probably delete all your files, drink your beer and eat
# your cat. Bruno Postle <[EMAIL PROTECTED]>
# Change these and make sure $resultdir exists as a Maildir, NOTE: this script
# will *delete* all existing files in $resultdir
my $mailfolder = "/home/bruno/Mail";
my $resultdir = "$mailfolder/search-results";
my $pattern = $ARGV[0];
my ( %hash, @folders );
unlink <$resultdir/cur/*>;
find ( { wanted => \&maildirs }, "$mailfolder" );
sub maildirs
{
return unless /hcache\.db/;
return if ( $File::Find::name =~ /$resultdir/ );
my $maildir = $File::Find::name;
$maildir =~ s/\/hcache\.db//;
push @folders, $maildir;
}
foreach ( @folders )
{
my $x = tie %hash, "DB_File", "$_/hcache.db"
or die "Cannot open $_/hcache.db: $!\n";
find ( { wanted => \&messages }, "$_" );
undef $x;
untie %hash;
}
sub messages
{
return unless /:/;
my $uid = $File::Find::name;
$uid =~ s/.*\/([^\/]*):.*/${1}/;
if ( $hash{$uid} =~ /$pattern/i )
{
link ( "$File::Find::name", "$resultdir/cur/$uid:2,S" );
}
}
1;
how much CPU?
I have one mailbox that has A LOT of messages in it, as in quite a few thousand. It is in mbox format. For mutt to open it as quickly as possible, it is dependent on processor speed? I moved my mail to a friend's server which has some really old hardware, and it takes a long time to open this mailbox, plus a few times it has simply stopped while opening it and I had to kill off the mutt process and open it again. Thanks. -Ken
Re: available MDA's: are you satisfied?
* Cameron Simpson ([EMAIL PROTECTED]) wrote: > On 09:43 26 Jan 2002, Prahlad Vaidyanathan <[EMAIL PROTECTED]> wrote: > > On Fri, 25 Jan 2002 Mathias Gygax spewed into the ether: Holy crap > > !! How do you cope ? I can't even manage the 200-250 mails I get > > everyday :-) > > Much as I do I guess - spread it across several folders (not > one-per-list; I put several UNIX/Linux/SOlaris etc lists into one > big "unix" folder) Ugh, not sure I could handle that. I like having fine-grained control over what I read :) > and some lists you only visit sporadicly. Read in threaded mode. Be > aggressive with the delete-thread key, reading only the interesting > threads. I have a default limit set to only show new mail; reading mail involves scanning the folder's subjects once, and when I leave it, the old mail gets hidden and after about a week, archived. Even busy lists only take a few seconds to scan using PageUp. I get about 750 mails a day, and this setup works fine to keep on top of my mail without having it take hours to read it. 90% of my time in mutt is probably in vim editing replies :) -- Thomas 'Freaky' Hurst - [EMAIL PROTECTED] - http://www.aagh.net/ - Fat people of the world unite, we've got nothing to lose!
Re: how much CPU?
On Sun, Jan 27, 2002 at 07:49:54AM -0800, Ken Weingold wrote: > I have one mailbox that has A LOT of messages in it, as in quite a few > thousand. It is in mbox format. For mutt to open it as quickly as > possible, it is dependent on processor speed? I moved my mail to a It's dependent on a lot of things: hard drive speed, processor speed, and memory. IE: all those hardware issues. I'd suggest using Maildir instead of mbox -- my experience has been that Maildir is faster. There's much less to worry about in parsing a Maildir entry -- every file is one message and starts with headers. There's more fh opening and closing, to be sure, but you may find it faster. Give it a try. -- rjbs msg23863/pgp0.pgp Description: PGP signature
Re: Don't mention MUAS to fight html email
* David T-G ([EMAIL PROTECTED]) wrote: > Off-topic meandering: > I think it would be lovely to automatically compress all email before > sending and have it opened on the other end, Gzip your message body and you'll probably find half of mutt-users have it decompressed and viewed automatically :) > but that not only gets into more MIME types (I think it could be > done pretty easily but haven't played with it, and certainly haven't > thought about the troubles of, say, searching within a compressed mail > body) That would make tools like grep pretty useless. > but also costs processing power to package up and then open up > the item. For those on a dialup link, though, it could be a real > blessing. I think it would be rather better for them if they could grab their entire mailspool gzipped; most of the time it takes to download email from a pop3d is taken up by the 'list messages, get message 1, read message 1, delete message 1, get message 2, read message 2, delete message 2...'. With each command taking upwards of 0.2s to get there and back, being able to just request 'give me all the messages you have then delete them' would speed things up no end. -- Thomas 'Freaky' Hurst - [EMAIL PROTECTED] - http://www.aagh.net/ - There's a whole WORLD in a mud puddle! -- Doug Clifford
Re: how much CPU?
At some point hitherto, Ricardo SIGNES hath spake thusly: > It's dependent on a lot of things: hard drive speed, processor speed, > and memory. IE: all those hardware issues. Much more drive speed and memory than cpu though, most likely in that order unless your mailboxes are HUGE and the amount of available RAM is TINY. > I'd suggest using Maildir instead of mbox -- my experience has been that > Maildir is faster. That's really funny since we just had a very large thread here where it was discussed rather at length that mailder is considerably slower when opening mail folders than mbox. Like on the order of 1000% slower or more... Many cases of anecdotal evidence were provided in support of that, and zero cases were provided that support maildir being faster for opening mailboxes than mbox. > There's much less to worry about in parsing a Maildir entry -- every > file is one message and starts with headers. That's precisely what makes maildir slower... there's substantially more overhead in opening many small files than one large one. It performs better on fast hardware with particular filesystems, but in all cases discussed (that I can recall, anyway) maildir was slower. I suggest you read the archives and look at the thread entitled "maildir over mbox?" for the details. -- Derek Martin [EMAIL PROTECTED] - I prefer mail encrypted with PGP/GPG! GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu Learn more about it at http://www.gnupg.org msg23865/pgp0.pgp Description: PGP signature
Re: how much CPU?
On Sun, Jan 27, 2002 at 11:30:04AM -0500, Derek D. Martin wrote: > At some point hitherto, Ricardo SIGNES hath spake thusly: > > It's dependent on a lot of things: hard drive speed, processor speed, > > and memory. IE: all those hardware issues. > > Much more drive speed and memory than cpu though, most likely in that > order unless your mailboxes are HUGE and the amount of available RAM > is TINY. CPU does become important if you're using threading as mutt needs to trawl through the mailbox trying to match up threads. This is further slowed is $strict_threads are unset as it needs to play with $reply_regexp on every message. Useless info: A gui needs to respond with in 0.25 s to feel responsive to a users. -- Benjamin Smith <[EMAIL PROTECTED], [EMAIL PROTECTED]> msg23866/pgp0.pgp Description: PGP signature
Re: how much CPU?
On Sun, Jan 27, 2002, Benjamin Smith wrote: > CPU does become important if you're using threading as mutt needs to > trawl through the mailbox trying to match up threads. This is further > slowed is $strict_threads are unset as it needs to play with > $reply_regexp on every message. In my case it is just when mutt is reading in the messages. -Ken
Re: how much CPU?
So sprach »Ricardo SIGNES« am 2002-01-27 um 11:02:07 -0500 : > I'd suggest using Maildir instead of mbox -- my experience has been that > Maildir is faster. There's much less to worry about in parsing a Maildir Well, saying it so broad as you did, the only answer to this is, that your statement is wrong. On certain filesystems Maildir may be a little faster than mbox, but for example on reiserfs Maildir is tremendously slower in mutt. On ext2 (and also on ext3?), really big Maildirs (not just a few thousand messages though) may make the filesystem run out of inodes. At least I'd think that Maildirs cause more space to be occupied, because every message occupies at least 1 block. That's of course not the case with mbox. Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.iso-top.de | Jabber: [EMAIL PROTECTED] iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 12 days 19 hours 14 minutes
Re: how much CPU?
* Alexander Skwar ([EMAIL PROTECTED]) wrote: So sprach »Ricardo SIGNES« am 2002-01-27 um 11:02:07 -0500 : > > that Maildir is faster. > > Well, saying it so broad as you did, the only answer to this is, > that your statement is wrong. On certain filesystems Maildir may be > a little faster than mbox, but for example on reiserfs Maildir is > tremendously slower in mutt. Maildir may be faster if you know it's going to be cached. It's still likely to be a bit slower on reading, but updates are usually going to be faster. I demonstrated this when I gave cached/noncached examples; while mbox was only slowed down by about 15%, Maildir took over 300% longer to read, but when cached there was barely a 10% difference. For an often accessed working folder on a system with plenty of memory and few users, Maildir will probably have the edge, especially if you're not one of us 700+ message a day weirdo's who keep all their mail :) -- Thomas 'Freaky' Hurst - [EMAIL PROTECTED] - http://www.aagh.net/ - Those who believe in astrology are living in houses with foundations of Silly Putty. -- Dennis Rawlins
Re: html email
Alas! Joel Hammer spake thus: > I thought NT stands for New Technology. MS is always trying to make > their customers forget about the last operating system. I always thought it was "Ne Twerking" because NT is supposed to be so secure for networks or something ;) -- Rob 'Feztaa' Park [EMAIL PROTECTED] -- "Television: A medium. So called because it's neither rare nor well done." -- Ernie Kovacs msg23870/pgp0.pgp Description: PGP signature
Kill mails automaticly
Hello Mutt folks, Is it possible to kill the last oldest messages in Maildir automaticly, for example if mails past 1000 already? -- Joerg Hoehne <[EMAIL PROTECTED]>
Re: Kill mails automaticly
* JASH <[EMAIL PROTECTED]> [020127 17:46]: > Is it possible to kill the last oldest messages in Maildir > automaticly, for example if mails past 1000 already? yes. but mutt won't do this unless you start it yourself. besides of this - mutt is not the tool for this. hint: maildir format + cron + fileutils Sven
Re: how much CPU?
* Ken Weingold <[EMAIL PROTECTED]> [020127 15:55]: > I have one mailbox that has A LOT of messages in it, as in > quite a few thousand. It is in mbox format. For mutt to open > it as quickly as possible, it is dependent on processor speed? no. mutt works independently of procesor speed. actually, it does not need any RAM or disk space. and if you believe that then you'll believe anything. ;-) > I moved my mail to a friend's server which has some really old > hardware, and it takes a long time to open this mailbox, plus > a few times it has simply stopped while opening it and > I had to kill off the mutt process and open it again. check the locking method of mutt and your machine. Sven [using mutt-1.3.27 - opening mutt folder with 39,000+ messges in less than a minute.]
Re: gpg and mutt: "not a detached signature"
At Sat, Jan 26 2002 [22:34 -0500], Ben Logan aroused my curiosity with: Hello Ben :-) > set pgp_sign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor >--textmode --clearsign %?a?-u %a? %f" pgp_sign_command is set to create old-style pgp signatures - for this reason the variable pgp_clearsign_command exists. Change your pgp_sign_command="..." to pgp_clearsign_command="..." and add another line with pgp_sign_command like this one: set pgp_sign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor --detach-sign --textmode %?a?-u %a? %f" ^^^ (this should create a detached sig) Tschoe, Steff
Re: how much CPU?
On Sun, Jan 27, 2002, Sven Guckes wrote: > > I moved my mail to a friend's server which has some really old > > hardware, and it takes a long time to open this mailbox, plus > > a few times it has simply stopped while opening it and > > I had to kill off the mutt process and open it again. > > check the locking method of mutt and your machine. > > Sven [using mutt-1.3.27 - opening mutt folder > with 39,000+ messges in less than a minute.] Hmmm. There may indeed be a locking issue. This is the first time I think I have had to install mutt into my home directory since I don't have root on this machine. What are the issues with mutt_dotlock in this case? -Ken
Discard email on POP server
While discussing the real reasons to fight HTML email, people said: >> Off-topic meandering: >> I think it would be lovely to automatically compress all email before >> sending and have it opened on the other end, > >Gzip your message body and you'll probably find half of mutt-users have >it decompressed and viewed automatically :) >... >> but also costs processing power to package up and then open up >> the item. For those on a dialup link, though, it could be a real >> blessing. > >I think it would be rather better for them if they could grab their >entire mailspool gzipped; most of the time it takes to download email Actually, at least when dealing with many mailing lists, the real problem is that there are whole huge threads that one's could not care less about. And they are NOT spam that a procmail recipe can stop. For example, you have only EIDE disks, and people on your distro list start discussing for days and hundreds of messages how to deal with SCSI ones. In such cases the real solution (to save your time, and at least the bandwidth from the POP server to you) is, for any MUA/OS combination: 1) (as soon as you see an uninteresting thread start) 2) mark it in your MUA so that 3) next time you connect to the POP server 4) all replies are destroyed *instead* of downloaded 5) before fetchmail or whatever you use picks the rest up see http://web.tiscali.it/marco_web/popfilter.html for a simple Perl script and Mutt macros to do this, and give feedback please. Other more sophisticated and more maintained tools for the same purpose are animail, mailfilter and popsneaker (check on Freshmeat) ANy feedback/success story/config file is appreciated. (even partners to develop popfilter further!) Ciao, Marco -- Real leaders are ordinary people with extraordinary determination
Mails received as attachment?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all I just spoke to an Lookout! user who says she's getting my emails as both normally and as an attachment at the same time. This is most strange and confusing. I have the outlook compat patch and as you can see I use $p_c_t so everyone can understand me so why is this happening? Thanks very much - -- Nick Wilson Tel:+45 3325 0688 Fax:+45 3325 0677 Web:www.explodingnet.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE8VHKNHpvrrTa6L5oRAtIaAJ9gE5bMI3IMwTqQl/Dfk2KKEPvpMQCfeAWs yxYWM8qD/iSLyHeNsILgzmM= =+/yU -END PGP SIGNATURE-
Re: Discard email on POP server
... I forgot to say that this method also kills (as they deserve, IMHO) even all messages from those people who just hit reply to say whatever unrelated thing passes through their mind when they should really make everybody's life easier by starting a new thread with a proper new subject. YMMV Marco -- May your campfire always burn bright
[no subject]
I've just recently installed FreeBSD. I've got most all of my mail functioning properly, but I'm having a problem with mutt. When I am in a console, the bottom messages don't appear. For example I enter "q" and at the bottom of the screen is a black spaced indent and then the cursor. No text. If I type "y" mutt quits. I'm using mutt 1.25 and Roland Rosenfeld's .muttrc and setup files icewm-gnome .xinitrc .tcsh Oh, if I'm in X using xterm, there's no color in mutt but I can backspace to delete text. If I'm in rxvt I have color in mutt but can't backspace/delete.
Re: your mail
On Sun, Jan 27, 2002 at 02:08:08PM -0800, Dale Morris wrote: > I've just recently installed FreeBSD. I've got most all of my mail > functioning properly, but I'm having a problem with mutt. When I am in a > console, the bottom messages don't appear. For example I enter "q" and > at the bottom of the screen is a black spaced indent and then the > cursor. No text. If I type "y" mutt quits. It sounds as if your choice of $TERM is resetting colors to black-on-black. > I'm using mutt 1.25 and Roland Rosenfeld's .muttrc and setup files > icewm-gnome > .xinitrc > .tcsh > > > > Oh, if I'm in X using xterm, there's no color in mutt but I can > backspace to delete text. If I'm in rxvt I have color in mutt but can't > backspace/delete. same problem (the terminfo entry tells the application what to expect for backspace - kbs - and delete - kdch1). -- Thomas E. Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: Mails received as attachment?
Hi Nick, the $p_o_c patch sets the header Content-Disposition: inline; filename="msg.pgp" which is why Outlook shows an attachment. There is a patch from Dale Woolridge, which is supposed to take care of this, but I couldn't test it yet. (So little time.) The URL is http://www.woolridge.ca/mutt/patches/patch-1.3.26.dw.pgp-traditional.2 Good luck, Viktor -- Viktor Rosenfeld WWW: http://www.informatik.hu-berlin.de/~rosenfel/ msg23881/pgp0.pgp Description: PGP signature
Re: your mail
Dale Morris wrote: [might be a good idea to use a subject line] > I've just recently installed FreeBSD. I've got most all of my mail > functioning properly, but I'm having a problem with mutt. When I am in > a console, the bottom messages don't appear. For example I enter "q" > and at the bottom of the screen is a black spaced indent and then the > cursor. No text. If I type "y" mutt quits. did you build mutt from ports, or from source? if you built from the ports, you might specify the option to build with ncurses instead of slang. do you mean in the actual console, or in a terminal window? i don't have this problem in either case in a terminal window (usually Eterm) or on the console on my FreeBSD 4.4 machines. Also, my main mail machine is a linux box but I read it from FreeBSD and i don't have this problem here also. if you mean a terminal rather than the actual console, probably you have the wrong $TERM setting. if you're in the console, is $TERM set to cons25? > I'm using mutt 1.25 and Roland Rosenfeld's .muttrc and setup files you might also include mutt -v output, and let us know what $TERM is set to anywhere you have the problem (echo $TERM in bourne derived shells; not sure about csh derived shells, but env | grep TERM will do it). > Oh, if I'm in X using xterm, there's no color in mutt but I can > backspace to delete text. If I'm in rxvt I have color in mutt but > can't backspace/delete. i usually use xterm-color in FreeBSD even though you really shouldn't ever use 'xterm-color' since color 'ls' only works (AFAIK) when $TERM is set to this. on linux, i use xterm-xfree86, or sometimes just xterm. experiment with different TERM settings and terminal programs and see what works for you. personally i find Eterm nicer looking (after you mess with the default colors and stuff) than xterm or rxvt, although it can be a bit of a memory hog. w
Re: your mail
On Sun, Jan 27, 2002 at 02:24:22PM -0800, Will Yardley wrote: > i usually use xterm-color in FreeBSD even though you really shouldn't > ever use 'xterm-color' since color 'ls' only works (AFAIK) when $TERM is > set to this. on linux, i use xterm-xfree86, or sometimes just xterm. xterm-color is always incorrect for xterm and rxvt... (it happens to work if you don't care much about how well). see http://dickey.his.com/xterm/xterm.faq.html#xterm_terminfo color 'ls' ignores the termcap and terminfo databases, btw. > experiment with different TERM settings and terminal programs and see > what works for you. personally i find Eterm nicer looking (after you > mess with the default colors and stuff) than xterm or rxvt, although it > can be a bit of a memory hog. Both (XFree86) xterm and rxvt implement default colors, have done so since long before Eterm was written. (There's no difference, except of course if you're setting $TERM to xterm-color for one of the latter). -- Thomas E. Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: your mail
Thomas Dickey wrote: > On Sun, Jan 27, 2002 at 02:24:22PM -0800, Will Yardley wrote: > > i usually use xterm-color in FreeBSD even though you really shouldn't > > ever use 'xterm-color' since color 'ls' only works (AFAIK) when $TERM is > > set to this. on linux, i use xterm-xfree86, or sometimes just xterm. > > xterm-color is always incorrect for xterm and rxvt... > (it happens to work if you don't care much about how well). > color 'ls' ignores the termcap and terminfo databases, btw. CLICOLOR Use ANSI color sequences to distinguish file types. See LSCOLORS below. In addition to the file types mentioned in the -F option some extra attributes (setuid bit set, etc.) are also displayed. The colorization is dependent on a terminal type with the proper termcap(5) capabilities. The default ``cons25'' console has the proper capabilities, but to display the colors in an xterm(1), for example, the TERM variable must be set to ``xterm-color''. Other terminal types may require similar adjustments. Colorization is silently disabled if the output isn't directed to a terminal unless the CLICOLOR_FORCE variable is defined. (from the 'ls' man page). in freebsd, colorized ls doesn't work with xterm (ie it will work if you're on a linux machine or something but not on the machine itself). i use Eterm, but haven't had any problems with xterm-color. i know that it's incorrect, but it works for me ok. if anyone knows a better workaround, let me know. w
Re: your mail
On Sun, Jan 27, 2002 at 02:50:16PM -0800, Will Yardley wrote: > Thomas Dickey wrote: > > On Sun, Jan 27, 2002 at 02:24:22PM -0800, Will Yardley wrote: > > > > i usually use xterm-color in FreeBSD even though you really shouldn't > > > ever use 'xterm-color' since color 'ls' only works (AFAIK) when $TERM is > > > set to this. on linux, i use xterm-xfree86, or sometimes just xterm. It's trivial to fix this (FreeBSD's termcap is badly-undermaintained). All you need to do is take the termcap that's part of the xterm distribution, paste it at the front of your /usr/share/misc/termcap, and regenerated the termcap database. Any competant sys-admin can do this. > > xterm-color is always incorrect for xterm and rxvt... > > (it happens to work if you don't care much about how well). > > > color 'ls' ignores the termcap and terminfo databases, btw. I had in mind (having forgotten that FreeBSD has a not-invented-here mentality) that they'd implemented a copy of the GNU 'ls', and didn't consider that they may have fixed one problem while introducing another... > CLICOLOR > > Use ANSI color sequences to distinguish file types. See LSCOLORS > below. In addition to the file types mentioned in the -F option some > extra attributes (setuid bit set, etc.) are also displayed. The > colorization is dependent on a terminal type with the proper > termcap(5) capabilities. The default ``cons25'' console has the > proper capabilities, but to display the colors in an xterm(1), for > example, the TERM variable must be set to ``xterm-color''. Other it's still wrong even if it's in the manpage (I think I'm more familiar with this stuff than the ostensible author of this manpage). > i use Eterm, but haven't had any problems with xterm-color. i know that > it's incorrect, but it works for me ok. you won't get default colors (by anything that relies on the termcap settings). hardcoded programs, of course, are not affected. > if anyone knows a better workaround, let me know. I haven't been counting, but I'm certain I've mentioned it at least once a week for the past year. -- Thomas E. Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net
Re: Don't mention MUAS to fight html email
Thomas -- ...and then Thomas Hurst said... % % * David T-G ([EMAIL PROTECTED]) wrote: % % > Off-topic meandering: % > I think it would be lovely to automatically compress all email before % > sending and have it opened on the other end, % % Gzip your message body and you'll probably find half of mutt-users have % it decompressed and viewed automatically :) Yep :-) % % > but that not only gets into more MIME types (I think it could be % > done pretty easily but haven't played with it, and certainly haven't % > thought about the troubles of, say, searching within a compressed mail % > body) % % That would make tools like grep pretty useless. Well, zgrep takes care of that, too, but it just makes things that much tougher. It would take some front-end work. % % > but also costs processing power to package up and then open up % > the item. For those on a dialup link, though, it could be a real % > blessing. % % I think it would be rather better for them if they could grab their % entire mailspool gzipped; most of the time it takes to download email % from a pop3d is taken up by the 'list messages, get message 1, read % message 1, delete message 1, get message 2, read message 2, delete % message 2...'. With each command taking upwards of 0.2s to get there % and back, being able to just request 'give me all the messages you have % then delete them' would speed things up no end. Hmmm... Not a bad idea. % % -- % Thomas 'Freaky' Hurst - [EMAIL PROTECTED] - http://www.aagh.net/ % - % There's a whole WORLD in a mud puddle! % -- Doug Clifford :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg23886/pgp0.pgp Description: PGP signature
Re: how much CPU?
Ken -- ...and then Ken Weingold said... % % On Sun, Jan 27, 2002, Sven Guckes wrote: % > > I moved my mail to a friend's server which has some really old ... % > check the locking method of mutt and your machine. % > % > Sven [using mutt-1.3.27 - opening mutt folder % > with 39,000+ messges in less than a minute.] Heh. That's cool :-) % % Hmmm. There may indeed be a locking issue. This is the first time I % think I have had to install mutt into my home directory since I don't % have root on this machine. What are the issues with mutt_dotlock in % this case? If your mail is in /var/spool/mail, then mutt_dotlock will need to have special perms -- but mutt should also complain that it can't open the spool for writing. If you own the spool files, permissions are not an issue. Since it's a friend, though, ask her/him to install mutt_dotlock (or, heck, just load up 1.2.5.1 as a full install, since you can use 1.3.27 from your home tree and *not* use your own mutt_dotlock) and never worry about it again. If^WWhen s/he gets turned on to how cool mutt is system updates will be taken care of for you :-) Meanwhile, my personal feeling is that you'll feel it first based on disk type (EIDE will suck), second on available RAM, and distantly third on processor power, and that unless your friend is running ext3 (run "mount" without args to see) you do NOT want Maildir. % % % -Ken :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg23887/pgp0.pgp Description: PGP signature
Re: your mail
Thomas Dickey wrote: [this is getting OT, so it might be nicest to continue this discussion off list if necessary] > I had in mind (having forgotten that FreeBSD has a not-invented-here > mentality) that they'd implemented a copy of the GNU 'ls', and didn't > consider that they may have fixed one problem while introducing > another... is it gnu's ls? it isn't in /usr/src/gnu/bin - it's in /usr/src/bin, and has a standard BSD license at the top. also the options are different in freebsd - it's 'ls -G' not 'ls --color[=]'. > it's still wrong even if it's in the manpage (I think I'm more > familiar with this stuff than the ostensible author of this manpage). perhaps (i'm not being sarcastic), but the fact of the matter is that if i have TERM set to ANYTHING other than 'xterm-color', LS output doesn't show up in color. i don't know any way to prove this, but that's the case. i don't think it has to do with the terminal settngs not being capable. i will try regenerating my termcap database and stuff. i appreciate your (generally helpful) commentary on this list. i do think that perhaps you sometimes assume that other people know more about this stuff than most people actually do. while i like to do things the Right Way, i'm more interested in results; using xterm-color hasn't caused me any problems that bother me, so i'm not overly concerned about it. i will review the documenation on your site; if you have links to any other docs that might be helpful (especially freebsd specific, as their termcap database does seem to be kind of wacky) i'd appreciate those links as well. w
Re: Don't mention MUAS to fight html email
* David T-G ([EMAIL PROTECTED]) wrote: > ...and then Thomas Hurst said... > > Gzip your message body and you'll probably find half of mutt-users > > have it decompressed and viewed automatically :) > > That would make tools like grep pretty useless. > > Well, zgrep takes care of that, too, but it just makes things that > much tougher. It would take some front-end work. Well, gzipped mail content would imply uuencoding or so; zgrep won't work with that :) gzipped mboxes make manipulation problematic, and gzipped individial messages in a maildir is unlikely to save you much more than the odd inode. -- Thomas 'Freaky' Hurst - [EMAIL PROTECTED] - http://www.aagh.net/ - An ounce of application is worth a ton of abstraction.
Re: gpg and mutt: "not a detached signature"
Thanks, that fixed the problem. Ben -- Ben Logan: ben at wblogan dot net OpenPGP Key KeyID: A1ADD1F0 The part of the world that people find most puzzling is the part called "Me".
Re: available MDA's: are you satisfied?
Hi, On Fri, 25 Jan 2002 Roman Neuhauser spewed into the ether: [-- snip --] > I'm slowly getting the picture of the classes that would make this > happen, and would like to ask you: is there something that you sorely > lack in your favorite MDA? What is it? > > Any feedback is much appreciated. Just saw this. Haven't tested it, but I thought it might interest you : http://melkor.dnp.fmph.uniba.sk/~garabik/pycmail.html I might try figuring it out tomorrow. pv. -- Prahlad Vaidyanathan <[EMAIL PROTECTED]> The person who makes no mistakes does not usually make anything. msg23891/pgp0.pgp Description: PGP signature
Re: available MDA's: are you satisfied?
On 16:00 27 Jan 2002, Thomas Hurst <[EMAIL PROTECTED]> wrote: | * Cameron Simpson ([EMAIL PROTECTED]) wrote: | > On 09:43 26 Jan 2002, Prahlad Vaidyanathan <[EMAIL PROTECTED]> wrote: | > > On Fri, 25 Jan 2002 Mathias Gygax spewed into the ether: Holy crap | > > !! How do you cope ? I can't even manage the 200-250 mails I get | > > everyday :-) | > | > Much as I do I guess - spread it across several folders (not | > one-per-list; I put several UNIX/Linux/SOlaris etc lists into one | > big "unix" folder) | | [...] I like having fine-grained control | over what I read :) You're hardly obliged to :-) I just found a hundred folders harder to track. Now I have only about thirty. | > and some lists you only visit sporadicly. Read in threaded mode. Be | > aggressive with the delete-thread key, reading only the interesting | > threads. | | I have a default limit set to only show new mail; I just sort with new at the top, and the colour change tells me when I've reached the older stuff (not yet thrown away). | I get about 750 mails a day, and this setup works fine to keep on top of | my mail without having it take hours to read it. 90% of my time in mutt | is probably in vim editing replies :) I probably get double that I think (past a certain point, who counts?) Still, you're doing better than I with your reading/replying ratio. -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ Every particle continues in its state of rest or uniform motion in a straight line except insofar as it doesn't. - Sir Arther Eddington
aol question
I have FreeBSD and redhat 7.2 running on my athalon machine. On the redhat os I am using sendmail configured using the install-sendmail 5.5 script from freshmeat and on the FreeBSD os I have sendmail installed, but configured just as it came out of the box. Sending mail to myself @yahoo.com works fine (both os's), sending mail to my friend @aol.com seems to bounce on both os's. The aol machine is a new windows xp (yeah, I know it sucks) that she just got. Is there something I have to change in my config files to allow my mail to get through to aol? I've been using sendmail and linux for the last 2 years and not had any problem with her address, but now that I think about it, other aol mails have bounced. I haven't been checking the list closely, apologies if there's a huge thread on this that I'm unaware of.
