>In principle I'd *like* to run mhfixmsg on email as it's delivered, but
>I'm also sympathetic to the "keep the wire copy" argument, and a little
>worried because of the abovementioned failures; does anyone else run it
>through procmail? Are you happy with your experience of same?
I've been using
If the goal is to have grep-able messages easily,
two things come to mind:
1) my previous MIME-hooks scripts, which save the original
message as #.msg, and then use mhmimefix to massage the message
into something more human friendly. These can easily be extended.
Or, you could just add your own
%(exec procedure_name)
This opens a possible attack vector, though not easy to exploit reliably,
if said scripts are not carefully designed. exec's also a name with certain
connotations, eval or pipe are closer to the behavior described.
I would suggest local date as the default is sensible,
if someone wants the raw date they can view the file directly.
However, either way it goes, the alternative should be included
in the default format file but commented out and with an
explanation, since mh-format is not intuitive for all and
mhdraft is documented in the octopus book.
http://rand-mh.sourceforge.net/book/http://www.oreilly.com/openbook/mh/
Ideally the man pages would be complete of course,
but for any sort of scripting, Jerry's book should be on hand.
___
Nmh-workers
forw -mime
(f key in mh-e)
I would look at dist to avoid added layers of MIMEness.
GMail is relatively clueful about it, but may occassionally
misdirect things to the spam folder.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
I recently discovered what seems to be a wart in pick,
it resets Previous-Sequence to *all*. It does not set
it to match the returned results, nor does it leave the
sequence unmoleated. This unespected behavior resulted
in a very nasty surprise when I ended up removing all
of my messages after
mhl has baggage that I don't believe that -- nor do I believe that you believe
...
I think you should be able to design and write the new program unencumbered by
the encrustations of the past. Of course, if in in writing the new code, you
want to copy some of the mhl code, the ghost of Dijkstra
Further, it seems to me that it would not be hard to determine if
the text/plain and text/html parts are essentially identical.
This is a more difficult problem than you imagine. You'd have to render
the HTML, and then decide what essentially identical means. For many
it would be differences in
The RFCs that define MIME say that alternatives parts representing the
same content, e.g. text/plain, text/rtf, and text/html, shall be in the
email in order worst to best when judged by their ability to represent
the content. This allows a user reading the email in an MUA that's not
It understands more structured information as well, but seemingly only in
American style dates and without support for 24-hour times e.g;
% google calendar add 12/31 at 10:30-12:00AM Partay!
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
I have never known profiles with leading # alone to parse properly,
since that does not look like a header. Use #: or #Label: instead
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
I'll echo Norm's request for better repl to MIME messages.
Maybe replyfilter would do the job. But I tried once and
couldn't use it due to Perl madness, and haven't gone in to
figure it out. Also, I'm little wary of depending on par in
a UTF-8 world: the patch to par to deal with multibyte
one also might wonder why postscript is such a special flower.
It is an odd-beast, but the files are mostly ASCII,
so somebody probably thought to use QP for efficiency's sake
(and preserve legibility?)
I was curious and searched the web for postscript quoted-printable,
it seems to be a common
They are similar, but there is a small advantage to using the
scan.highlighted format: you can have a shared format file owned by root
with abstract names-- scan-color-cur, scan-color-unseen--and users can
customize the colors as they wish without having to maintain their own
scan format ;-)
I'm
Please make sure it handles ~/ (much shorter ;-) not just ~user
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Does POSIX's wordexp(3) help?
I ... do not think so. Unless I am misreading the man page, you can't make
it just do tilde expansion. I don't like the idea of a single Attach:
header expanding to multiple files.
why not?
it's now the primary UI for attachments. why not make it a
mhlist is almost certainly the correct place for this if done in nmh,
and leveraging existing format info is a good idea Ken. Although,
it would be easy to roll a perl script for this too ;-)
An alternative structure would be a means for mhlist to simply
provide a list of part identifiers*. It
I would like it if the Attach: header would do tilde expansion :-)
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
I made those changes, but then ran into a problem. If you set
--with-backup-prefix to soemthing in a pound sign e.g; .# or #
...things blow up Makefile.am does not seem to have any facility
for escaping interpolated values, and apparently pounds signs
aren't portable in Makefile variable values
Does it work now that we've actually fixed locking? I recall that
was an issue before, and AFAICR it only worked because we incorrectly
kept going even if we failed to acquire a lock.
Oh, good call. I suppose I'll have to bite the bullet and upgrade to RC1
from the February pull. I'll get back to
That really seems like overkill. Also, none of those scripts are
regularly tested, or even supported. I would much rather see those
copied into /usr/local/share/nmh/contrib, with a post install note
pointing out that directory.
They might not be tested nmh-workers, but I expect we are all eating
Some basic testing shows no issues with mime-hooks in RC1.
Also, I updated the archive to 0.08; made a convenience script from TODO list.
However make check (an alias of make test might get more muscle-memory
prompted testing done by those used to working with perl ;-) returned a
few errors that
I have mixed feelings about this; I think /bin/bash is wrong, but I thought
that /bin/sh should actually work everywhere.
It depends on the script. If it needs bash, then it should be specified as
bash since bash will operate with a simpler feature set if invoked as sh.
I know perl is all over
I've not had a chance to dig through the code yet,
but it just occurred to me hat it doesn't really
matter whether or not nmh would like lines greater
than 998 characters. If does, then mhfixmsg could
replace the HTML part with an un-transfer-encoded
version, but the issue at hand is creating a
If the issue is that we need to un-qp some HTML content that results in
a line length 998, but then that HTML will be converted to plain text that
presumably won't have long line, then that would be fine
Precisely.
It does. At this point, I don't understand your problem.
mhfixmsg adds
And the message is unaltered.
Is it? That text/plain part should have been inserted. And the
inserted part should be a text/plain representation of the binary
text.
Yes, no modifications are made at all accoreing to cmp.
nmh MIME parser. While it's possible that long lines might be
OK, I
However I will note that the mhfixmsg man page does not indicate that
it uses the mhfixmsg profile parameter, which is why I asked...
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
However I will note that the mhfixmsg man page does not indicate that
it uses the mhfixmsg profile parameter, which is why I asked...
Do any of the other commands say that they do? A quick check suggests
that they don't.
No, I don't suppose they do. mh-profile(5) covers this case, but it
seems
Download it using the plain link, then man ./mh-mime.man
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Hi all,
mhn.defaults.sh checks for the presence of lynx before elinks.
It seems as though it should check for the availability of
more modern tools before falling back to old standbys, and that
they ought to be reversed. This would also solve the problem
for me on some systems where lynx is
I'd prefer lynx over elinks because elinks doesn't have a
way (that I can see) to tell it the charset of the content.
Not from the command line. It uses LANG/LC_CTYPE/LC_ALL,
and this can be overridden from the SetupCharacter set menu;
which could probably set in a dummy config pointed to be
What are the chances of including vpick in contribs, or some of the other
modern enhancements? Or do we want most of them to live separately?
I'll also take a crack at a guide to resources for customizing nmh next week,
I've been busy with three conferences this week. I'll have to write it in
In not keeping with usual MH practice, don't provide
-nodryrun? It just seems too confusing, and if you get it
wrong there's no -undo.
Thre's a certain amount of logic to that, but because there's no undo
someone one might want to set a default of -dryrun to prevent errors,
and then explicitly
Might be a little word-smithy, but I'd say durable code
or hidden invocations instead of permanent code, but
otherwise sounds good! (also something to include in
hypothetical extending nmh docs ;-) ... maybe I'll give
that a crack sometime soon, although I don't grok roff.
GNU make has --recon as a synonym for --just-print/--dry-run/-n
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
amIn my personal opinion a very good choice is conversion into
amhtml-entities, like aogon; or lstrok; . It remains quite readable and
amis still unique enough to convert it back in case of need.
krUm, ouch. Unless there's a common library that already implements
krthat behavior, that's not on
Recode need not be required, it could just be an option. iconv currently
isn't afterall, although they seem to complement each other. Recode is
part of the core distrib of my older Ubuntu 10.02.
Selective recoding would probably require calls for the substrings of interest.
As an aside, recode's
khAre you using 1.3 (ewww), 1.5, or post-1.5 for your nmh implementation?
1.5+dev pulled from master on Monday (2/24) morning
khWell, think about what's going on. You're changing sequences in the
khmiddle of an operation which is changing sequences. At a minimum you're
khgoing to be on the
My *intent* when adding the hook code was to allow external, non-nmh programs
to access the message store keeping track of changes. I added this code for
a specific purpose, and never thought about anyone executing nmh commands
inside of hook code. So I support Ken's conclusion that doing so is
Of course, if you want to CALL mark inside of a hook, then all bets are
off :-) I'm unclear how we can make that better. I will note that rcvstore
can add messages to specific sequences, and there was a deprecated feature
Nice! If that happens after add-hook we're 90% there.
The only problem is
I can save you the trouble; that's not going to change anything. All
set_unseen does is modify the sequence status bit vector in the folder
structure. The locks don't get released until seq_save() is called.
Actually it did solve the problem.
Sorry if I was not clear, the idea of moving it was
Nope, not mixed versions, but your guess is as good as mine as to what's up.
I can poke around some more in the next few days/keep my eyes peeled.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
The only difference is ctxpath, which is to be expected since MHCONTEXT
is set in one instance. I've also unsuccessfully tried a workaround of
copying the sequence to another, then using mark -seq unseen tmpseq $MSGNUM
___
Nmh-workers mailing list
I suppose I could try, but I've not used a C debugger
Hmm, on a hunch I just discovered that somehow the call to mhstore
in mime-add-hook's for loop is the trigger... of course that's the
raison d'etre of the script :-/
Hopefully it's not too hard to follow:
#!/bin/sh
VERSION=0.05
#Diagnostic
1. I had thought that I had added the hook stuff to the documentation for
mh_profile but I don't see it there. I'd be happy to add it. I have
mh_profile seems like a good place for this. There coudl also potentially
be a cookbook somewhere on extending nmh, with references to this, Jerry's
mh_profile seems like a good place for this. There coudl also
potentially be a cookbook somewhere on extending nmh, with references to
this, Jerry's book, contribs, GUIs, etc.
Jerry's book is open source, and can be modified.
Indeed.
Sigh .. so much documentation to do, so little time.
I more
del-hook is not called if rmmproc is set. This prevents the user from doing
a number of useful things e.g; restoration of original message in MIME-hooks
(see forthcoming message to list) I would expect the hook to be called before
rmmproc is invoked, and not wrapped into the non-rmmproc fallback
FYI, it runs out slocal is handled (the + action uses rcsvstore).
I missed this in preliminary testing because slocal is headless :-P
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
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
I am using 1.3, and the triggers only invoke with absolute paths.
I have a master branch checkout of 1.5 from last March I've been
trying, I did not check this particular issue but will take your
word about it now accepting bare command names.
The bigger problem of course is that nmh reports a
I cannot get the hooks to work:
inc: external hook ((null)) did not work properly.
refile: external hook ((null)) did not work properly.
Although add-hook does not work for inc, nor does ref-hook for refile,
I just noticed that add-hook successfully fires on Fcc*. I've also found
add-hook
And, I have to ask ... 1.3? You're not the only person still using that,
so I'm wondering if I did something wrong, or you just haven't seen a reason
to upgrade yet.
I'm running CentOS 5.9, so no package support.
I downloaded master for mhfixmsg this past spring, one of the more compelling
Yes, executability was one of the first things I checked ;-)
Note the most recent message where it does work correctly
for Fcc and refile -link though... very odd
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
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
I've added some documentation (perldoc mhisto) and filtering features:
You may specify a comma or pipe-delimited list of address (substrings)
to be used in a regular expression to limit the set of per-sender
graphs to be printed. The switch may also be given as a negated form
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
My guess is uucp, whichhad a ! delimited path,
but there was still an intended recipient at a machine, but not @.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Wouldn't a FUSE IMAP layer largely solve the problem of conflicts
by working on the live data store? Perhaps a customization of
something like:
http://imapfs.sourceforge.net/
http://www.sr71.net/projects/gmailfs/
___
Nmh-workers mailing list
have to manage the mapping between MH message numbers and IMAP messages,
which involves a synchronization process. Also, it just seems like to
Yeah, if I were doing it I'd probably not support all of MH's numbering
and sequence goodness... for simplicity/sanity's sake. Just allow basic
sortm to
FTM
In addition to 822-style dates, pick will also recognize any of the
days of the week (sunday, monday, and so on), and the special dates
today, yesterday (24 hours ago), and tomorrow (24 hours from
now). All days of the week are judged to refer to a day
See the man page for mh-tailor which describes the mts.conf
options for the address masquerading you wish to do.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
$ scan unseen
...notice that third-from-end message is spam...
$ refile unseen_3 +spam
Seems delightfully error-prone and inefficient.
Scan includes message numbers, rmm the specific
message and there's no need to count lines of output.
vpick might also be useful here?
digit message numbers. believe me, p last_4 is much less error
prone than p 365530.
Sorry, I wasn't clear. The error-proneness wasn't due to typing,
but in gauging which line of the displayed sequence was the message
you cared about. Although I suppose those who love this mode of
specifying
And I also think that nmh shouldn't have such a low limit on
the number of sequences. Even 59 is, or will soon be, too
low for someone. It'd be nice if we wouldn't have to
Really? This might be a bit of armchqir quarterbacking...
but it seems to me if you have 5 dozen sequences in one
folder
Ahh, yes, probably a dirty tree/funky dependencies.
I extracted this evening's tarball over yesterday's build,
but I would have expected a reinvocation of configure to
force any necessary updates... however make has its own
way with things :-P
As for Lyndon's comment, yes, having things be in a
CentOS 5 is on Automake 1.7, but I upgraded to build
mhfixmsg once I figured out what the problem was...
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Sounds great, where is it? :-P
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
The normal way to handle your second problem is to set $MHCONTEXT
for the scope of your script. Admittedly, this is not listed prominently
in an ENVIRONMENT section of most nmh man pages (not even nmh itself).
As for the first, you might also look at slocal.
Failing out would be nice, as would be an option to edit.
I often mistype an Fcc, and then hqve go trolling through
drafts for the message to mv
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
- Remove rcvtty completely. This works in conjunction with slocal or
I would not be happy with that, I use slocal and rcvtty for
(user-configurable) new message notification.
My .maildelivery is:
#Field Pattern Action Result String
X-Spam-Flag NO qpipe R
Wow, ok ... I didn't think anyone used that, but I stand corrected. It
looks like what we did for OpenBSD was simply make rcvtty not work. Are
you fine with that? I'm not really interested in dealing with OpenBSD's
brokenness here.
Fine with me, I usually run some flavor of Linux.
Although it
My rmm is an alias:
refile -normmproc !* +Trash
Thus I can search back throug deletd mail.
Whenever I notice such searching is slow,
or the message numbers in the results are
approaching 2000 I `empty first:800` or so.
Empty is an alias:
/usr/local/bin/rmm +Trash !*; folder -pack
With
Will do. Any suggestions on what to call the escape function?
It sounds like a zero-width operator, though that's rather long.
What about hide?
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
It's definitely practical on a tablet,
Hacker's Keyboard + ConnectBot is very usable.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Is `scan +/tmp/foo' documented anywhere, i.e. the ability to treat any
directory as a folder, not just one under Path? And `@..' after that..
Doh. Was planned but slipped my mind. Here are revised versions.
1) Insert into nmh.1 near:
Commands which take a message number as an argument (
For what it's worth, it make sense to me. The only draw back is that
you cannot get an overview of it all in one screen. I might also suggest
adding sub-headings for each action group.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
I would have thought `mark -seq cur -del` would work, but it does not.
That would seem to be the logical command to use? nor does
`mark -seq cur -del cur` nor `mark -seq cur -del #`
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
I'd probably use it. Though I've been trying to rely more on pick
and less on message numbers.
You might vpick useful for certain use cases
http://pthbb.org/manual/software/MH/vpick.html
I find the following incantation especially useful:
vpick -seq unseen -cull -new
That only shows you
Apparently it is, but what is it supposed to do?
It's a bad list because your cur was 9. Try:
pick 1; pick cur-9
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
I don't really understand how relative numbers are useful, but if they are to be
introduced why not use the same signifier as for folders? i.e; @
cur@2 = cur+2 cur@-4 = cur-4
This could also prevent some confusion as to why we are using something with a
clear meaning (+) for such an odd
folder +inbox
refile @example last# Means +inbox/example.
huh. i believe you, but you might have just found a bug in
the man pages. :-) i can find no mention of such a feature.
volunteers?
I can try to tackle this tomorrow evening.
Sending files as .exe is probably not the wisest way to work around things
either, as you wil fall afoul of virus heuristics. .bin seems to be the
more conventional way to approach this.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
You want mhstore, mentioned in the See Also of mhshow
mhstore (1) - store contents of MIME messages into files
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
I use rcvtty actually. It was the closest I could come,
with minimal effort, to replicating the mail zephyr class
used at MIT :-P
.maildelivery
X-Spam-Flag NO qpipe R /usr/local/lib/rcvtty -form
rcvtty.format
___
Nmh-workers
It's not broken, read the diagnostics and follow the directions provided.
You have to supply a From now
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
I would have expected the upgrade to install the appropriate components
to not break things.
In which case it would likely break things in other ways,
or not do the right thing for some individuals.
Making specific changes to a template of unknown content is fraught with peril.
as an unfortunate and unnecessary burden on code whose assumptions have
been valid for a long time.
But it's still an assumption, and we know what those mean.
More seriously though, is there an actual spec for MH declaring
what valid folder and filenames are?
What's the worst-case for those using
You seem to have misunderstood my proposql.
Paul, Message 76 would still be what came over the wire,
however something like mhstore could optionally make 76.*
as the split out compoents
Tet, nothing in what I wrote implied you couldn't have
76.1.1.4 grep's, not going to care.
Sorry for the premature reply.
I see now that Paul did understand my idea.
I can underatd that some might not want duplicate
content, but that's what I proposed it be optional.
A temporary cache does not allow for indexing.
Keeping it in Mail means you have whichever
decoded messages you want
A hyphenated switch (without long-opt beginning) seems awkard,
can we add -H (a la curl) as a synonym? I might also suggest
calling the header content a value rather than a body,
for unambiguity's sake.
Cheers!
___
Nmh-workers mailing list
That's as designed, you're resending, as is, not forwarding.
Did you enter the info and send?
A more useful way to use dist is:
dist -editor prompter
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
mts.conf is fairly important but rarely touched,
so people may not recall what options they had set
to get things working.
I think clobbering it is bad. If not preserving
the original, can we make the clobber happen late
in the install and cat the current file to STDOUT
for anyone who overlooks
In which case, couldn't they just do sh -c whatever as the thing that
would get passed to their login shell (i.e., csh)? It's a bit clumsy,
but it should work for the few people that are in that situation.
Why do you want to use the user shell exactly?
Yes, the user might be more familiar with
Could nmh not do with such parameters what perl does for
system()/exec(), auto-splitting the string? In the off
chance that someone's installed binaries in a path with
a space they can escape the space, same as they would in
a shell...
___
Nmh-workers
My $_ is bad, no lexicalization of $boundary is bad.
If you must do it all in one fell swoop w/o pre-declaring $boundary use:
local($_, $boundary) = ...
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
$_ is a special global, you lexicalize these with local not my,
especially if you want to be backwards compatible ;-)
Although 5.8 is a bit old, it's still common and has good Unicode
support, therefore as long as the changes to support are minimal
I suggest it is well worth doing.
Sorry, by lexicalize I mean limit scope,
since lexical specifically refers to my and our.
FYI my($_) was introduced in 5.10
http://perldoc.perl.org/5.10.0/perldelta.html#Lexical-$_
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
DEFAULTS
'+folder' defaults to the current folder
'-add' if -sequence is specified, -list otherwise
The first default is true
The second implies `mark -seq cur` should list the current sequence,
which it does not (tested 1.3 1.5RC1)
___
1 - 100 of 132 matches
Mail list logo
