Re: [Nmh-workers] mhfixmsg on a pathological mail

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. That's why there's

Re: [Nmh-workers] mhfixmsg on a pathological mail

ralph wrote: > Hi Ken, > > > Huh, the HEADERS have ^M on them? > > I've reproduced similar symptoms with an mhbuild-produced email where I > tacked on CR to the end of every line after the blank line after the > headers. IOW, without the headers having CR. However, I still think > this

Re: [Nmh-workers] mhfixmsg on a pathological mail

Hi Ken, > Huh, the HEADERS have ^M on them? I've reproduced similar symptoms with an mhbuild-produced email where I tacked on CR to the end of every line after the blank line after the headers. IOW, without the headers having CR. However, I still think this is an invalid format email; why

[Nmh-workers] mhlist(1) with message/external-body Duplicates.

Hi, This is OK. $ mhlist -noverbose msg part type/subtype size description 8394 multipart/mixed363 1 text/plain 6 2 message/external-body 93 application/octet-stream $ But my

Re: [Nmh-workers] mhfixmsg on a pathological mail

Hi Håkon, > Trying by hand gives: > $ unlzma ./test/testdir/tmp/11.tar > ./test/testdir/tmp/11.tar: unknown suffix -- unchanged ... > My lzma command comes from debian package lzma-9.22-2. I've pushed this to the master branch and cherry-picked it to 1.7-release. commit

Re: [Nmh-workers] Minor Thing About the Welcome Message.

Hi, > Good point. I'm not too sure either; it depends what the current > needs are... So my email above had this part to it, that made it through the list back to me. > Content-Type: message/external-body; access-type="url"; > url="dict://dict.org/d:yagni:foldoc" > > Content-Type:

Re: [Nmh-workers] Minor Thing About the Welcome Message.

Hi, > Good point. I'm not too sure either; it depends what the current > needs are, or what they would be if the code was nicer. Options > include: just using atexit(3); ... With good timing, this just cropped up. With gcc 4.9.2, `-O -D_FORTIFY_SOURCE=2', on 1.6-branchpoint-1494-g23645d5, I

Re: [Nmh-workers] mhstore dumps core

Hi David, > > valgrind here, 3.13.0-2, doesn't complain about the printf, and that > > prints zero. That puzzles me. > > Yes, interesting. Have you tried with -O0? gcc 7.1.1-4. valgrind 3.13.0-2. With -D_FORTIFY_SOURCE=2: -O0 Compile fails; optimisation needed. -O2

Re: [Nmh-workers] Minor Thing About the Welcome Message.

Hi David, > > There are probably various valid paths where a program exit(0)s that > > don't write the context file. > > Yeah, yet another unification target. Germany's was a cinch compared. :-) > > sbr/done.c's done is a file pointer that often points to exit(3). > > Is it just a poor man's

Re: [Nmh-workers] mhstore dumps core

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. >

Re: [Nmh-workers] Minor Thing About the Welcome Message.

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

[Nmh-workers] Minor Thing About the Welcome Message.

Hi, I've been doing `inc -version' before and after upgrading the installed nmh as 1.7-release changes to check it went OK. I noticed this behaviour. $ cat ~/mail/context Current-Folder: inbox Version: nmh-1.7-RC2 $ sed -i 2d ~/mail/context $ $ inc -version

Re: [Nmh-workers] mhstore dumps core

Hi, David wrote: > Ken wrote: > > And dang, coming up with a test for the url external-body type is > > going to be a pain. How about Content-Type: message/external-body; access-type="url"; url="http://google.com/robots.txt; Could have https too. They could be skipped if a curl(1)