Re: [9fans] acme mail on unix
Dave Eckhardt <[EMAIL PROTECTED]> writes | Instead my guess would be something more like: if you're | rebuilding the quota database you can do so by N/M | readdir()'s instead of N/M readdir()'s plus N stat()'s, | which is probably a huge reduction in disk seeks, which | would be attractive since almost everything stat() would | be telling you would be irrelevant (e.g., inode number, | permissions, actual disk blocks consumed). i've heard ken has a solution to this that involves less code. ;-) seriously, how does this make sense for a /user's/ maildir located in the user's home directory? notwithstanding that the very long filenames blow much of the original savings. - erik
Re: [9fans] acme mail on unix
> Do you think it might make it easier to change upas/fs to > not keep the whole mailbox in memory? i sketched out a design for an imap upas/fs last night. it is imap in the sense of intended to be used with an imap server but really that just breaks a handful of the current assumptions. the new design should make it simpler to not keep the mailbox in memory and also to accomodate other mailbox formats. russ
Re: [9fans] acme mail on unix
> (the S=2872 is the file size. i'm not sure why stat is so > expensive on their machine.) I suspect it's *not* because of this: AFS directories are (essentially) whole-file transferred to clients who interpret them locally, but each stat() requires an RPC to the server. Instead my guess would be something more like: if you're rebuilding the quota database you can do so by N/M readdir()'s instead of N/M readdir()'s plus N stat()'s, which is probably a huge reduction in disk seeks, which would be attractive since almost everything stat() would be telling you would be irrelevant (e.g., inode number, permissions, actual disk blocks consumed). Dave Eckhardt
Re: [9fans] acme mail on unix
uriel, my limited time is starting to cause major headaches. i've been working with john cummings on getting upas ready-for-primetime within plan9port. upas/fs has been stable for a long time, but not integrated. perhaps this is silly to worry about, but i'd rather not have a version in contrib if it's not necessiary. russ, would you be willing to integrate the recient p9p upas/fs changes ahead of the rest of upas? i believe that it's ready. these changes will probablly work with plan9 proper. this isn't something i can test right now. - erik [EMAIL PROTECTED] writes | | > [EMAIL PROTECTED] writes | > | > i added mdir support to upas/fs for p9p. it should work | > | > on mh directories, too. | > | Do you think it might make it easier to change upas/fs to | > | not keep the whole mailbox in memory? | > | > yes, i do. but i didn't go that far. | Ah, that is great news! That limitation is one of my main problems with upas/fs. | | > | > this isn't integrated yet, but has worked pretty well for me. | > | What is missing for it to be integrated into the distribution? | > | | > | > set me a note if you'd like me to forward the code. | > | Could you put it in sources/contrib? | > | > i would, but i don't have a directory. | Get one then ;) | | See: | http://plan9.bell-labs.com/wiki/plan9/How_to_contribute/#SOURCES/CONTRIB | | uriel
Re: [9fans] acme mail on unix
> [EMAIL PROTECTED] writes > | > i added mdir support to upas/fs for p9p. it should work > | > on mh directories, too. > | Do you think it might make it easier to change upas/fs to > | not keep the whole mailbox in memory? > > yes, i do. but i didn't go that far. Ah, that is great news! That limitation is one of my main problems with upas/fs. > | > this isn't integrated yet, but has worked pretty well for me. > | What is missing for it to be integrated into the distribution? > | > | > set me a note if you'd like me to forward the code. > | Could you put it in sources/contrib? > > i would, but i don't have a directory. Get one then ;) See: http://plan9.bell-labs.com/wiki/plan9/How_to_contribute/#SOURCES/CONTRIB uriel
Re: [9fans] acme mail on unix
[EMAIL PROTECTED] writes | | > i added mdir support to upas/fs for p9p. it should work | > on mh directories, too. | Do you think it might make it easier to change upas/fs to | not keep the whole mailbox in memory? yes, i do. but i didn't go that far. | | > this isn't integrated yet, but has worked pretty well for me. | What is missing for it to be integrated into the distribution? | | > set me a note if you'd like me to forward the code. | Could you put it in sources/contrib? i would, but i don't have a directory. - erik
Re: [9fans] acme mail on unix
> i added mdir support to upas/fs for p9p. it should work > on mh directories, too. Do you think it might make it easier to change upas/fs to not keep the whole mailbox in memory? > this isn't integrated yet, but has worked pretty well for me. What is missing for it to be integrated into the distribution? > set me a note if you'd like me to forward the code. Could you put it in sources/contrib? uriel
Re: [9fans] acme mail on unix
i added mdir support to upas/fs for p9p. it should work on mh directories, too. this isn't integrated yet, but has worked pretty well for me. set me a note if you'd like me to forward the code. - erik erik quanstrom <[EMAIL PROTECTED]> writes | Dan Cross <[EMAIL PROTECTED]> writes | | | | | On Thu, Jan 19, 2006 at 11:24:36AM -0500, Russ Cox wrote: | | > Eventually I might replace the mh programs with code from | | > Plan 9 (still leaving the mh disk layout) but I don't expect to | | > do that any time soon. | | | | Personally, I'd rather that wasn't the case. I'd rather see a version of | | the MH utilities (or a subset of the useful ones) that know how to deal with | | Maildir or IMAP (given the discrete nature of the MH commands, the latter | | might be hard and/or slow). | | | | - Dan C.
Re: [9fans] acme mail on unix
i'm not sure what you have available in your environment, but you could get around the slow imap connection by running upas/fs, which can be mounted as a normal fs on linux-2.6.n, n>=13. i don't use mh, but your description of an mh directory sounds compatable with the upas/fs layout. i've been running upas/fs for about 2 months against an imap server had have no problems. - erik Dan Cross <[EMAIL PROTECTED]> writes | | On Thu, Jan 19, 2006 at 11:24:36AM -0500, Russ Cox wrote: | > Eventually I might replace the mh programs with code from | > Plan 9 (still leaving the mh disk layout) but I don't expect to | > do that any time soon. | | Personally, I'd rather that wasn't the case. I'd rather see a version of | the MH utilities (or a subset of the useful ones) that know how to deal with | Maildir or IMAP (given the discrete nature of the MH commands, the latter | might be hard and/or slow). | | - Dan C.
Re: [9fans] acme mail on unix
the standard for the top level is $home/.maildir or $home/Maildir (cyrus). you can get away with only working with $MAILDIR/new if you don't have a need for maildir-style folders (which start with a "." and get utf-7- encoded). there is disagreement about the format of the unique.file.name. the cyrus maildir man page says this: A new unique filename is created using one of two possible forms: ``time.MusecPpid.host'', or ``time.MusecPpid_unique.host''. ``time'' and ``usec'' is the current system time, obtained from gettimeofday(2). ``pid'' is the process number of the process that is delivering this message to the maildir. ``host'' is the name of the machine where the mail is being delivered. their maildir files look like this 1136731697.M580106P15382V0303I0009030C_0.conchobor.berzerked.org,S=2872 (the S=2872 is the file size. i'm not sure why stat is so expensive on their machine.) but postfix gives you this: 1137764424.Vfe04I16e1M435392.dexter-peak.quanstro.net and fetchmail gives you this 1125641448.1984_0.dexter-peak i don't use djb's stuff, but i'm sure he disagrees with all of these formats. ;-) i see the important part of the file format to be time "." unique-extension. i wrote a set of programs for reading mail in maildirs (from, mcat, mimedesc, e.g.). they get buy by not paying any attention to the file names. - erik John Barham <[EMAIL PROTECTED]> writes | | > Maildir uses the structure folder/{tmp,cur,new}/unique.file.name. | > The files are required to be uniquely named, and there is a convention for | > the intermediate directories. djb has a brief but detailed specification | > under cr.yp.to somewhere, if you want to google for it. | | http://cr.yp.to/proto/maildir.html
Re: [9fans] acme mail on unix
> Maildir uses the structure folder/{tmp,cur,new}/unique.file.name. > The files are required to be uniquely named, and there is a convention for > the intermediate directories. djb has a brief but detailed specification > under cr.yp.to somewhere, if you want to google for it. http://cr.yp.to/proto/maildir.html
Re: [9fans] acme mail on unix
| MH uses monotonically-increasing small positive integers to number | messages within a folder. Maildir, as I recall, uses large | pseudo-random numbers, or what appear to be pseudo-random numbers. Maildir uses the structure folder/{tmp,cur,new}/unique.file.name. The files are required to be uniquely named, and there is a convention for the intermediate directories. djb has a brief but detailed specification under cr.yp.to somewhere, if you want to google for it.
Re: [9fans] acme mail on unix
MH uses monotonically-increasing small positive integers to number messages within a folder. Maildir, as I recall, uses large pseudo-random numbers, or what appear to be pseudo-random numbers. --- Begin Message --- > On Thu, Jan 19, 2006 at 11:24:36AM -0500, Russ Cox wrote: > > Eventually I might replace the mh programs with code from > > Plan 9 (still leaving the mh disk layout) but I don't expect to > > do that any time soon. > > Personally, I'd rather that wasn't the case. I'd rather see a version of > the MH utilities (or a subset of the useful ones) that know how to deal with > Maildir or IMAP (given the discrete nature of the MH commands, the latter > might be hard and/or slow). What is the difference between mh's layout and maildir? I thought they were the same. Russ--- End Message ---
Re: [9fans] acme mail on unix
> On Thu, Jan 19, 2006 at 11:24:36AM -0500, Russ Cox wrote: > > Eventually I might replace the mh programs with code from > > Plan 9 (still leaving the mh disk layout) but I don't expect to > > do that any time soon. > > Personally, I'd rather that wasn't the case. I'd rather see a version of > the MH utilities (or a subset of the useful ones) that know how to deal with > Maildir or IMAP (given the discrete nature of the MH commands, the latter > might be hard and/or slow). What is the difference between mh's layout and maildir? I thought they were the same. Russ
Re: [9fans] acme mail on unix
On Thu, Jan 19, 2006 at 11:24:36AM -0500, Russ Cox wrote: > Eventually I might replace the mh programs with code from > Plan 9 (still leaving the mh disk layout) but I don't expect to > do that any time soon. Personally, I'd rather that wasn't the case. I'd rather see a version of the MH utilities (or a subset of the useful ones) that know how to deal with Maildir or IMAP (given the discrete nature of the MH commands, the latter might be hard and/or slow). - Dan C.
Re: [9fans] acme mail on unix
> Hey Russ, > I'd love to try out your script - problem is nmh doesn't seem to like > modern-ish utilities (gcc 4 et al). Would you know of any other > utility which would have the same functionality? I would suggest trying to find an earlier gcc or prebuilt binaries. Eventually I might replace the mh programs with code from Plan 9 (still leaving the mh disk layout) but I don't expect to do that any time soon. Russ
Re: [9fans] acme mail on unix
Hey Russ, I'd love to try out your script - problem is nmh doesn't seem to like modern-ish utilities (gcc 4 et al). Would you know of any other utility which would have the same functionality?
Re: [9fans] acme mail on unix
Mail script should be attached. This time for sure. Russ #!/usr/local/plan9/bin/rc . 9.rc . $PLAN9/lib/acme.rc mh=/usr/bin/mh # directory with mh binaries fn event { # $1 - c1 origin of event # $2 - c2 type of action # $3 - q0 beginning of selection # $4 - q1 end of selection # $5 - eq0 beginning of expanded selection # $6 - eq1 end of expanded selection # $7 - flag # $8 - nr number of runes in $7 # $9 - text # $10 - chorded argument # $11 - origin of chorded argument switch($1$2){ case E* # write to body or tag case F* # generated by ourselves; ignore case K* # type away we do not care case Mi # mouse: text inserted in tag case MI # mouse: text inserted in body case Md # mouse: text deleted from tag case MD # mouse: text deleted from body case Mx MX # button 2 in tag or body $x $* case Ml ML # button 3 in tag or body $l $* & } } listfmt='%(msg)/%<(mymbox{from})%<{to}To: %(decode(friendly{to}))%>%>%<(zero)%(decode(friendly{from}))%> %(day{date}) %(month{date}) %(mday{date}) %02(hour{date}):%02(min{date})\n %(decode{subject})' fn boxexec { switch($9){ case Get echo -n , | winwrite addr $mh/scan +^$boxname -reverse -format $listfmt | winwrite data winctl clean case Mail* postwin `{echo $9 | sed 's/Mail *//'} & case * winwriteevent $* } } fn boxload { switch($9){ case [0-9]* msgwin $boxname $9 & case */Mail/* f=`{echo $9 | sed 's;/+$;;'} if(test -d $f){ boxwin $f & } if not if(test -f $f){ echo reloading msg box=`{echo $f | sed 's;/[^/]+$;;'} num=`{echo $f | sed 's;.*/;;'} msgwin $box $num & } if not winwriteevent $* case * winwriteevent $* } } fn cmd { $1 - - - - - - - - $2 } fn boxwin { newwindow boxname=$1 winname $boxname x=boxexec l=boxload cmd $x Get echo -n 'Get Mail ' | winwrite tag wineventloop } fn msgexec { switch($9){ case Get echo -n , | winwrite addr $mh/mhshow -nopause +^$boxname $msgnum | 9 grep -v '^part [0-9]? +text' | 9 fmt -j | winwrite data winctl clean case Mail* postwin `{echo $9 | sed 's/^Mail *//'} & case Reply* postwin `{echo $9 | sed 's/^Reply *//'} & case Delmesg if(~ $boxname */*){ x=`{echo $boxname | sed 's;.*/;;'} $mh/refile -src +$x $msgnum +d winctl del } case Spam if(~ $boxname */*){ x=`{echo $boxname | sed 's;.*/;;'} $mh/refile -src +$x $msgnum +spam winctl del } case * winwriteevent $* } } fn msgwin { newwindow boxname=$1 msgnum=$2 winname $boxname/$msgnum shift shift x=msgexec l=boxload if(~ $boxname */draft){ x=postexec echo -n 'Post ' | winwrite tag } if not echo -n 'Reply Delmesg ' | winwrite tag cmd $x Get wineventloop } fn postexec { switch($9){ case Get winctl get case Post switch($boxname){ case */draft if(winctl put) $mh/send -attach Attach -push -draftmessage $boxname/$msgnum case * # should copy body into draft file and post it # can't put - would overwrite good message echo cannot post from non-draft } case Del # check that window is clean! winwriteevent $* case * winwriteevent $* } } nl=' ' fn postwin { if(~ $#msgnum 1){ # prepare a reply winread body | 9 grep -i '^(Reply-To|Subject|From|Message-Id):' >/tmp/mail.$pid winread body | sed '1,/^$/d' | sed 's/^/> /' >/tmp/body.$pid oifs=$ifs ifs=$nl subject=`{9 grep -i '^Subject:' /tmp/mail.$pid | sed 's/^Subject: *//'} from=`{9 grep -i '^From:' /tmp/mail.$pid | sed 's/^From: *//'} msgid=`{9 grep -i '^Message-Id:' $box
Re: [9fans] acme mail on unix
oops, sorry for the noise, didn't mean to send this to the list. > Russ, > This is great! I am very eager to try this out. > However I didn't get the Mail script you attached. It just > came through as an empty file. Would you mind sending that > again? > > tim > > > > I am sending this from inside acme Mail on Linux. > > Or at least the program is called Mail. > > It's not actually the Mail from Plan 9. > > > > I am running mh and have 'customized' it to print > > something close to sensible output. Mail itself > > is a shell script. The interactive delay is a little > > annoying sometimes, you have to run inc and Get > > to check for new mail, and the script itself needs > > to be cleaned up, but it's still entirely usable. > > > > I have attached my .mh_profile, Mail/mhl.format, > > Mail/mhl.headers, and the Mail script itself. > > > > Russ
Re: [9fans] acme mail on unix
Russ, This is great! I am very eager to try this out. However I didn't get the Mail script you attached. It just came through as an empty file. Would you mind sending that again? tim > I am sending this from inside acme Mail on Linux. > Or at least the program is called Mail. > It's not actually the Mail from Plan 9. > > I am running mh and have 'customized' it to print > something close to sensible output. Mail itself > is a shell script. The interactive delay is a little > annoying sometimes, you have to run inc and Get > to check for new mail, and the script itself needs > to be cleaned up, but it's still entirely usable. > > I have attached my .mh_profile, Mail/mhl.format, > Mail/mhl.headers, and the Mail script itself. > > Russ