Tom wrote:
> David Levine writes:
> > After the file is opened and read, it's lseek'd. Is (or
> > was) it necessary, or advised, to do an fseek between the
> > subsequent fdopen and ftell?
>
> "Opened and read"? I thought you said w+ ...
I go
Hi,
Fedora 18 was released yesterday. par is available for it:
$ sudo yum install par
And it should remain available for succeeding Fedora releases.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinf
Hi,
Unless there's objection, I'm going to deprecate msh(1).
Here's why. Starting with the man page:
nmh commands operating on a single file in packf'd format.
That is, msh is used to read a file that contains a number of
messages, as opposed to the standard nmh style of reading a
number
Norm wrote:
> % folder +/tmp/inbox
> /tmp/inbox+ has 20 messages (1-75).
> % sortm
> sortm: can't parse date field in message 66, continuing...
> sortm: can't parse date field in message 67, continuing...
> sortm: can't parse date field in message 68, continuing...
> sortm: can't parse date field
Ralph wrote:
> > sortm: can't parse date field in message 66, using file mod time, continu
> ing...
>
> "sortm: 66: resent-date not understood; will use mtime"
>
> "continuing..." seems superfluous.
OK, but I think that we should keep the original beginning, so:
sortm: can't parse dat
Ralph wrote:
> I know, that's why I showed what header was failing, in
> this case `resent-date' rather than plain old `date'. :-)
> Or is the `date field' not hard-coded and actually showing
> the datefield was `date' in this case?
Yes:
admonish (NULL, "can't parse %s field in message %d", d
Paul F. wrote:
> not all MH users are programmers. i like "file modi[fi]cation time" better
> than "mtime".
Agreed.
David
__
The information contained in this e-mail message and its attachments are
intended only for the perso
Hi,
The m_getfld() rewrite is finished and the branch merged to
master. Reviews welcome:
git diff -w --color=auto dbe9e9eb 0bfb53a2 sbr/m_getfld.c
Or until there's another change to m_getfld.c:
http://git.savannah.gnu.org/cgit/nmh.git/diff/sbr/m_getfld.c
There is a small performance penal
Ken wrote:
> Ok, I'm wondering about this ... I see that the big
> difference at least from a system call trace is the calls
> to lseek(), which I guess are resulting from calls from
> fseek() or ftell(). So do a lot of nmh programs use
> fseek() to change the stream pointer mid-stream? I ask
>
Norm wrote:
> I only understand about every 70% of this discussion, so I
> am talking out of turn, and and maybe nonsense. But to the
> extent I understand the discussion, you guys are investing
> time and effort to make nmh faster.
The bulk of the investment has been to make nmh easier to
enhanc
> So do a lot of nmh programs use fseek() to change the
> stream pointer mid-stream? I ask because maybe
> (the programs that care about that could tell m_getfld ()
> that they do care about that).
Done with a very minor code addition. I also reduced
m_getfld's internal buffer size from 8K to 4K
I wrote:
> 4K is also the stdio buffer size on Linux.
Let me correct that. That buffer size is 8K, but reads
appear to be in 4K chunks. And m_getfld() uses fread(),
so it depends directly on glibc, not Linux.
David
___
Nmh-workers mailing list
Nmh-w
Valdis wrote:
> On Sun, 27 Jan 2013 10:34:54 -0500, David Levine said:
>
> > sortm: can't parse date field in message 66, will use file mtime
> >
> > The user can select the field to use for the date with
> > -datefield. And I'd like to be clear about
Robert wrote:
> I know that it should display as "foobar" - the RFC is kind of
> weird, it says "for display purposes" (or similar) in several
> places, which implies that for other purposes the words are
> not considered as one.
It doesn't imply that to me.
> I kind of suspect that they just di
> I personally think we should work around this problem like
> other MUAs, but others did not agree.
The nmh way could be to add a -ignore-errant-header-fields
switch, more briefly named.
Or, I've been having fleeting dreams of writing a message
fixup program. I now have to handle messages that
Ken wrote:
> See now why I wanted to get rid of that MD5 code? :-)
Fine by me. It's only used in the test suite to verify the
integrity of the input files.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/lis
Ralph wrote:
> pick's not up to the job, generally, we know but
>
> pick -datefield resent-date -date bad
>
> to find them. -date already has a variety of non-date special values.
A -check switch was recently added to sortm, that might
be more intuitive. (And -date bad doesn't seem to wor
Lyndon wrote:
> On 2013-01-31, at 6:28 AM, David Levine wrote:
>
> > ap -format '%(decode{text})' \
> >'=?us-ascii?q?=66=6f=6f?= =?utf-8?q?=62=61=72?='
>
> Gives:
>
> foo =?utf-8?q?=62=61=72?=
Per Ken's message, how about prepending
Lyndon wrote:
> lyndon@nemo:/u/lyndon/src/nmh/head> LC_CTYPE=en_US.UTF-8 uip/ap -format '%(de>
> foobar
Great, the test did its job. If you want to see properly
decoded UTF-8 headers, set your LC_CTYPE or higher level
(LC_ALL, LANG) environment variable. I don't know if
en_CA.UTF-8 will work.
Lyndon wrote:
> In the interest of getting a bit wider build/test coverage than just
> Linux, I've set up a small buildbot cluster.
Very, very cool.
For whatever reason, it's not happy with tests that refer
to bands:
Ken, getcwidth apparently reports 0 but the Spinal Tap test
still fails.
I do
Lyndon wrote:
> But this raises a separate issue. If a system doesn't
> support iconv, should the tests flag things like the
> test-pick example as a FAIL?
I think so, otherwise you might not have noticed.
David
___
Nmh-workers mailing list
Nmh-worke
Lyndon wrote:
> So this means we *require* iconv to build nmh?
No, it means that the test suite could let the user know if
nmh in their current locale can't handle UTF-8.
David
__
The information contained in this e-mail messag
Ken wrote:
> on whether or not you're using GCC. And hmm, you know, -ansi is
> already conditionalized with GCC, so I'm wondering what is going wrong
> there; in a perfect world, it shouldn't be adding -ansi to that.
We shoved it in last year, along with -pedantic, in
an effort to maintain
To list what's in your sendmail queue:
# sendmail -bp
It should also show you where the queue is, likely
/var/spool/mqueue/
You can use your big "rm" hammer to remove the files that
are there, AND that pertain to the error message. There
should be two. I'd look at them first so you don't rem
Norm wrote:
> # sendmail -bp
> Mail queue is empty
As Ralph noted, you're using postfix. So, "postqueue -p"
should list the queues and show the message id(s). That
need not be run as root. root can use
"postsuper -d " to remove messages.
David
___
Ken wrote:
> Hm, okay, I _think_ I see it. The problem isn't sending
> to your original recipient, it's with the cc to yourself.
> And adzone.com is your MX record, so that explains the
> received headers. But I don't know why it kept happening.
> And I'm a little puzzled how rawbw.com got into
Norm wrote:
> Minor fcc bug or mis-feature: Can't send a message with fcc's but no
> recipients.
You can now (after nmh 1.5) with this mis-feature:
Bcc: /dev/null
What now? send -mts sendmail/pipe
David
___
Nmh-workers mailing list
Nmh-workers
I've been getting text emails with only a text/html
Content-Type, with no alternative text/plain part.
Microsoft Exchange and Outlook have settings to do that:
http://technet.microsoft.com/en-us/library/aa998896(v=exchg.65).aspx
http://support.microsoft.com/kb/323195
This is so annoying (/rud
Ken wrote:
> Although, if you're grep'ing for something, you'd think you'd
> still find it in text/html (if it wasn't base64-encoded).
Might as well go to text/plain along with decoding.
Even Q-P is bothersome, esp. for replying.
> Perhaps we should think about extending pick to decoding
> base6
Paul wrote:
> david wrote:
> > My thinking at this point is to make the guts of the
> > fixer-upper available to repl and forw. I hadn't thought
> > about pick but it should be able to use them as well.
>
> are you picturing a one-time "fix this message" command, which leaves
> it greppable,
Ken wrote:
> With Lyndon's work on the buildbot (thanks, again!)
+many
> Okay, seems clear enough. But I'm wondering what the "right" solution
> is here. Should we simply convert things like the format engine over
> to use unsigned char for everything? Considering that we're starting
> to sup
Ken wrote:
> >Thinking a bit more about pick: I'd expect a pick that had
> >to decode and translate via an external program on the fly
> >would be way too slow. I grep through 10's of 1000's of
> >messages at a time. I definitely want the permanent message
> >modification.
>
> Yeah, but why wo
Ken wrote:
> The real problem is this: while unsigned char is required
> to prevent sign extension from happening when using the
> ctype macros (because they take int), every OTHER string
> function takes an unqualified char *. E.g., strcpy,
> strcmp, mbtowc(), etc etc.
>
> So you ended up with
Lyndon wrote:
> But to what benefit? I.e. where is the gain in using
> "unsigned char" rather than just reverting to "char"
> everywhere. This is what the C library uses for for its
> string and stdio functions.
I see two broad approaches to dealing with the issue:
1) use unsigned char everywh
> >It would solve the warning, but not the bug in the code, which is
> >the missing explicit cast to int required to match the is* function
> >prototype.
>
> Is that required? Won't the prototypes for the is* functions take
> care of it?
No and yes. Cast of any char flavor to an int is not
requ
> >I prefer the first because 1) we deal with chars that we,
> >within nmh, always interpret as unsigned,
>
> Do we? I was looking at that and _in my brief
> examination_ I saw that we mostly don't do math on them,
> except in a few ASCII-specific cases. But I could believe
> I missed it.
I mea
Ken wrote:
> (If I was voting, I will confess that I think the prototype of
> m_getfld() should be changed, but like I said, it's totally your
> call).
I agree with that, assuming the move to char. There's only
one isspace() in m_getfld(). Other than that, everything in
m_getfld() would be a st
Mark wrote:
> Just to confirm...we're both talking about using the Message-ID
> header as the basename for the saved copy of the original message,
> not the message number as used by nmh?
I was thinking the message number. But I like Message-ID,
great idea.
> Hmmm... I've never filed a bug repo
> >Especially if we get the compilers to flag missing casts.
>
> I think we're going to have to do some work on that front;
> I don't see how to make that happen out of the box on some
> systems. Tom Lane explained how he checks for that; Tom,
> you willing to test out nmh on that system for us?
Ken wrote:
> [Lyndon wrote:]
> >FWIW, nedmail and friends on Plan9 punt in text/html by piping the
> >part through htmlfmt(1).
>
> htmlfmt is a Plan 9 thingy, right? FWIW, for replyfilter I borrowed
> a page from mha-mhedit and use w3m to translate HTML to plain text;
mhfixmsg builds on mhshow,
Ralph wrote:
> Hi David,
>
> I'm not a w3m user but I think that formats the HTML into text?
Yes, but it handles any text.
What do you use for HTML, if anything? It looks like I'll
have to figure out if whatever gets used does the charset
translation or not.
> I was interested in a base64 win
Harald wrote:
> [Ralph:]
> > I'm not a w3m user but I think that formats the HTML into text? I was
> > interested in a base64 windows-1252 text/plain staying as text/plain but
> > utf-8 and 8-bit. IOW, ideal for grep.
>
> Me too, but probably that would be a different tool?
Right. Any externa
Ralph wrote:
> Hi David,
>
> > mhfixmsg [+folder [msgs] | -file file] [-outfile file]
>
> Are stdin and stdout required? An `anno -inplace' on an existing
> message would seem adequate.
A filter would be handy with procmail.
> Don't bother backing up stdin, it's transient by definition.
I
Harald wrote:
> I like this scheme for the ease to find the original to any given
> message. The downside seems to be, that originals aren't easily
> accessible from nmh tools like pick.
Backup (,) message files aren't, either, and I view
the originals as similar in that respect. With the Messag
Harald wrote:
> But those who actually want to keep originals for something
> other than just debugging: Will they want to refile etc. them?
>
> I don't know the answer and even if it is "yes", I don't have a
> solution. But I think these things should be discussed, otherwise
> the next day someb
Ralph wrote:
> Why not replace all three with rmmproc; I've already got that doing
> what *I* want. It's a pain it's not used everywhere as it is without
> adding more exceptions.
Good idea.
I'll add a sample rmmproc.messageid script for those who want
something to start from, how does the one
Ralph wrote:
> :-) It also avoids reading the whole of the email. BTW,
> your brackets for tr are actually asking it to
> transliterate an open bracket to an open bracket and so
> on.
Thanks. I avoid sed, tr, etc., as I'm sure you can tell.
> > # Message-IDs should be unique, so there sh
Ken wrote:
> - The MIME parser & other routines are used by a lot of
> programs, but they're not in libmh.a. I guess that's
> historical, but I am thinking that this should be
> cleaned up.
Yes, I've noticed/fixed a few things. As we make more
use of the parser, we'll find more.
> - We d
Ron wrote:
> archive locally using appropriately named MH folders that
> reside underneath my own ~/Mail directory.
It sounds to me like rcvstore(1) would be more appropriate than
inc here. My .procmailrc is littered with actions like this:
| $STORE +nmh-workers
where STORE is defined at t
Ron wrote:
> >The normal way to handle your second problem is to set $MHCONTEXT
>
> OK. To what?
See the mh-profile(5) man page. For your purpose, as I
understand it, that file can be empty. /dev/null should
work.
> Suggestion: In the man page for "inc", perhaps it would
> be a Good Idea to
Here's what I currently have planned for mhfixmsg, comments?
-reformat currently only applies to text parts. For future
expansion, it could require a content type. Though other
types would need a subtype analogous to text/plain.
David
Usage: mhfixmsg [+folder] [msgs] [switches]
switches are
Tet wrote:
> Ralph Corderoy writes:
>
> >>MIME messages are specified in RFC-2045 thru RFC-2049
> >
> >`through'! ;-)
>
> If we're being picky about it, 'to'! :-)
That was a copy and paste from one of the four other man
pages that has "thru". I'll change them all to "to", though
my Am
Ralph wrote:
> It seems exposure to American has had me take `through' as
> inclusive and the Usage note at
> http://oald8.oxfordlearnersdictionaries.com/dictionary/inclusive
> agrees. I'm only pointing this out because I was unsure,
> benefits of a British state education, went off to find out,
Valdis wrote:
> And the exact gotcha involved, from 'nman rcvstore':
>
> BUGS
>If you use the "Unseen-Sequence" profile entry, rcvstore
>could try to update the context while another nmh process is
>also trying to do so. This can cause the context to become
>corru
> >I removed that notice from the man page after 1.5 went out.
> >However, I shouldn't have. Ken added locking to the context
> >and sequences files nearly a decade ago. That addresses
> >file mangling during write, but not possible interaction with
> >other nmh processes.
>
> I did? When I wen
Ken wrote:
> Also, it's always bugged me that you can't specify a CTE
> directly; nmh is actually nice that if you want exact
> control over your MIME content you can do it, but the CTE
> is the one thing you can't specify.
That has the small advantage of not needing to handle a bad
CTE specifica
Ken wrote:
> Are you sure? According to RFC 2045, Section 2.8, NULs are not
> permitted in 8bit data (binary, yes, but we don't claim to support
> that). So I think anything that handles a C string should be fine.
> Unless there's something I'm missing (which is always possible).
You're right.
Ken wrote:
> So now that we have that settled suggestions for syntax for
> selecting a Content-Transfer-Encoding? :-)
"*8bit", etc., is fine.
I assume the most likely use would be to specify 8bit, q-p,
or base64 when mhbuild wouldn't pick one of those on its
own? If I tried to use 7bit or
Ken wrote:
> Also, I've occasionally had to deal with
> "application/x-patch" parts and those are by default
> encoded with base64; I'd rather do 7bit or 8bit.
Looking quickly, I would think that mhbuild would use 7bit
if safe:
case CT_APPLICATION:
/* For application type, use base64
Ken wrote:
> You know, the more I think about it ... how would they
> even know that it kills performance? Maybe it was a big
> deal 20 (or even 10) years ago, but I have a hard time
> believing you'd even notice nowadays.
Esp. with nmh now configuring, by default, kernel-level
locking if approp
Ken wrote:
> I am wondering if the core problem is that there's no real specification
> for what "MH format" mail directories are.
> Should we write one?
We should, I'll help.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.no
Ralph wrote:
> Hi Oliver,
>
> > I find it happens quite often that I receive an e-mail where someone
> > has attached something that is likely to be plain text (such as a
> > diff) but their mail program has marked it as
> > application/octet-stream. Viewing such attachments ends up being a
> >
Ken wrote:
> Obviously locking on the spool file should match whatever
> locking the local delivery agent uses. But let's look at the
> "everything else" case.
>
> Lyndon makes the case here:
>
> http://lists.nongnu.org/archive/html/nmh-workers/2012-02/msg00050.html
>
> That the default sh
Ken wrote:
> As discussed, this prevents sequence file corruption, but doesn't solve
> the race condition you can get with rcvstore. So it occurs to me that we
> should really solve that properly. Solving THAT means that we have to
> lock the sequence file across a read()-change-write() cycle.
Ken wrote:
> So it probably makes sense to there to call seq_read() to read/lock
> the sequence file after all the messages are searched; that will
> reload any changes to the sequence file & write-lock it.
What happens if there were changes to the sequence file,
esp. some that invalidate t
Ken wrote:
> >> So it probably makes sense to there to call seq_read() to read/lock
> >> the sequence file after all the messages are searched; that will
> >> reload any changes to the sequence file & write-lock it.
> >
> >What happens if there were changes to the sequence file,
> >esp. some
Ken wrote:
> Make sense?
Your small examples do, but there's nothing to stop dangerous
concurrent operations, which we're starting to get to:
> >* a "refile" that made a heckuva mess
>
> You're running refile the same time as an "inc" or "pick"?
It can happen, such as with cron jobs.
> I'm tr
Ken wrote:
> Yeah, but until (relatively) recently, that could result
> in corrupted sequences. I'm just trying to imagine how
> people could be doing that since it can break, today.
They live with it, I suppose. I don't rely on sequences
for anything important.
(And shouldn't that be "now" in
Ken wrote:
> - The "complex" case, where the sequence file could
> potentially be changed from the time that it's first
> read until the sequence file needs to be manipulated.
> "inc" is an example; "pick" is another.
Is sortm in the same category as folder -pack?
> The basic issue there i
Ken wrote:
> AFAICT, if you reread the sequences file, that will solve that
> problem. I cannot think of a scenario when it does not; can
> you think of one that doing that will fail?
Not off hand, but I can't get beyond "merge conflict".
> Programs that use folder_addmsg() are safe to run conc
Ken wrote:
> >> AFAICT, if you reread the sequences file, that will solve that
> >> problem. I cannot think of a scenario when it does not; can
> >> you think of one that doing that will fail?
> >
> >Not off hand, but I can't get beyond "merge conflict".
>
> Maybe you're thinking of it wrong.
>
Kevin wrote:
> This is the last piece of the puzzle. I need to basically write the
> predicate "is message N in sequence S?" Ideas on how to do that?
> I've combed the man pages and haven't found a way, yet. Ideas
> welcome.
There isn't an easy way. Maybe use mark -list to get all
sequence na
Kevin wrote:
> What do you think about this functionality being added natively to
> refile? Possibly via a command line switch? -retain-sequences or
> something.
Done, here's the interesting part:
/*
* Copy sequence information for a refiled message to its
* new folder(s). Skip the cur sequ
mhfixmsg(1) has been committed. Thanks, everyone,
for your inputs.
There's an example procmail setup in the man page.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Jerrad wrote:
> Incidentally, although attempts to autogen.sh will warn you about
> the minimum autoconf version (though it's not in INSTALL), there is
> no similar warning about automake version requirements. Instead,
> one receives a random warning about color-tests.
Just curious, what version
Jerrad wrote:
> Would it be possible to expose rmmproc as an option for rmm?
> Just a thought, though I understand if it seems like
> Yet Another Switch
I had that feeling when putting rmmproc support in mhfixmsg.
But, I agree that it would be useful. Unless there's
strenuous objection, I'll ad
Ken wrote:
> It seems reasonable to want to be able to invoke nmh commands from
> rmmproc, although that was never clearly defined as reasonable (or
> even if it was expected to work).
I think this man page note indicates that it was considered
reasonable, though hazardous without some minimal ca
Ken wrote:
> >> - Do nothing. Not as weird as it sounds; if messages aren't on the
> >> sequence, they'll get removed next time the sequence file is written.
> >
> >Yes but an intervening folder -pack would mess that up.
>
> Actually, it would work out fine. If messages don't exist they won't
Norm wrote:
> If foobar is a message sequence then something like forbar+3, for
> the third message of foobar, would make my life a bit easier.
>
> Even better, would be to allow forbar+3,4 and foobar
> forbar+3-5. Then, recursively, and perhaps a bit fancifully, since
> forbar+3-5 is a message se
Norm wrote:
> The mark man page (version nmh-1.5) has:
>
> 'As expected, the command "mark -sequence foo -delete all" deletes the
> sequence "foo" from the current folder.'
>
> I think that what is meant is
>
> 'As expected, the command "mark -sequence foo -delete all" deletes all
How about this:
As expected, the command "mark -sequence foo -delete all"
removes all messages from the sequence "foo", and
therefore removes that sequence from the current folder.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
h
Valdis wrote:
> On Mon, 25 Mar 2013 18:50:59 -0400, Paul Fox said:
> >
> > how about
> > As expected, the command "mark -sequence foo -delete all" empties
> > the sequence "foo", and therefore removes that sequence from the
> > current folder.
>
> "from the current folder's list of se
Ken wrote:
> But clearly the "MH way" was to silently discard sequences that
> exceeded the per-folder limit. That doesn't mean that it should
> always be the way, of course.
It'd be nice if it wasn't that way.
And I also think that nmh shouldn't have such a low limit on
the number of sequences
Ken wrote:
> M. Levinson sent me private email and pointed out that it's not QUITE
> a one-line change; some casts are needed in the sequence macros to
> prevent bit-shifts from overflowing an int. He was kind enough to
> send me patches that did that, so I'll probably integrate that today
> alon
> >Would that bring us to where a 32-bit executable could lose
> >information created by a 64-bit executable via a common sequences
> >file? If so, either we shouldn't do it, or should add code
> >to protect against the loss. It's wrong to allow silent loss.
>
> I assume you mean "sizeof(seqset_
> >That happens on both 32- and 64-bit Linux. So as of right
> >now, with your new locking code, I don't need to worry about
> >losing any sequence information, right?
>
> I believe so (fun fact; the old locking code released the lock on the
> file before it called fclose(). Whoops). But when y
Michael wrote:
> Can anyone think of a reason why using fd_set isn't just the right
> thing? It is 1024 bits on most systems (256 on others), and a #define
> usually lets it get bigger.
If it's a different size on different systems that share a
sequences file, then we're back to the risk of sil
Lyndon wrote:
> The next step is for someone who really feels 27 sequences is
> a hindrance to replace the uint32_t with a variable-length bitfield.
Done. No more limits, except for virtual memory, on the
number of sequences in a folder.
David
___
Nm
This old bug is about post ignoring a login name in .netrc:
http://savannah.nongnu.org/bugs/index.php?23168
I had closed it, but I really think that it should be fixed.
The current behavior is to determine the user using the
first of:
1) -user switch
2) local login name
I'd like to change
Lyndon wrote:
> .netrc isn't the right mechanism. Its long-standing use is for
> mapping "system" login credentials for things like telnet and ftp.
> If, as you state, pop account names are becoming divorced from login
> names, then it would be impossible to use .netrc for both pop and
> ftp acco
I wrote:
> This old bug is about post ignoring a login name in .netrc:
>
> http://savannah.nongnu.org/bugs/index.php?23168
>
> I had closed it, but I really think that it should be fixed.
> The current behavior is to determine the user using the
> first of:
>
> 1) -user switch
> 2) local
c22bc2bd4e417e8 (master~193^2~6^2~31)
> Author: David Levine
> Date: Sun Jan 13 11:08:28 2013 -0600
>
> Added bytes_read to m_getfld() buffer state. This is the
> next step in supporting ftell()/fseek().
>
>
> you can see that the last several c
nd the first failing commit is:
> >
> > commit f6e6ec96c9e179f7817fca4c8c22bc2bd4e417e8 (master~193^2~6^2~31)
> > Author: David Levine
> > Date: Sun Jan 13 11:08:28 2013 -0600
> >
> > Added bytes_read to m_getfld() buffer state. This is the
> > next step in support
Paul F. wrote:
> certainly. i've already done man pages and tests. i'll do find the
> pending notes and do those too.
Thank you for paying attention to those details.
(docs/pending-release-notes)
> is "make check" the only way to invoke the tests? i couldn't see
> an easy way to invoke just
Ralph wrote:
> Hi Paul,
>
> > as a convenience feature when typing negative offsets, "foo:-n" and
> > "foo=-n" can be entered as "foo::n" and "foo==n" respectively.
>
> I dislike this. Must be my preference for Python's `one way to do it'
> over Perl's `there must still be one more way we haven
Paul F. wrote:
> so it looks to me like this command:
> /home/pgf/src/pdom/nmh/nmh.git/test/testdir/inst/usr/local/nmh.git/lib/sl
> ocal -maildelivery /home/pgf/src/pdom/nmh/nmh.git/test/testdir/Mail/maildeliv
> ery
> should have produced the .actual file, but didn't. the contents of that
> m
Paul wrote:
> WARNING: /home/pgf/src/pdom/nmh/nmh.git/test/testdir/Mail/maildelivery has
> bad ownership/modes (su=0,uid=1000,owner=1000,mode=0100664)
> (delivering to standard mail spool)
So you have a umask of 0002?
I'll add this to the test, that should fix it:
@@ -78,0 +79 @@ EOF
+chmod go-
Lyndon wrote:
> On 2013-04-18, at 8:16 AM, David Levine wrote:
>
> > So you have a umask of 0002?
> >
> > I'll add this to the test, that should fix it:
>
> Why not set an explicit umask instead?
I prefer that the test suite not hide other situations whe
Ralph wrote:
> Hi,
>
> $ mhlist
> msg part type/subtype size description
> 19696 multipart/alternative 4785
> 1 text/html 2787
> 2 text/plain1680
> $
>
> The email has subtype plain first, then htm
Lyndon wrote:
> Or have the script take a message number and let it
> extract the invite attachment for you.
>
> I can't image you receiving a message with more than one invite in
> it, so if message 100 contains the invite, the rsvp script could
> accept a message number, dig in to find the appr
301 - 400 of 1610 matches
Mail list logo
