Hi Jon,
Many years ago I added the hooks interface to nmh. Hasn't been as
controversial as my attachment handling stuff, which makes me think
that it isn't widely used.
I might vaguely recall it being mentioned. I found
http://git.savannah.gnu.org/cgit/nmh.git/tree/docs/README-HOOKS.
I'm not sure I follow. From where I'm sitting MH mailboxes are only
useful with traditional Unix tools true if the vast majority of email
you have in your mailbox is US-ASCII text/plain only. Can't speak for
anyone else, but that's slowly becoming less and less true for me.
Since MH tools only
Ken Hornstein k...@pobox.com writes:
See, this is where we run into two competing ideas as to what MH's original
innovation is. Do people think it's:
1) The message store (1 file per message), instead of one file for the
whole store.
2) Individual commands to perform message operations,
if mail commands can't trivially be part of shell scripts
then having one message in a file is a lot less interesting
I'm not sure I follow. From where I'm sitting MH mailboxes are only
useful with traditional Unix tools true if the vast majority of email
you have in your mailbox is US-ASCII
Ken Hornstein wrote:
if mail commands can't trivially be part of shell scripts
then having one message in a file is a lot less interesting
I'm not sure I follow. From where I'm sitting MH mailboxes are only
useful with traditional Unix tools true if the vast majority of email
you have in
On Feb 22, 2014, at 21:20, Paul Vixie p...@redbarn.org wrote:
given the number of messages in my mail repo whose bodies are in
quoted-printable or base64, or which have attachments that are binary, i've
only been able to access my stored mail, or indeed inbound mail containing
commands of
Lyndon Nerenberg wrote:
If we undid the transport encodings for text/* and converted everything to
utf8, you could then, e.g., alias mhgrep='env LC_ALL=en_CA.UTF-8 grep'.
all true. but there's a strong feeling among MH zealots, of whom i am
one and which feeling i do share, that what gets
And despite the prevalence of QP and base64, I still find grep works
quite well for me. Anything text/* that is all base64 is almost always
spam, so the base64 encoding is actually a 'feature' for me, ensuring
the message doesn't generate a false positive match for what I am
really looking for.
On Feb 22, 2014, at 21:43, Paul Vixie p...@redbarn.org wrote:
all true. but there's a strong feeling among MH zealots, of whom i am
one and which feeling i do share, that what gets written to
$HOME/Mail/inbox/42 ought to be the raw BODY that came in over SMTP.
But which SMTP? The MTAs are
Lyndon wrote:
There is nothing that says we cannot undo transport encodings for
text/* parts when we write store a message into a folder.
mhfixmsg -decodetext 8bit
And despite the prevalence of QP and base64, I still find grep works
quite well for me.
Agreed.
If we undid the transport
Hi Norm,
Here, for example, is one stab at how messages would be stored.
Each message would be a directory. Each component would be a file or
directory, whose name was the component name, Each MIME part would be
a directory.
Plan 9's filesystem that presents an email as a directory is worth
Hi Jeff,
Just because you can use a lot of disk space doesn't mean you should.
If you use a database backend for indexing the messages you detect and
avoid duplicate copies of attachments. The actual pieces of the
message could still exist in directories with duplicate copies linked
in.
Hi Ken,
I dunno; to me, databases are fine for specialized things, but just
add a level of complexity that I don't necessarily think is useful.
Also, I'm not sure of the savings; maybe it's just me, but I rarely
get identical copies of the same message or attachment.
I think it's just you.
Hi Ken,
1) The message store (1 file per message), instead of one file for the
whole store.
2) Individual commands to perform message operations, as opposed to
traditional monolithic MUAs.
I've stuck with MH because it's both. Either on its own may not have
kept me over the decades.
Hi Ken,
Maybe a set of primitives, like mhcat that would let you output a
part of a message on stdout
Aside, I have
$ readlink ~/bin/mhcat
/usr/bin/mh/mhstore
$
Don't recall where I learnt to create it, mhstore(1) here doesn't
mention `mhcat', but I use it quite a bit. The
Hi Paul,
i would. first, i'd adopt the messages-as-directories model norm gave,
since it supports MIME, where our current model does not. by support
i mean i want to use normal UNIX file access to work with my message
store.
Yes. The original email should also be available, like upas's raw*
What you seem to be saying is that instead of an MUA where you are in
its own shell, e.g. mail(1), you have an MUA comprised of many commands,
scriptable with a bit of shell control-flow, but no commands outside the
MUA's set should touch the storage.
Well, not exactly.
I guess my feeling is
$ readlink ~/bin/mhcat
/usr/bin/mh/mhstore
$
Don't recall where I learnt to create it, mhstore(1) here doesn't
mention `mhcat', but I use it quite a bit.
Are you sure you don't have something in .mh_profile that makes that
work? I don't see anything in the code that would make that
Hi Ken,
$ readlink ~/bin/mhcat
/usr/bin/mh/mhstore
$
Don't recall where I learnt to create it, mhstore(1) here doesn't
mention `mhcat', but I use it quite a bit.
Are you sure you don't have something in .mh_profile that makes that
work? I don't see anything in the code
Hi Ken,
You say that the current store is inadequate. Okay, I can't really
argue that. But ... we've got a problem here. We have a number of
front-ends that have grown up assuming that the store isn't going to
change.
No, this isn't nmh. This is Norm's MH-2014. :-) The other projects
n...@dad.org writes:
I am suggesting this exercise only for recreational purposes.
Design MH, from scratch, without the constraints affecting the original
MH design.
Suppose, you weren't designing a system to run on a time shared PDF 1145,
but on a
single user, multi-core system.
So again, I think that the UI issues and message store issues are independent.
I'm personally much more interested in the UI issues. As I've said before,
the ability to scan/next/prev/show attachments would do it for me. This
wouldn't be too hard to add to the current UI. Oh, and the ability to
I think the whole exercise is too limited. If we're going to really blue sky
an idea, lets be revolutionary.
First of all, the whole concept of email is kind of obsolete. There should be a
universal messaging protocol that allows, for example, me to send you a message
via email, and you
to
maybe just using URIs and having the data accessed on demand would solve
this and also re duce message size.
MIME already has this. It's nice in theory, but it doesn't get used.
Among other things, it requires people to treat URIs as they're meant to
(permanent identifiers), and also to maintain a
Jon Steinhart j...@fourwinds.com wrote:
I use these hooks to build a separate searchable database. I have a
number
of additional command line utilities that operate on this database.
I'm interested in trying this.
Any of you could use these hooks to maintain a separate
I am suggesting this exercise only for recreational purposes.
Design MH, from scratch, without the constraints affecting the original
MH design.
Suppose, you weren't designing a system to run on a time shared PDF 1145,
but on a
single user, multi-core system. Suppose that you had multi
Just because you can use a lot of disk space doesn't mean you should. If
you use a database backend for indexing the messages you detect and avoid
duplicate copies of attachments. The actual pieces of the message could
still exist in directories with duplicate copies linked in. Attachments,
and
Just because you can use a lot of disk space doesn't mean you should. If
you use a database backend for indexing the messages you detect and avoid
duplicate copies of attachments. The actual pieces of the message could
still exist in directories with duplicate copies linked in. Attachments,
and
On Feb 19, 2014, at 8:22 AM, n...@dad.org wrote:
Suppose, you weren't designing a system to run on a time shared PDF 1145,
but on a
single user, multi-core system. Suppose that you had multi gigabyte disks
available.
MH is not resource constrained by CPU, or memory for that matter, so I
Lyndon Nerenberg wrote:
On Feb 19, 2014, at 8:22 AM, n...@dad.org wrote:
Suppose, you weren't designing a system to run on a time shared PDF 1145,
but on a
single user, multi-core system. Suppose that you had multi gigabyte disks
available.
MH is not resource constrained by CPU, or
On Wed, Feb 19, 2014 at 1:33 PM, Lyndon Nerenberg wrote:
As for disk space, how much you use is a function of the types of
email you receive and how much of a pack rat you are.
Yep. Ages ago, if one had a ton of email, you may have issues of
running out of inodes, but I do not think that is
On Wed, Feb 19, 2014 at 1:44 PM, Paul Vixie wrote:
i would. first, i'd adopt the messages-as-directories model norm gave,
since it supports MIME, where our current model does not. by support
i mean i want to use normal UNIX file access to work with my message
store. there is no file-level
On Feb 19, 2014, at 11:44 AM, Paul Vixie p...@redbarn.org wrote:
third and finally, i'd fully support the IMAP UID psychosis, by offering
persistent-for-the-life-of-the-message numeric identifiers,
For-the-life-of-the-message where? Within a folder? Within ~/Mail?
If you want a truly
i would. first, i'd adopt the messages-as-directories model norm gave,
since it supports MIME, where our current model does not. by support i
mean i want to use normal UNIX file access to work with my message
store. there is no file-level access to attachments right now, which
means i have to run
Ken Hornstein writes:
i would. first, i'd adopt the messages-as-directories model norm gave,
since it supports MIME, where our current model does not. by support i
mean i want to use normal UNIX file access to work with my message
store. there is no file-level access to attachments right now,
Earl Hood wrote:
On Wed, Feb 19, 2014 at 1:44 PM, Paul Vixie wrote:
i would. first, i'd adopt the messages-as-directories model norm gave,
since it supports MIME, where our current model does not. by support
i mean i want to use normal UNIX file access to work with my message
store. there
I feel about that like I do about Paul's rearchitecturing of the nmh
library: I think that's a great idea, my only concern is who, exactly, is
going to write that code? I don't have enough time on my plate to finish
the relatively straightforward things like RFC 2231 support; that's a huge
Might one use mailutils as a starting point? Didn't it come up in a recent
discussion that it was effectively a MH library with interface utilities?
Not necessarily the same ones we're looking for, but the core is possibly a
better starting point than scratch if one has no moral objections to the
Might one use mailutils as a starting point? Didn't it come up in a recent
discussion that it was effectively a MH library with interface utilities?
Not necessarily the same ones we're looking for, but the core is possibly a
better starting point than scratch if one has no moral objections to the
Though that could be replaced by a mhgrep that extracts
messages from whatever form they're in and feeds them to
grep (and caches due to likely locality of reference).
'pick' exists, although it doesn't support everything that grep does,
but it's pretty close.
Analogous to what less(1) does with
On Feb 19, 2014, at 9:37 PM, Paul Vixie p...@redbarn.org wrote:
i have a moral objection to the GPL.
I have a double-barreled shotgun for the GPL.
No, wait, against the GPL!
signature.asc
Description: Message signed with OpenPGP using GPGMail
41 matches
Mail list logo
