given
show 107 96
show shows 96 and then 107, instead of respecting the order provided.
--
H4sICNoBwDoAA3NpZwA9jbsNwDAIRHumuC4NklvXTOD0KSJEnwU8fHz4Q8M9i3sGzkS7BBrm
OkCTwsycb4S3DloZuMIYeXpLFqw5LaMhXC2ymhreVXNWMw9YGuAYdfmAbwomoPSyFJuFn2x8
Opr8bBBidcc=
--
MOTD on Prickle-Prickle, the
Hello,
I'm using nmh 1, and am not readily able to upgrade and verify that these
problems exist in 1.2, although there is no mention of fixes in the ChangeLog.
I have a feature request and a bug report regarding sortm. The feature request
is simple enough, the sortm man page rather implies that
I've looked at the code now and it's quite clear that the meaning of
a folderspec beginning with either dot or double dot is relative to
the current working directory, not the Path: profile entry.
I've not used these forms of + (nobody on the list seems to use these
[odd] undocumented constructs]
Besides, I've always found fcc useless. It doesn't expand local user
names, e.g. `to: ralph' stays like that instead of becoming `to:
[EMAIL PROTECTED]', and there's no message-id which is vital for
Erm, it's not at all useless, you're misusing it. Fcc is for filing a
local copy, it expects a
Actually, my mind blanked and I sent the message before verifying a
test case. It seems it did just hardlink messages, but I seem to recall
this not always happening. Is the fallback to copy the message? If so,
a message to the user that this has happened would be nice.
--
Free map of local
Minor note: hard links do not work across directories in AFS.
This may be part of the problem you're seeing.
Really? (Not that it would surprise me)
% refile -link last +Trash +SPAM
% perl -le 'foreach( qw(/mit/belg4mit/Mail/SPAM/978
/mit/belg4mit/Mail/Trash/896) ){ print $_: @{[stat $_]}: $! }'
How can I disentangle the evil that are mhshow and mhl from nmh?
In nmh 1.0 I was able to set showproc and moreproc in mh_profile to less
and view my messages in piece (text files in a text viewer, the novelty).
But I just installed 1.3 on another box (RHEL4 with Fedorqa SRPM) and it
seems even
At least on my box, as long as you give slocal -user when it's invoked,
Strike that, reverse it. As long as -user *is not supplied*, presumably
due to these lines of localmail:
443 /* last resort - deliver to standard mail spool */
444 #ifdef SLOCAL_MBOX
445 return usr_file
You might try telling slocal to be verbose, in which case it might
say what was going wrong, or alternatively run under a debugger and
see why status is being set to -1...
This has been suggested before, but it's not the most end-user friendly route.
# slocal -debug
vec[0]: default
vec[1]: -
From strace
write(1, !/var/spool/mail/belg4mit\n, 26) = 26
open(/var/spool/mail/belg4mit, O_RDWR|O_CREAT|O_NONBLOCK, 0600) = 5
write(1, !/var/spool/mail/belg4mit.lock\n, 31) = 31
uname({sys=Linux, node=vm10.myvpshost.com, ...}) = 0
umask(022) = 077
No, it is not ncurses based
# ldd mhshow
libiconv.so.2 = /usr/local/lib/libiconv.so.2 (0x2af0a6328000)
libtermcap.so.2 = /lib64/libtermcap.so.2 (0x2af0a6609000)
libc.so.6 = /lib64/libc.so.6 (0x2af0a680c000)
/lib64/ld-linux-x86-64.so.2
It depends on what's provided on the platform. configure
searches for available libraries in this order:
termcap_curses_order=termcap curses ncurses
I don't think that really qualifies as curses based,
using an variant of a standard library that might be provided by (n)curses.
And that is the
It's not necessary to write an entire IMAP implementation from scratch,
there are a few possible codebases to work with.
List member David Keijser wrote of his attempt in Python this October:
http://www.mail-archive.com/nmh-workers@nongnu.org/msg01803.html
And there's also:
Why?
What difference does it make if MH's mail store format is non-standard?
If you ever need to export things there's packf (although some scripting
may be necessary to handle nested folders) to get an mbox.
You wouldn't just be sacrificing esoteric features of MH, but also much
of ability to
Sorry, a little more...
Apparently somebody also thought it was a good idea though,
and one of the top results from Google for nmh maildir is:
http://www.jeenyus.net/linux/mdmh.html
Where someone created some reimplementations of MH comamnds
for use with maildir; the author seems to have
Specifically see the masquerade option and draft_from
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
you can either:
- add your new From: header manually, when you
edit your draft (perhaps you can define an editor
macro to help with this), but this will become tiring.
This repetition is not necessary.
A related approach uses shell aliases and the -form option:
Also not
RTFM... mhl + mhshow to display whatever portions of messages you want.
Post-process for printing as necessary if |lpr ain't good enough :-P
--
Free map of local environmental resources: http://CambridgeMA.GreenMap.org
--
MOTD on Prickle-Prickle, the 59th of Chaos, in the YOLD 3176:
1:37 is an
Section 4.4 Re: filters
`pick` is a mail-aware grep-like filter
I use it in a chain-like way via:
alias pscan 'scan `pick !:*`' #tcsh
One could argue that `mark` is also a filter.
Section 4.5 Re: IMAP
You should probably revisit the list discussion and include some of the points?
For
I found the problem: for whatever reason I am not allowed
to choose `new' as a sequence name.
From mh-sequence(5):
There is also a special reserved message name new which is
used by the mhpath command.
--
Free map of local environmental resources:
I do not think msh should be discarded. At worst, a build time option,
but you never know when you might want/need it, so why not build it?
It's a single, documented useful utility that provides a useful
complement to packf. I've not had *much* call for it, but it's nice
to know it's there if I do
If both text/plain and text/html is available drop text/html
(maybe configurable ?)
You'd have to do this interactively, showing a snippet of each,
with the option to specify it on the command line.
Too many mismanaged mailing lists have nothing as their text/plain
content other than Your mail
Quoth Lyndon:
Par isn't part of nmh any more than 'less' is.
My point was that if there's an existing tool we recommend deferring the
heavy lifting to, particularly something that is not part of a standard
*nx kit, maybe it should be included in the distro.
Quoth Valdis:
given lproc and moreproc,
I was under the vague impression that ORA gave Jerry back the book and
Indeed, its now GPL: http://rand-mh.sourceforge.net/book/
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
- If there is a draft without a From that is fed to post, it will error
erp? What sort from From is it going to require?
I currently use
From: me
And it DWIM, while giving me the ability to quickly change it in a draft
to another of my identities
I agree with Tet, and considered saying the same thing
(though less eloquently) last night...
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
This behavior is documented in the repl man page, from context it appears to
be to support for custom editors (or the imaginary replproc) to do things w/o
having to grok the MH message filesystem
See comp(1) for a description of the -editor and -noedit switches.
Note that while
I guess that I avoid multiple concurrent compositions of all
sorts because it's painful because of the shared draft file
unless one uses long options.
That's what .mh_profile defaults are for, and Jerry Peek's recomp ;-)
http://rand-mh.sourceforge.net/book/examples/mh/bin/recomp
The patch inlined
Shouldn't take much more than
#after opening for reading
binmode(IFH, ':utf8');
#before writing
binmode(OFH, ':utf8');
to fix your formatting script.
If adding perl dependency, you'll need to require at least 5.6.1
for utf8, although 5.8 or better yet 5.10 would be preferable;
perl may
Yes, I think it does that. Bit annoying. Would be nice if it picked
the one that shipped the least bytes.
Bytes schmytes, pick the one that's maximally human readable.
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
My long standing work around for this, is to use the profile entry #
As in
#:#
#: System wide variables
Aliasfile: aliases
Draft-Folder: drafts
editor: emacs
#:#
#: Program defaults
...
Works like a charm
___
Nmh-workers mailing list
Maybe we should simply reserve # as a profile component and document #:
as the .mh_profile comment character(s) rather than leave it as a puzzle.
Makes sense to me. If documenting, point out that you cannot have blank lines,
hence my use of #:# To separate blocks, although if someone were so
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)
___
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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
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
- 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
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
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.
Sounds great, where is it? :-P
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
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
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
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
$ 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
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
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
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
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
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
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'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
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
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
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
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
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
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
1 - 100 of 132 matches
Mail list logo
