[9fans] acme mail on unix

[9fans] acme mail on unix

[Russ Cox]

[-- Attachment #1: English text --]
[-- Type: text/plain, Size: 552 bytes --]

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


[-- Attachment #2: English text --]
[-- Type: text/plain, Size: 102 bytes --]

Path: Mail
Draft-Folder: draft
Aliasfile: aliases
mhshow-charset-iso-8859-1: %s | tcs -f 8859-1


[-- Attachment #3: Ascii --]
[-- Type: text/plain, Size: 266 bytes --]

; mhl.format
;
; default message filter for `show'
;
overflowoffset=4
leftadjust,compwidth=9
Date:formatfield="%<(nodate{text})%{text}%|%(pretty{text})%>"
To:
cc:
From:decode
Subject:decode
:
body:nocomponent,overflowtext=,overflowoffset=0,noleftadjust

[-- Attachment #4: Ascii --]
[-- Type: text/plain, Size: 223 bytes --]

; mhl.format
;
; default message filter for `show'
;
overflowtext="***",overflowoffset=5
leftadjust,compwidth=9
Date:formatfield="%<(nodate{text})%{text}%|%(pretty{text})%>"
To:
cc:
From:decode
Subject:decode
:

[-- Attachment #5: directory --]
[-- Type: text/plain, Size: 0 bytes --]

Re: [9fans] acme mail on unix

[Tim Wiess]

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

[Tim Wiess]

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 Cox]

[-- Attachment #1: English text --]
[-- Type: text/plain, Size: 64 bytes --]

Mail script should be attached.  This time for sure.

Russ


[-- Attachment #2: rc executable file script --]
[-- Type: text/plain, Size: 4517 bytes --]

#!/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:' $boxname/$msgnum | sed 's/^[Mm][Ee][Ss][Ss][Aa][Gg][Ee]-[Ii][Dd]: *//'}
		replyto=`{9 grep -i '^Reply-To:' $boxname/$msgnum | sed 's/^[Rr][Ee][Pp][Ll][Yy]-[Tt][Oo]: *//'}
		rm -f /tmp/mail.$pid
		ifs=$oifs
		if(~ $#* 0){
			if(! ~ $#replyto 0)
				*=($replyto)
			if not
				*=($from)
		}
		if(! echo $subject | 9 grep -si 're:')
			subject='Re: ' ^ $"subject
	}
	newwindow
	n=1
	while(test -f $home/Mail/draft/$n)
		n=`{echo 1+$n|hoc}
	name=$home/Mail/draft/$n
	msgnum=$n
	boxname=$home/Mail/draft
	{
		echo 'To:' $*
		if(! ~ $#subject 0)
			echo 'Subject: '^$subject
		cat $home/Mail/headers
		if(! ~ $#msgid 0)
			echo 'In-Reply-To: '^$msgid
		echo 
		if(test -f /tmp/body.$pid){
			cat /tmp/body.$pid
			rm /tmp/body.$pid
		}
	} >$name

	winname $name
	winctl get
	echo -n 'Post' | winwrite tag
	x=postexec
	l=boxload
	wineventloop
}

boxwin $home/Mail/inbox; exit

Re: [9fans] acme mail on unix

[Aaron Griffin]

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

[Russ Cox]

> 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

[Dan Cross]

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

[Russ Cox]

> 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

[geoff]

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

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.

[-- Attachment #2: Type: message/rfc822, Size: 2996 bytes --]

From: "Russ Cox" <rsc@swtch.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] acme mail on unix
Date: Thu, 19 Jan 2006 16:58:30 -0500
Message-ID: <20060119215835.492A124FAE@holo.morphisms.net>

> 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

[Scott Schwartz]

| 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

[John Barham]

> 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

[erik quanstrom]

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.M580106P15382V0000000000000303I0009030C_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 <jbarham@gmail.com> 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

[Dave Eckhardt]

> (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

[erik quanstrom]

Dave Eckhardt <davide+p9@cs.cmu.edu> 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

[erik quanstrom]

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 <cross@math.psu.edu> 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

[erik quanstrom]

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 <quanstro@quanstro.net> writes

| Dan Cross <cross@math.psu.edu> 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

[uriel]

> 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

[erik quanstrom]

uriel@cat-v.org 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

[uriel]

> uriel@cat-v.org 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

[erik quanstrom]

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

uriel@cat-v.org writes

| 
| > uriel@cat-v.org 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

[Russ Cox]

> 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