Jon wrote:
> Ralph Corderoy writes:
> > When implementing this, was there a reason whatnow doesn't implement
> > `cd' with chdir, as normal Unix commands that offer cd do, and instead
> > "fake" it for `pwd', `ls', and `attach', but not `mime', etc?
>
> Well, the most honest answer that I can give
hymie wrote:
> But it seems like there is something I'm missing, that will enable
> mhshow to say "Oh, base64 and pgp-encrypted. I should use the
> 'gpg2 -d %F | less' command to show this part"
Here are some pieces, in addition to gpg-agent, that might help:
1) I think you're looking for this
Tom wrote:
> $ pick automount -list |xargs -n1 show |egrep -i '^messagename' |head
> MessageName: (Message ipa:378)
> MessageName: (Message ipa:437)
> MessageName: (Message ipa:438)
> MessageName: (Message ipa:451)
What's the output from "show automount |egrep -i '^messagename' |head" ?
David
_
Tom wrote:
> $ folder;command show automount | egrep -i '^(messagename|X-Envelope-From)'
> |head -4
> ipa+ has 4706 messages (1-4706); cur=4706; (others).
> X-Envelope-From: freeipa-users-boun...@redhat.com Fri Apr 29 16:01:46 2016
> X-Envelope-From: freeipa-users-boun...@redhat.com Mon May 2
Paul F wrote:
> oh: it looks like "mhparam -all -debug" might give everything.
This is kinda interesting. -debug is currently ignored with -all.
It wasn't before commit 234c9cc4, which replaced a badly formatted
conditional statement with an else branch. Instead, it could be
changed to be two
Ken wrote:
> And because of changes to email protocols over the past few decades,
> you end up needing more and more knobs for SMTP (controlling TLS, SASL,
> certificate validation, XOAUTH2 parameters, and who knows what else we
> will have in the future). I'm unsure how much of that stuff we wan
Ralph wrote:
> Anyone know why nmh uses ~/mail instead of /tmp? The latter may well be
> tmpfs so no disk is hit, and cleaning it isn't nmh's problem.
Not off hand. It looks like $MHTMPDIR was introduced between MH 6.8.5
and the entry of nmh into CVS. MH 6.8.5 hard-coded the use of /tmp/.
The
Lyndon wrote:
> > On Mar 5, 2017, at 7:26 PM, David Levine wrote:
> >
> > Not off hand. It looks like $MHTMPDIR was introduced between MH 6.8.5
> > and the entry of nmh into CVS. MH 6.8.5 hard-coded the use of /tmp/.
> >
> > The thread beginning at
> &
Ralph wrote:
> 6.8.5 was right; /tmp can be hardcoded.
I'd be fine with that. We'd have to deprecate the current behavior,
as you noted. The test suite uses MHTMPDIR but that shouldn't be hard
to change to TMPDIR.
David
___
Nmh-workers mailing list
Ken wrote:
> maybe the "right" fix is to properly bubble up read errors from m_getfld()?
I agree, and would be willing to visit that after 1.7. I think that all callers
should be able to handle the error, but I'm not certain.
In the meantime, how about the fix below to parse_mime()? That shoul
> +'Forwarded Message' delimiters are not added.
That line in the man page causes the test-manpages to fail:
+ man1/forw.1:344: warning: macro `Forwarded' not defined
on Fedora 25.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https:/
Paul F. wrote:
> the patch looks fine to me, though the comment could be modified a
> bit, or moved. do you need me to test it?
Thanks, I cleaned it up and committed it. It works for mhshow, mhfixmsg,
mhlist, and mhstore for me.
David
___
Nmh-worker
Larry wrote:
> Does this fix it?
Yes, thanks! Patch applied.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ralph wrote:
> Hi Larry,
>
> > Can I get a ruling, please, on the use of 'maildrop' vs 'mail drop' in
> > the man pages?
>
> Google's Ngram's viewer clearly favours "mail drop".
>
> So do I, with it being hyphenated as a compound adjective, e.g. "a file
> in mail-drop format".
+1
David
Ralph wrote:
> The newly created messages will have a mode of 0600, see chmod(2),
> on filesystems that support it.
> A Msg-Protect profile entry gives the mode to use instead, in octal.
+1
David
___
Nmh-workers mailing list
Nmh-workers@no
Ralph writes:
> Hi Larry,
>
> > ali \- list *nmh* mail aliases
> > anno \- annotate *nmh* messages
> > comp \- compose an *nmh* message
> > mark \- manipulate *nmh* message sequences
> >
> > Is this just silly, or shall I proceed?
>
> +1, ignoring those where it's too awkward to shoehorn nmh in.
Jon wrote:
> OK, thanks. I'm running FC25 linux and have experienced this on earlier
> versions. I'll try to track it down someday.
I haven't seen this with FC25 or prior versions. Maybe try from /bin/sh or
"env -i bash --noprofile --norc" or whatever to see if it's something in your
shell.
D
Valdis wrote:
> It appears to be in the same class of faults as another bug I
> reported a while back with handling of null bytes in mhfixmsg -
> the failure symptoms appear to be dependent on the amount of
> input.
Just to note: that problem was due to use of strlen(3) in the MIME
parser, which
Larry wrote:
> We - you, David and I - went through this on this list already. I,
> ultimately, took David's advice, which backed up his many requests
> to me to change the dates.
I think that I had interpreted the guidance on when to change dates
differently. I apologize for that. Though at th
Ken wrote:
> Hm, that script was put there by David, but it was never added to the
> appropriate line in Makefile.am.
Fixed, thanks.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ralph wrote:
> > [Valdis:]
> > I can re-create the `-width 137' spew with git, but not with 1.6.
> > That suggests a bisect might help
>
> So git-bisect(1) blames
>
> commit e537b780f7aea8df01ddca1976f8c128d9c1fb55
> But I suspect it's wrong and that just pushes the 137 to trigger the
> error
Ken wrote:
> Normally I would suggest deprecating this feature and then removing it
> after the next release, but it's impacting reasonable behavior NOW, and
> fixing the core dump issue here just means trying to comprehend a pile
> of code that's just a mess and that we all agree needs to go. So
Ralph wrote:
> Hear, hear. I've now committed all of Larry's patch emails to git bar
> one; it was adding a trivial example to the start of mh-alias(5). I've
> then gone back through the git history of every man page looking for the
> recent commit that was a significant change and altered `.TH
Ralph wrote:
> I'm happy to make all those lines be tabs followed by spaces, preserving
> the indentation, but don't want to cause `git pull' hassles if there's
> large un-pushed commits out there. Objections?
No objection from me. Though I wonder if we should wait until after 1.7.
> Also, I a
Ralph wrote:
> If we are going for wholesale spaces-for-indent then that's probably a
> soon-after-1.7 job.
+1
> Talking of 1.7, I think there are some things that were marked
> deprecated in 1.6 that could get the chop before 1.7...
Such as?
David
Ralph wrote:
> Well, that was just based on a little search the other day when I was
> looking for example of how to deprecate something. One is
>
> $ git blame -s 8a14191c0^ uip/send.c | grep deprecated
> 521674623 305)advise(NULL, "The -attach switch is
> deprecated");
Ralph wrote:
> Except mhn, which has been stated as deprecated in its documentation
> as far back as git stretches. Time to wield the axe!?
I'd prefer to wait for the release after 1.7. I use mhn to get
different behaviour from mhshow without a separate profile. I
could adapt to the loss, of c
Ralph wrote:
> I don't know how many read past the interesting "new features"
> bit. As it's probably brief, perhaps "deprecated features"
> could be first, headed by a warning saying notice is hereby
> given.
Good idea.
> I wonder if there's anything listed as deprecated in NEWS for 1.6 and
>
kre wrote:
> The one argument for keeping mhn in 1.7 is that it allows nmh 1.7 to
> be released soon, without needing to depend upon an updated exmh being
> released first
Another argument is that it is good practice to remove a program early
in the release cycle rather than at the end. While we
Ralph wrote:
> Firstly, is that a valid VCALENDAR? Is the event 31 minutes long?
That was the intent. I think you're right, the To: should be to 0330,
not 0230.
> Would it be better to ditch DST from the calculations, and make EDT -400
> above? Then it wouldn't need adjusting again on formatt
Valdis wrote:
> How compatible are the directives handled by mhn and mhbuild?
mhn execs mhbuild under either of these conditions:
1) The -build switch is passed to mhn.
2) Both the mhdraft environment variable and the single argument
to mhn are the message number of the draft.
I don't see tha
Valdis wrote:
> If users are supplying their own in-line #whatever directives, and
> mhn does *not* call mhbuild, but does its own processing,
I don't know what exmh is doing with mhn, but I assume that it
gets mhn to exec mhbuild using one of its two methods. If so,
then build directives are pr
Ralph wrote:
> 80a9e99f7078199500d2d53c8d77d1b92af06fbc added an assert(3) as part of
> the -width-overflow fix for Valdis's email.
Right. If w < 0, bad things happen in the code just following. If
w can indeed be negative there, maybe that code block should be simply
skipped.
> any problems,
I wrote:
> Right. If w < 0, bad things happen in the code just following. If
> w can indeed be negative there, maybe that code block should be simply
> skipped.
How about this:
@@ -300 +299,0 @@ cpstripped (charstring_t dest, size_t max, char *str)
- assert(w >= 0);
@@ -302,2 +301,4 @@ c
Valdis wrote:
> Oh, good. In that case, it's trivial to replace it with mhbuild.
Should be. And also mhn -store with mhstore.
> (Part of the problem has been that I have a too up to date install of nmh,
> and thus
> no mhn manpage remaining that says more than "deprecated".
You'd have to go
Ralph wrote:
> But only by the time wide_char may have been written by a second mbtowc().
Oh, good catch! Your patch looks good.
I noticed that the altstr = NULL; in cptrimmed(), line 197, is inside the
w >=0 block. I think it should be outside.
Also, altstr is misspelled as alstr in the comm
Ralph wrote:
> Hi David,
>
> > I noticed that the altstr = NULL; in cptrimmed(), line 197, is inside
> > the w >=0 block. I think it should be outside.
>
> The else block for that condition effectively returns so the un-NULL'd
> altstr isn't used again. (They should be swapped. :-)
That's in c
Tom wrote:
> $ pick -to mytkhcsh
> pick: no messages match specification
That's due to this hard-coded limit in picksbr.c:
#define LBSIZE 1024
#define ESIZE 1024
static char linebuf[LBSIZE + 1];
static char decoded_linebuf[LBSIZE + 1];
We should replace that with dynamic allo
Ralph wrote:
> I think a limit so large that a breach suggests something's gone
> wrong, or it's a corrupt email, e.g. 100 KiB. But that obviously
> shouldn't be allocated each time; it should grow to that as
> needed. This will all be m_getfld() I assume? Ken's nememsis?
I would avoid touch m
Hi,
I just added this to the send(1) man page:
Beware that if no “Fcc:” folders exist and the default
fileproc and postproc are in use, then refile will prompt
the user to create the folder(s) if -push is not
specified. If all responses are negative, or creation of
each folde
Valdis wrote:
> On Thu, 11 May 2017 20:25:52 -0400, David Levine said:
> > Hi,
> >
> > I just added this to the send(1) man page:
> >
> > Beware that if no “Fcc:” folders exist and the default
>
> Does that mean "if no folders have been specified
Ralph wrote:
> ./configure with CFLAGS including -DBUFSIZ=225.
Then don't do that? :-)
I suspect that m_getfld() might be involved. I wouldn't
recommend trying to fix it. If you want to do something, #error
if BUFSIZ < 226 or something like that?
David
___
Ken wrote:
> If not, maybe we could squash those bugs from Ralph and then start the 1.7
> release cycle.
+1
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ralph wrote:
> man5/mh-profile.5 ← man/mh_profile.man
> man5/mh-tailor.5 ← man/mts.conf.man
>
> The files they document are $HOME/.mh_profile and /etc/nmh/mts.conf. I
> don't think mh-profile(5) and mh-tailor(5) should exist or be referred
> to; it's just confusion and clutter. May they
Ralph wrote:
> Hi Ken,
>
> > I think this is long-obsolete, and I propose we remove it.
> > Objections?
>
> Nuke.
+1
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ken wrote:
> Maybe we could develop some quick performance measuring tools; might be
> worth some time, and we'd all be working from the same source?
+1
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinf
Norm wrote:
> post (or maybe send) ignores extra commas before, between, after, or
> instead of addresses.
It is post, specifically the hand-crafted address parser in sbr/mf.c.
> I don't know whether this feature is intended or not, but I hope it stays.
I think it's a potentially useful feature
When processing directives from repl -convertargs, mhbuild used to
inhibit use of quoted-printable for text content. I just removed
that. Now, the encoding is selected based on content, just as it
is for all other message content. The user still has control over
the use of quoted-printable via
Norm wrote:
> I find it to be more than little useful in simplifying scripts. I
> hope that the feature stays, even though it's undocumented.
I have no desire to remove it. (Or document it. :-)
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.or
Ken writes:
> Ralph has already given you specific answers, but more generally ... yes!
> If you or anyone want to volunteer to do ANYTHING for nmh, it would help!
> No task is too small.
I agree completely.
And I agree that the test suite is a good place to start, and "make gcov"
within that.
I wrote:
> tests/README has some guidelines.
That should be test/README
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Bob writes:
> of recent test coding (though not necessarily as defined template
> for all aspects of testing going forward -- in particular, that
> just checking the exit status is sufficient).
The tests handle exit status differently, it would be nice if it
was unified.
> Note: I've not yet up
Ken wrote:
> Thoughts?
It's been over 3 years and is stable now. Go.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Norm wrote:
> scan applied to an Email like the attached dumps core. I will send more
> particulars, on request.
Doesn't dump core for me, and valgrind doesn't notice anything unusual.
I also tried with your .mh_profile that you posted 16 Nov 2016, with
no problems. If you have updated it since
Conrad wrote:
> packf leaves "..map" files lying around my mail directory; this
> is documented in the man page as a "binary index".
Not after this commit:
commit e6c917710e4318949cb4174cabca51a8d1822dbd
Author: Ralph Corderoy
Date: Thu May 25 13:53:27 2017 +0100
So, how about te
Norm wrote:
> % locale
> LANG=en_US.utf8
So is mine.
Does the following command produce readable output, or a complaint?
$ printf %s
8J+VtlN1buKAmXMgb3V0LCBzYXZpbmdzIE9O4oCUc2hvcCBtYWpvciBhcHBsaWFuY2UgZGVhbHMgbm93
| base64 -d | iconv -f utf-8
David
__
Norm writes:
> inc seems to have a similar, if not identical problem.
It's identical: inc uses the same code to print the scan line.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ralph writes:
> Sunglasses have a width of 1 here, that's why David and I don't see the
> problem.
I'm surprised that I didn't see the same behavior as Norm, because
we use the same locale, en_US.utf8. Any idea why?
David
___
Nmh-workers mailing list
Ralph writes:
> Hi Leonardo,
>
> > At least regarding the `make check' (always on NetBSD/amd64 8.99.1),
> > all 104 tests are passed and 7 tests were not run.
>
> Great, thanks.
Yes, thanks to both of you.
> I guess we'd like a minimal-change fix for this on the 1.7
> branch rather than flip to
Valdis wrote:
> On Tue, 08 Aug 2017 18:04:56 +0100, Ralph Corderoy said:
>
> > I did git-bisect(1) it. Over time, it homed in on the enabling of
> > assert(3)s by default. :-)
>
> Which points at it *always* having been broken..
Indeed, though in this case, that's just since the m_getfld
Leonardo wrote:
> I'll attach in this email a possible trivial patch that should fix
> this issue.
Indeed. Thank you! I added a test to your patch and applied it to
both master and the 1.7-release branch. It looks like it missed
1.7RC2, but I agree that it should go into 1.7.
> Thank you for
Does the -nocrlflinebreaks switch to mhfixmsg help?
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Ken wrote:
> And dang, coming up with a test for the url external-body type is going
> to be a pain.
Uh, yeah. I fixed it and now valgrind doesn't report any problems.
> David, do you recall why the clang static analyzer was complaining about
> that? Also, if you look in all the callers of ope
Ralph wrote:
> There are probably various valid paths where a program exit(0)s that
> don't write the context file.
Yeah, yet another unification target.
> sbr/done.c's done is a file pointer that often points to exit(3).
> Is it just a poor man's atexit(3),
> and should we aim to switch to that
Ralph wrote:
> Or, `python2 -m SimpleHTTPServer $port' gives a HTTP server for files in
> the current directory.
We've avoided dependencies on python, perl, etc., in favor of POSIX tools,
for the most part. I don't know if test/fakehttp would fill the need here,
even with some enhancement.
> Bu
Ralph wrote:
> With -D_FORTIFY_SOURCE=2:
> -O0 Compile fails; optimisation needed.
configure.ac doesn't add -D_FORTIFY_SOURCE if CFLAGS contains -O0, but
that can be easily fooled at compile time.
> So valgrind looks best with -O2, but gcc spots some problems itself at
> -O3 if no
Ralph wrote:
> I don't know if this is the right fix.
I don't either. mhparse is long overdue for a good sanitizing.
> Frankly, after staring at functions that take a pointer to a struct
> with an FILE pointer and a filename, and also a couple of pointers to
> return a filename and a file descr
Ralph wrote:
> Hi Paul,
>
> > isn't that sort of the point of mhfixmsg? to fix poorly or illegally
> > formatted email?
>
> Good point, but I think it uses the stock nmh code for parsing emails
> rather than have it own code that is cluttered with wart handling.
Yes. mhparse works quite nicely
I wrote:
> configure.ac doesn't add -D_FORTIFY_SOURCE if CFLAGS contains -O0, but
> that can be easily fooled at compile time.
configure.ac added -D_FORTIFY_SOURCE to AM_CPPFLAGS. I just changed that
to CPPFLAGS on master, that'll reduce the force with which we (I) try to
impose it. Should I ch
Ralph wrote:
> What's the semantic difference? One can be specified by the user, and
> the AM_* is what configure (automake) works out is required?
Yes, where "works out is required" comes from configure.ac and whatever
it pulls in, rather than configure itself.
> > Should I cherry-pick that to
Ken wrote:
> It looks to me like you have nmh configured to connect to a SMTP server
> running on port 587 on localhost, and there isn't one.
It looks like you got bit by this change in 1.7, Anthony:
- post now defaults to port 587 on 'smtp' message submission.
The -port switch to send(1), post
Anthony wrote:
> Thanks. Since the relay only accepts connections from localhost, I was
> okay with adding "send: -port 25 -notls" and "post: -port 25 -notls" to
> my profile
Note that post doesn't read the profile, so the line you added for it
doesn't do anything useful.
David
Kevin wrote:
> ./test/format/test-myhost: local hostname test expected:
> 'drums.cosgroves.us'
> but instead got:
> 'cosgroves.us'
> FAIL: test/format/test-myhost
That might be an /etc/hosts issue. And that could explain the
test-mymbox failure, too. test/getcanon, which uses
Ken wrote:
> > ./test/mhfixmsg/test-mhfixmsg: test failed, outputs are in
> > /home/local/src/INCOMING/BUILD/nmh-1.7-RC3/test/testdir/Mail/inbox/31 and
> > /home/local/src/INCOMING/BUILD/nmh-1.7-RC3/test/testdir/test-mhfixmsg31454.actual.
> > first named test failure: pass through message with
Jerry wrote:
> Binary files /home/jerry/code/nmh-1.7-RC3/test/testdir/21786.draft and
> /home/jerry/code/nmh-1.7-RC3/test/testdir/21786.expected differ
Can you look at those files and see how they differ?
David
___
Nmh-workers mailing list
Nmh-worker
Kevin wrote:
> In /etc/postfix/main.cf
>
> mydomain = cosgroves.us
> myorigin = $mydomain
nmh won't see that. Do you set localname in mts.conf or your profile?
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman
Ken wrote:
> But in THEORY that shouldn't matter, because we should be
> overriding that configuration by setting MHMTSCONF in the test suite
> which means we should be using that and not an already-existing one.
Except we don't in one place in test/format/test-myhost.
I think that we shoul
Ken wrote:
> What do people think we should do about this? We could make
> Autoconf reject this file command if it returns something other than
> "application/octet-stream" for the "nulls" file.
That would be fine. Or, just leave it. Based on Ralph's research,
it looks like it's been fixed.
D
Ken wrote:
> If it is fixed in newer versions of file and is only triggered by a small
> subset of inputs, I am fine with leaving it.
I don't know if the older version supports ~/.magic.mgc or ~/.magic, but if
it does, maybe that could be used to work around the problem.
David
_
Ken wrote:
> Some people have been recoiling in horror at my attempts to write an
> RFC-822 address parser in Yacc/Bison.
+1
Deciding on a common denominator for yacc/bison, and also lex/flex, could
be a challenge. I'd be OK with just supporting flex and bison.
David
_
Ken wrote:
> Are you recoiling in horror, or think it's a good idea? I can't tell :-)
:-) I think it's a good idea. m_getfld() and its clients are difficult
to maintain and expand.
> >Deciding on a common denominator for yacc/bison, and also lex/flex, could
> >be a challenge. I'd be OK with
Ralph wrote:
> It already has -prefer tests; they now fail. :-)
Just one of them, test-mhlist, failed for me. I fixed it, just on master.
That was trivial, and took the opportunity to migrate the test to
start_test/finish_test.
David
___
Nmh-worker
Ken wrote:
> Fair enough. I suspect that maybe this was the original intent, but
> whatever people intended as the original idea behind group address lists
> seem to have fallen by the wayside. Nowadays you only really see them
> "in the wild" to obscure email recipients.
Yeah, RFC 5322 §3.4 en
Laura wrote:
> could we have a switch that just edits the wretched mail for you
mhfixmsg(1) should do exactly what you want. Specifically, its -fixcte
switch, but that's enabled by default.
Its man page has examples of integration with inc and procmail.
David
_
Ken wrote:
> Hm. I see a lot of "?" in the message body output in scan. It may be that
> we might not be converting THAT part right.
Doesn't that just mean that iconv couldn't convert the characters? Maybe
they weren't valid GB2312, or they couldn't be represented given our locale
(en_US.utf8,
Ralph wrote:
> I've pushed a change and mention both xmh and exmh as "external
> projects" without stating either is available as a package. That
> removes the dependency and likelihood of falling out of date.
Good idea.
One change that I'm not fond of: I think that "command line
interface" sh
Ralph wrote:
> commit 6547ca9f73c3f02b2356017bbd7ff85292f8e4a1
Thanks.
> Can Fedora actually use SPECS/nmh.spec when building, or do they always have
> their own version?
Fedora maintains its own spec,
http://pkgs.fedoraproject.org/cgit/rpms/nmh.git/tree/nmh.spec
nmh's is for users who mi
Ken writes:
> Well, okay, there was one issue reported by Kevin Cosgrove that AFAIK
> was never resolved, where mhfixmsg was failing, mentioned here:
>
> http://lists.nongnu.org/archive/html/nmh-workers/2017-08/msg00180.html
Kevin, so you don't have to extract the test, I attached it to this me
Ralph wrote:
> Ah, and that still has the "If you want to use nmh as a true email user
> agent, you'll want to also install exmh to provide a user interface for
> it". :-( I was hoping to get that altered before 1.7, especially if
> it's years before 1.8.
I'll fix that (I'm one of the Fedora pa
Ralph wrote:
> I recreated your `make check' error, with the 1.7 tar file, but had to
> unpack the tar file inside `/tmp/,A' to do so based on a hunch.
> Can you try unpacking it into /tmp/AA, for example.
Yes, that's it. slocal's split() splits on whitespace and commas:
Each line of this [
Ralph wrote:
> So tee(1) is unhappy with its arguments.
This isn't the fault of tee. The "/tmp/" and
"A/nmh-1.7/test/testdir/6459.actu..." arguments should instead
have been a single "/tmp/,A/nmh-1.7/test/testdir/6459.actu..."
argument.
> To keep the test outputs mentioned in the error messages
Ralph wrote:
> Still probably worth waiting a bit for other faults to appear.
+1
David
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Leonardo wrote:
> (But, I think that this shouldn't matter according my code reading
> of relevant parts of nmh test suite because the test suite correctly
> inject them in the environment.)
Yes, that was the intent.
> And, with NetBSD iconv(1) I have:
>
> % printf '\xe4' | /usr/bin/iconv -f EB
kre wrote:
> (That's a NetBSD system). There's no EBCDIC at all. There are lots of
> others though.
I'm just looking for some encoded characters that can be translated to the
7-bit string "UTF-8", but non-trivially so that we can put iconv to work.
This was easy for me:
Content-Type: text
Steven wrote:
> I've run into a few issues, most of which are trivial (and which I'll
> describe below for the sake of completeness),
Thank you for for detail description. It looks like Ralph has addressed
the substantive issues.
> The other issues I mentioned are:
>
> - It would be really ni
Ralph wrote:
> This is now fixed on the master branch, if Ken or David are happy then
> it can get cherry-picked across to branch 1.7-release.
I don't have any objection, but I'm not sure what the criteria for adding
to the release branch should be. Just fix things that the broke on the
branch,
Tom wrote:
> Possibly related to this: I updated nmh from 1.6 to 1.7 on my RHEL6
> machine last night, using the EPEL package (last touched by David Levine).
> I noticed that it moved all the configuration files from /etc/nmh/ to
> /etc/nmh/nmh/, which seems a tad silly.
And quite u
Ralph wrote:
> Something like `UCS-4LE' would be widespread?
That reveals another problem. The UCS-4LE encoding contains NUL's,
which of course don't play well in C strings. In this case,
content_charset() returns (from get_param()) just "U".
David
--
Nmh-workers
https://lists.nongnu.org/mai
Steven wrote:
> It turns out there are two more such failures in test-mhfixmsg, which I
> didn't see yesterday because I wasn't getting that far.
It looks like Ralph found and fixed all hard-coded uses of the ','
backup prefix, including the three in test-mhfixmsg.
> (Yes, this is
> intended to
Ken wrote:
> If it's not necessary anymore, I'd say remove it (and even if
> it is necessary on FreeBSD 9, I would like to understand why and still
> consider removing it).
I'll remove it now.
> So I think
> we should simply have the defaults be stock Autoconf directories, and
> let users who wa
1101 - 1200 of 1608 matches
Mail list logo
