Jerrad wrote:
Try feeding mhstore from a file instead of a message, something like:
Alas, mhstore -file did not solve the problem;
Though it looks like mhstore causes the problem? I don't
understand why -file wouldn't solve it.
I seem to have found a workaround that works, even with the
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 :-/
Well, think about what's going on. You're changing sequences in the
middle
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
Hi Jerrad,
But other than the explicit calls to mark and Previous-Sequence,
sequences oughn't be being touched...? And I thought commands were
meant to open, close, reread sequences as needed rather than keep
a long lock? This is add-hook from rcvstore, via slocal.
You might find strace(1)
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 fringe of supported behavior.
But other than the explicit calls to mark and Previous-Sequence,
sequences oughn't be being
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
Jerrad Pierce writes:
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
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
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
The overall problem is that calling nmh commands inside the hook script
was removing the message from the Unseen-Sequence*. Delaying that call
until after the hook invocation is complete ensures that whatever operations
are done in the hook, the message ends up in Unseen-Sequence after the
program
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
In fact, the more I think about it, the more I wonder WHAT is going
on, exactly. The things you describe happening do not make sense to
me. Since the unseen sequence is not modified until the very end of
rcvstore, there should be nothing to remove from the unseen sequence
during the hook
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
Jerrad wrote:
In trying patch the last few nits in MIME-hooks, I seem to uncovered an
odd issue with mark. Despite the default behavior being to not zero a
sequence on -add, mark is clearing the sequence, even when -nozero is
explicitly given.
However I only see this behavior from mark
Initial .mh_sequences
cur: 15
pseq: 1-17
unseen: 15-17
Called in mime-add-hook if Unseen-Sequence is defined
mark 18 -nozero -add -seq unseen +/home/user/Mail/folder
Final .mh_sequences
cur: 18
pseq: 18
unseen: 18
Hm. I suspect there may be an interaction between the mark
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
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
Ken's theory seems most likely. Can you step through in a debugger
after
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
Jerrad wrote:
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 :-/
Try feeding mhstore from a file instead of a message, something like:
FILE=`mhpath $MSG`
for PART in
20 matches
Mail list logo
