Re: folders which are numerical names

2024-07-01 Thread Ralph Corderoy
Hi David, > How about this simple addition to identify the offending directory: Passes the ‘First, do no harm’ test. +1. -- Cheers, Ralph.

Re: folders which are numerical names

2024-06-26 Thread Ralph Corderoy
Hi Ken, > This happens because open() failing is considered a "soft" error and > scan will continue, but read() failing is considered a hard error. > I'd be willing to consider read() failing with EISDIR a soft error. > Thoughts from others? It compounds the flaws. The original one was not

Re: folders which are numerical names

2024-06-25 Thread Ralph Corderoy
Hi George, > So I work around it by having archives like sent/y2021 and it works > fine. I have sequences for years within a folder, e.g. y98, and y24. They have to have a prefix to avoid clashing with message numbers as sequences don't have a sigil whereas folders have ‘+’ or ‘@’. But even if

Re: whatnow: problems with edit--draft left

2024-06-12 Thread Ralph Corderoy
Hi kre, Thanks for setting me straight. > > I'm puzzled why g/x/= prints 3 twice rather than 1, 3. > > Add an extra line at the end (not containing x) and you'll see it > prints 4 4, which makes what happened obvious. I realised = was doing its normal thing of the number of lines in the file

Re: whatnow: problems with edit--draft left

2024-06-11 Thread Ralph Corderoy
Hi Marcin, > I think GNU ed introduced this at a (possibly misguided) attempt to > remove isatty at the very beginning. I agree with your analysis having read all of ed(1p). GNU seem to have this wrong. I'm puzzled why g/x/= prints 3 twice rather than 1, 3. $ ed -p': ' : a x y

Re: whatnow: problems with edit--draft left

2024-06-11 Thread Ralph Corderoy
Hi Andy, > .Ex -std ed > > I'm no man page expert but it seems that .Ex is a macro that loads > a standard string that is used commonly between commands where 0 is > success and >0 is error. And it takes the name of the utility as an > argument. > > Indeed it is found in mdoc_validate.c in the

Re: whatnow: problems with edit--draft left

2024-06-09 Thread Ralph Corderoy
Hi Andy, > Man page for OpenBSD's ed: > > EXIT STATUS > The ed utility exits 0 on success, and >0 if an error occurs. What am I doing wrong? I don't see ‘success’ in https://cvsweb.openbsd.org/src/bin/ed/ed.1?rev=1.77=text/x-cvsweb-markup > Does this statement mean that there was an error

Re: whatnow: problems with edit--draft left

2024-06-06 Thread Ralph Corderoy
Hi saper, > (resending, 1st attempt) Your first one was delayed for moderator approval because it was your first email to the list. It got approved and reached the subscribers. I replied to the list. Here's the archive so you can see the reply.

Re: whatnow: problems with edit--draft left

2024-06-06 Thread Ralph Corderoy
Hi Marcin, > After saving the file I mostly (not always) get the following error: > > whatnow: problems with edit--draft left in /home/saper/Mail/drafts/,1 https://git.savannah.nongnu.org/cgit/nmh.git/tree/uip/whatnowsbr.c#n760 760 if ((status = pidwait (pid, NOTOK))) { 761

Re: Nmh on MacOs

2024-04-18 Thread Ralph Corderoy
Hi Eric, > I have mu, nmh, dape, and slime on my emacs I think Emacs users like the MH-E interface to nmh: https://mh-e.sourceforge.io. > Every time I press inc, I get this message This is quite common. https://lists.nongnu.org/archive/html/nmh-workers/2023-03/msg3.html was one ‘recent’

Re: inc and non-compliant long lines redux

2024-04-17 Thread Ralph Corderoy
Hi, Ken wrote: > Andy wrote: > > Precisely. Though in my current patch proposal, the problem isn't > > with CR/LF but with the two .. signal terminator coming from POP. > > The two dots must be getting split and the first dot is at the end > > of a buffer and the second is at the beginning of the

Re: Symbolic link to mhmail

2024-03-27 Thread Ralph Corderoy
Hello Thomas, kre has given a good answer and I'd do what he suggested, but... > This issue comes from the fact that I wanted to use the > unattended-upgrades package on Debian which uses mailx to send > reports. Since only nmh is detected as providing a compatible mailx > program, mailx

Re: Trivia: space before '(others)' from 'folder' command

2024-01-20 Thread Ralph Corderoy
Hi Andy, > Is this perhaps an off-by-one error? I don't think so. Try folders +OpenSourceML | awk '{l=length($1)}l>m{m=l;p=$0}END{print p}' That it's 81 wide when ‘tput cols’ is 80 is coincidence. -- Cheers, Ralph.

Re: Trivia: space before '(others)' from 'folder' command

2024-01-20 Thread Ralph Corderoy
Hi Ken, > > Possibly this could be conditional on the 'all' flag which gets > > turned on if the command name ends in 's'? > > Yeah, that is exactly why it happens. Honestly it doesn't personally > bother me, but what do others think? It seems a bit of a nit which could be groomed out. It was

Re: Where is my editor?

2024-01-19 Thread Ralph Corderoy
Hi Andy, > I suppose I could set EDITOR but I've never had to on OpenBSD. POSIX says EDITOR used by more(1) and crontab(1) defaults to vi if not set. But for mailx(1), the default is unspecified unless it's an XSI system when it's ed. mailx's default for VISUAL is vi, XSI or not. That's based

Re: Setting send(1)'s draftfolder breaks mhmail.

2024-01-19 Thread Ralph Corderoy
Hi David, > mhmail currently uses a tmp file, always, for the draft. I think the > fix should depend on if mhmail has been instructed to use send and > send has a draftfolder switch in the profile. In that case it should > create the draft as a new draft message in the draftfolder, instead of >

Setting send(1)'s draftfolder breaks mhmail.

2024-01-18 Thread Ralph Corderoy
Hi, A while ago, I pointed out send(1) ignores the profile's ‘draft-folder’. The suggestion was to duplicate the setting by adding ‘send: -draftfolder drafts’. I think this breaks mhmail(1). mhmail \ -from $from \ -to $to \ -headerfield 'dcc: ralph' \

Re: mysterious c0 80

2024-01-05 Thread Ralph Corderoy
Hi David, > > > > nmh shouldn't comp(1) a new email today with a NUL in the body, > > > > but it should be able to read and show(1) one. > > > > > > I'm thinking of removing the support in post(8) for sending NULs. > > > Any disagreement? It's not a lot of code so could be easily > > > restored

Re: mysterious c0 80

2024-01-04 Thread Ralph Corderoy
Hi Ken, > It would be nice to understand the root cause of the bug, though. Yes. > So while I agree post would fail with this hypothetical dist(1) of a > message containing a NUL, it's not clear you could inc(1) such a > message in the first place. Today or historically? Historically is a

Re: mysterious c0 80

2024-01-04 Thread Ralph Corderoy
Hi David, > > nmh shouldn't comp(1) a new email today with a NUL in the body, but > > it should be able to read and show(1) one. > > I'm thinking of removing the support in post(8) for sending NULs. Any > disagreement? It's not a lot of code so could be easily restored in > the future if

Re: mysterious c0 80

2024-01-03 Thread Ralph Corderoy
Hi Ken, > According to RFC 5322, a NUL in a message body is not permitted. > From §3.5: > >body= (*(*998text CRLF) *998text) / obs-body > >text= %d1-9 /; Characters excluding CR >%d11 / ; and LF >

Re: mysterious c0 80

2024-01-02 Thread Ralph Corderoy
Hi Michael, > hexdump of this draft folder before I hit send: > > 520 2074 6f66 2072 6874 7461 0a2e 430a 756f > 530 646c 6220 2e65 0a0a 000a > > Note 00 0a. If one wrongly encodes NUL as two-byte UTF-8, intended for U+0080 to U+7fff, one gets c0 80. This is the bastard

Re: mysterious c0 80

2024-01-02 Thread Ralph Corderoy
Hi, Ken wrote: > ...draft file does NOT contain a '\n' as the last character? My > memory is that for some strange reason Emacs like to default to doing > that. I suspect we do not test for that. A POSIX text file is zero or more lines where a line is zero or more bytes terminated by '\n'. We

Re: message-Id has localhost

2024-01-01 Thread Ralph Corderoy
Hi Andy, > I also find it hard to beleive that someone wants the MUA to have a > specific Message-ID for their email People do all kinds of odd things. Like fully justify text on a media with coarse adjustment. :-) Wanting to specify the whole message-ID field is distinct from wanting to

Re: message-Id has localhost

2024-01-01 Thread Ralph Corderoy
Hi Ken, > I do not believe there is solution to this that will universally work, > or even work in a large majority of cases considering the > configuration of the modern Internet. Agreed. That's why I suggested allowing ‘@...’ in addition to ‘local’ and ‘random’. It allows the user to route

Re: mysterious c0 80

2023-12-31 Thread Ralph Corderoy
Hi Michael, > If it were in my template files, then it would show up in my emacs > buffer and draft files, right? If they're not hiding it from you to be helpful. Try LC_ALL=C sed -n $'/[^\t -~]/l' foo bar ... to see if there is any output for files foo, bar, ... -- Cheers, Ralph.

Re: message-Id has localhost

2023-12-31 Thread Ralph Corderoy
Hi Ken, > > > 4) Some people, for reasons I would classify as "vague", prefer to > > >generate their Message-IDs locally so their saved copy of the > > >message has the Message-ID in it. > > > > The reason you state seems precise rather than vague. > > I mean, that's not a reason in my

Re: message-Id has localhost

2023-12-31 Thread Ralph Corderoy
Hi Ken, > 2) The recommendation for Message-IDs is to use a domain name for the >right-hand side Recommendation or rule? I don't recall. > 4) Some people, for reasons I would classify as "vague", prefer to >generate their Message-IDs locally so their saved copy of the >message has

Re: message-Id has localhost

2023-12-30 Thread Ralph Corderoy
Hi Michael, > So it's me sending those bytes, not something in between adding them. ... > I'm clearsigning this email instead. The email I'm replying to: $ hd `mhpath .` | tail -3 1ac0 6e 73 74 65 61 64 2e 0a 0a 0a c0 80 c0 80 c0 80 |nstead..| 1ad0 c0 80 c0 80

Re: message-Id has localhost

2023-12-30 Thread Ralph Corderoy
Hi Michael, Of your three emails in this thread so far, two of them are MIME with a application/pgp-signature part. Those two have some dodgy bytes after the PGP signature. This caused some subscribers to the list to not see your email because their MTAs bounced it. Interesting lines from the

Re: nmh is vital to me

2023-11-30 Thread Ralph Corderoy
Hi dan, > inc produces this infernal message. > the -silent switch doesn't do anything. > how to i shut it off? > i just moved over to debian bookworm See ‘Welcome’ in mh_profile(5) for starters. Though something must be going wrong for it to be shown more than once. Others here will help more,

Re: Forwarding email

2023-07-09 Thread Ralph Corderoy
Hi Arthur, > I have been advised, and have tried using: > > forw -mime 5 > > where 5 is the number of the email I am trying to forward. > > This gets me: > > From: aalin...@riseup.net > To: > cqc: > Fcc: +outbox > Subject: Welcome to your The New York Times Replica Edition

Re: Forwarding html email

2023-04-10 Thread Ralph Corderoy
Hi Arthur, > It doesn't work when forwarding to a Proton mail account. Does Proton reject the whole email? Or does it appear in the inbox at Proton? > I guess i will have to contact the people at Proton for help. There's also https://www.reddit.com/r/ProtonMail/ The key information is your

Re: Forwding html email

2023-04-10 Thread Ralph Corderoy
Hi Arthur, > I believe i asked this once before when I was having difficulty > forwarding html email. The answer I received was to type "mime" at the > "what now" prompt and then send. There are gaps in that explanation of what you do. Rather than pick over the fine detail of your set-up, I'll

Re: Unsupported nroff macros on MacOS X

2023-04-06 Thread Ralph Corderoy
Hi Conrad, > Do the packaging systems on the affected operating systems support > "recommends" or "suggests"? My impression is the only OS where this is a problem is macOS. And if it has a packaging system then groff isn't in it. So instead of FreeBSD's ‘install package groff’ prompt when

Re: Number of nmh users.

2023-04-05 Thread Ralph Corderoy
Hi, M. Levinson emailed me off list but has agreed for the content to be forwarded because I thought it was of general interest. > >nmh-workers has ~170. > > And for what it's worth, one of those subscriptions is an automated > relay to the gmane.mail.nmh.devel newsgroup, so the total number of

Re: Unsupported nroff macros on MacOS X

2023-04-05 Thread Ralph Corderoy
Hi Anthony, > Not all groff parts were commented out. It will use groff if > installed and if mandoc gives an unsupported warning. > > https://github.com/apple-oss-distributions/man/blob/man-46/man/man.sh Thanks, that's interesting. Line 375 onwards,

Re: Unsupported nroff macros on MacOS X

2023-04-04 Thread Ralph Corderoy
Hi Bakul, > > groff was the macOS package Ken mentioned that provided troff. > > I've no knowledge of how Apple ship different troffs and how one can > > be specified as an nmh dependency. > > Apple doesn’t ship any *roff any more. If you look at their > /usr/bin/man script, they commented out

Re: Unsupported nroff macros on MacOS X

2023-04-04 Thread Ralph Corderoy
Hi Anthony, > > And if not now, then it may do in the future, > > Pure FUD. In your anger, you cut too much. > > It may be formatting other things wrongly. > > And if not now, then it may do in the future, > > especially if knowedgable man-page authors continue to write nmh's > > *man pages*,

Re: Unsupported nroff macros on MacOS X

2023-04-04 Thread Ralph Corderoy
Hi Paul, > What happened to the possibilitiy of simply replacing the .fc macros, > and the use of tbl, with tab characters? Or one of the other alternatives I gave along with that one. But it still leaves the risk of mandoc not coping with something else now or in the future. macOS, for that's

Re: Unsupported nroff macros on MacOS X

2023-04-04 Thread Ralph Corderoy
Hi kre, > > - Require groff. A win all round. > > If you mean "require a *roff compat text processor" then OK, but if > you really mean "groff" then no, never. groff was the macOS package Ken mentioned that provided troff. I've no knowledge of how Apple ship different troffs and how one can be

Re: Unsupported nroff macros on MacOS X

2023-04-04 Thread Ralph Corderoy
Hi Ken, > > The status quo is fine. It doesn't require understanding all of > > troff. Just man(7) plus the odd bit here and there. > > Sigh. The "odd bit" unfortunately, for me, requires a lot of > knowledge that seems to take some serious roff-fu. Which is why I said refer to the mailing

Number of nmh users. (Was: Unsupported nroff macros on MacOS X)

2023-04-04 Thread Ralph Corderoy
Hi doug, > There are 26 members on Savannah. Is that all of us that are left? The number of subscribers to the mailing lists may be a better representation. nmh-announce has ~60. It goes down whenever there's a flurry of announcements due to domains having expired, accounts being deleted, or,

Re: Unsupported nroff macros on MacOS X

2023-04-03 Thread Ralph Corderoy
Hi Ken, > I see what you mean; you can't mix and match macros across packages. ...across macro sets like man and mdoc. No. The status quo is fine. It doesn't require understanding all of troff. Just man(7) plus the odd bit here and there. It's sufficed for nmh for ages. Any occasional issue

Re: Unsupported nroff macros on MacOS X

2023-04-03 Thread Ralph Corderoy
Hi Ken, I don't have time to reply fully now. > My specific question is: should we replace the .fc macros in nmh man > pages with mdoc macros? The question is flawed. You could replace .fc plus *all* the man macros with all-mdoc macros in all the nmh man pages. It's man ^ mdoc == 1. But that

Re: Unsupported nroff macros on MacOS X

2023-04-03 Thread Ralph Corderoy
Hi Ken, > Are we all in agreement that (when possible) we should change man > pages over to mdoc and new man pages should be written in mdoc? No, see my other email which crossed. -- Cheers, Ralph.

Re: Unsupported nroff macros on MacOS X

2023-04-03 Thread Ralph Corderoy
Hi Ken, > This manpage is not compatible with mandoc(1) and might display > incorrectly. mandoc is a pain. It's one of many programs which attempt to interpret man pages whilst being an incomplete implementation. I hang out in places which like to talk about troff/nroff, including for man

Re: flist -- "Killed" -- oom (*not* 1.8 related)

2023-03-02 Thread Ralph Corderoy
Hi Ken, > > > I think we have to push this back on the MH-E people ... > >$ refile +31415 >$ folder +31415 > >31415+ has 1 message (1-1). > > I'm aware of that, but what happens if you have a subfolder that is > all numeric? I believe all of the nmh tools will treat that subfolder

Re: flist -- "Killed" -- oom (*not* 1.8 related)

2023-03-02 Thread Ralph Corderoy
Hi, Ken wrote: > I think we have to push this back on the MH-E people; Robert's > suggestion to add a non-numeric prefix to directories it creats sounds > like the best answer to me. $ refile +31415

Re: flist -- "Killed" -- oom (*not* 1.8 related)

2023-03-01 Thread Ralph Corderoy
Hi Greg, > $ valgrind flist -sequence xyz -all ... > ==729147== Warning: set address range perms: large range [0x59c8e040, > 0xa313d8ac0) (undefined) To watch progress, try strace -e openat flist -recurse -sequence xyz -all >/dev/null Also, is there anything odd about your tree of

Re: way to use Bcc: with mhmail?

2023-02-13 Thread Ralph Corderoy
Hi Tom, > Is there a way to Bcc: with mhmail? Experiment with one of -headerfield 'bcc: Tom R ' -headerfield 'dcc: Tom R ' > I do not want any destination addresses in the header. You may have seen ‘undisclosed-recipients:;’ in the To field.

Re: nmh 1.8RC2, xlbiff, and $HOME

2023-02-03 Thread Ralph Corderoy
Hi David, > Then I think that we should do the same in 1.8 for all platforms. Your principles soon went out the window. -- Cheers, Ralph.

Re: nmh 1.8RC2, xlbiff, and $HOME

2023-02-02 Thread Ralph Corderoy
Hi David, I've had one night's sleep spread over the last two nights so I'm not going to have time for nmh until the weekend. > And my feeling at this point is to put out an RC3 with the 1.7 > behavior for $HOME. Which, to be clear, is not the behaviour Ken and kre want. :-) Stephen, I'd

Re: nmh 1.8RC2, xlbiff, and $HOME

2023-02-01 Thread Ralph Corderoy
Hi, I wrote: > If 3 is implemented then the user may have thought a different > pretence would occur. After all, it's an arbitrary choice. Perhaps > he expects it will carry on just like his shell does. This has overlap with DWIM, ‘do what I mean’, and Perl's TMTOWTDI, ‘there's more than one

Re: nmh 1.8RC2, xlbiff, and $HOME

2023-02-01 Thread Ralph Corderoy
Hi David, > > This close to a release, I think we should stick with requiring HOME > > to be non-empty if it's set as otherwise there's too many paths to > > consider which the test harness probably doesn't exercise. > > I'd rather crank out an RC3 than pass up the opportunity to solidify > the

Re: nmh 1.8RC2, xlbiff, and $HOME

2023-02-01 Thread Ralph Corderoy
Hi kre, > There is never a need to deliberately make anything an error to > satisfy user expectations, if the user wants a complaint about HOME > being an empty string, rather than some other behaviour, all they need > is one of... My stance has nothing to do with satisfying ‘user expectations’

Re: nmh 1.8RC2, xlbiff, and $HOME

2023-01-31 Thread Ralph Corderoy
Hi Ken, > > What's the intent of an empty HOME? > > Is it set by accident when it's meant to be unset? > > Is it empty by accident when it's meant to be non-empty? > > Do they want HOME=/, HOME=$PWD, or are they expecting it to error. > > Any choice could be not what the user intended so exit. >

Re: nmh 1.8RC2, xlbiff, and $HOME

2023-01-31 Thread Ralph Corderoy
Hi Ken, > > So an unset HOME is allowed by this function, it's an empty HOME > > which isn't. > > It strikes me as strange that there is a difference between an unset > HOME and an empty HOME in terms of behavior. I mean, yes, I can see > how the code is written, the historical precedent and how

Re: nmh 1.8RC2, xlbiff, and $HOME

2023-01-31 Thread Ralph Corderoy
Hi kre, Thanks for your learned input on this. As I said in another reply just now, where I listed set_mypath(), HOME being unset is fine as getpwuid() is the fallback in which case pw_dir must be non-empty. > > Alexander does point out that HOME is supposed to be valid according > > to POSIX,

Re: nmh 1.8RC2, xlbiff, and $HOME

2023-01-31 Thread Ralph Corderoy
Hi az, > "Author: Ralph Corderoy > Date: Thu May 13 13:46:20 2021 +0100 > > sbr/path.c: add set_mypath() to factor out repeated code." I think it's worth expanding on that. commit d8ca46fabc26469be325b73a73dcc26e70681eb5 Author: Ralph Corderoy Date: Th

Re: nmh 1.8RC2, xlbiff, and $HOME

2023-01-31 Thread Ralph Corderoy
Hi David, > I'd like to get Ralph's take on what we should do. Thanks. If my suggestion to Stephen of unsetting HOME works and is acceptable to him then I suggest we don't change nmh for this release. > > A further documentation issue: mh-profile(5) does not specify the > > treatment of a

Re: nmh 1.8RC2, xlbiff, and $HOME

2023-01-31 Thread Ralph Corderoy
Hi Stephen, > I have investigated the failure of the xlbiff tests with nmh 1.8RC2. Thanks. > $ printf 'Path: /tmp\n' > /tmp/mh-profile-minimal > $ HOME= MH=/tmp/mh-profile-minimal /usr/bin/mh/mhparam path My suggestion for a quick fix to try is to not have HOME in the environment so

Re: 1.8RC2?

2023-01-29 Thread Ralph Corderoy
Hi David, > Alexander wrote: > > https://qa.debian.org/excuses.php?package=nmh > > It looks like that dependent package is xbiff. Do you know how that > is identified as a dependecy? I don't see it as an explicit > dependency in nmh itself. Finding a Debian system, I think it's more that

Re: nmh latest on Mageia 8

2023-01-19 Thread Ralph Corderoy
Hi Jerry, > + Creating dir /home/jerry/code/nmhgit/nmh/test/testdir/tmp/ Have you got something odd with mkdir(1) which would make it print that message, especially with a ‘-p’? I don't think ‘Creating dir’ appears in nmh's source. -- Cheers, Ralph.

Re: [nmh-commits] [SCM] The nmh Mail Handling System branch, master, updated. 1.8-RC1-9-g68228e3c

2023-01-02 Thread Ralph Corderoy
Hi Ken, > man/burst.man: re-word to avoid ‘digestifying’, etc. ... > when the email is sent out about the change I get them a little > mangled because the script that notifies about changes doesn't mark > that email as UTF-8. Agreed, it doesn't. They arrive as valid UTF-8 here which

Re: [SCM] The nmh Mail Handling System branch, master, updated. 1.7-branchpoint-887-g54434563

2023-01-02 Thread Ralph Corderoy
Hi David, > > I can see tag 1.8-branchpoint is the branch point for the > > 1.8-release branch, but why are 69027ab9, 760a6ba9, 5608cda8, which > > alter VERSION and DATE, on master rather than 1.8-release? > > Good question. When I did that I was thinking of where master is at > that point in

Re: nmh 1.8?

2023-01-02 Thread Ralph Corderoy
Hi Andy, > > Has anyone had a chance to review my proposed changes to inc to be > > able to handle long lines from POP sources? Is the latest in Git? I see the ‘andy-long-line-patch’ at http://git.savannah.nongnu.org/cgit/nmh.git/refs/ with one commit:

Re: [SCM] The nmh Mail Handling System branch, master, updated. 1.7-branchpoint-887-g54434563

2023-01-02 Thread Ralph Corderoy
Hi David, > > Should I stop pushing commits now so as to not get in your way, or > > keep pottering them in as they may make it if there's an 1.8-RC2? > > I'd rather avoid code changes because, in theory, they'd require > complete re-testing. Agreed. > If you find a code change that really

Re: nmh 1.8?

2023-01-02 Thread Ralph Corderoy
Hi Kevin, > Is anyone here packaging nmh as part of a .deb file in the process of > testing? Alexander Zangerl is Debian's packager in the past; I'm CC-ing him. The end of docs/README.developers says Keep an eye on Debian's packaging, especially what patches they have to apply, and

Re: send(1) and Draft-Folder.

2023-01-02 Thread Ralph Corderoy
Hi David, > > Ralph wrote: > > > > Draft-Folder: To specify the default draftfolder > > > > > > > > Removing the hyphen from the second draft-folder helps associate > > > > it with the -draftfolder switch, I think. > > > > > > Is this equivalent? > > > > > > Draft-Folder: -draftfolder's

Re: [SCM] The nmh Mail Handling System branch, master, updated. 1.7-branchpoint-887-g54434563

2023-01-01 Thread Ralph Corderoy
Hi David, > Summary of changes: > NEWS | 112 > - I've pushed a little update to that to master which falls after the 1.8 tags. a3a23a66 (origin/master, origin/HEAD) man/*.man: fix options which didn't escape

Re: nmh 1.8?

2022-12-31 Thread Ralph Corderoy
Hi David, > HEAD builds and tests cleanly for me on Fedora, Solaris 11, and > Cygwin. Good to hear. I had a ‘All 118 tests passed’ with 1.7-branchpoint-884-gf116eb31 when doing ‘NMH_VALGRIND=1 VALGRIND_ME=1 make check’ on a friend's quicker PC running Manjaro. > Do you or anyone else have

Re: nmh 1.8?

2022-12-31 Thread Ralph Corderoy
Hi Ken, > Sigh. Ralph, you and I don't agree on Content-MD5, which is fine. The issue is not the repeated distractions of only I used the options or what was the point of them anyway. It's that functionality was deleted but at the same time documented as deprecated and the options left in as

Re: send(1) and Draft-Folder.

2022-12-30 Thread Ralph Corderoy
Hi David, > How about changing all of these man page descriptions: > > Draft-Folder: To find the default draft-folder > > to: > > Draft-Folder: To specify the default draftfolder > > Removing the hyphen from the second draft-folder helps associate it > with the -draftfolder switch, I

Re: valgrind Complaint for test/mhshow/test-charset.

2022-12-30 Thread Ralph Corderoy
Hi David, > I don't get that complaint here, Fedora 37 with glibc 2.36. Good to know. The problem appears on a friend's Manjaro system, an Arch Linux spin-off, also with glibc 2.36. > > ==19813551992192== Invalid read of size 8 > > ==19813551992192==at 0x4024AC0: strncmp

valgrind Complaint for test/mhshow/test-charset.

2022-12-30 Thread Ralph Corderoy
Hi, I'm getting a repeatable valgrind(1) complaint with NMH_VALGRIND=1 make TESTS=test/mhshow/test-charset check on one machine but not the other. Both are x86_64 but with different C libraries, etc. I think it's start_test 'Encoded parameter value' with the interesting, repetitive,

Re: nmh 1.8?

2022-12-28 Thread Ralph Corderoy
Hi Paul, > > - The generation and verification of Content-MD5 headers is no > > longer performed. The -check and -nocheck switches to various nmh > > programs that would control this functionality still exist, but > > are non-functional and will be removed in the next

Re: nmh 1.8?

2022-12-28 Thread Ralph Corderoy
Hi David, > Greetings as we approach the new year. Yes, hello all. Hope you've had a nice Christmas. > What does everyone think of pushing out a 1.8 soon? +1 > Here are changes since 1.7.1: > https://git.savannah.nongnu.org/cgit/nmh.git/plain/docs/pending-release-notes

Re: send(1) and Draft-Folder.

2022-12-19 Thread Ralph Corderoy
Hi David, > > I've Draft-Folder set to drafts in .mh_profile. Using at(1) to > > ‘send 42’ fails because `mhpath +`/42 doesn't exist. > > Would it succeed with 'send -draftfolder drafts 42'? Yes, I've just tried ‘send -draftfolder drafts 42’ and it worked. > Or if your profile included

send(1) and Draft-Folder.

2022-12-16 Thread Ralph Corderoy
Hi, send [-help] [-version] [-alias aliasfile] [-draft] [-draftfolder +folder] [-draftmessage msg] [-nodraftfolder] ... The -draftfolder +folder and -draftmessage msg switches invoke the nmh draft folder facility. This is an advanced (and highly useful) feature.

Re: nmh setup on macos by newbie

2022-11-27 Thread Ralph Corderoy
Hi Torsten, Ken's already answer some of your questions... > so this is my first reply to a mailinglist post - I addressed it to > you (reply to from:), cc'ed the list and hope for the best. Yep, that'll work fine. > > I think it is the problem. Try adding -initialtls to inc's options, > >

Re: nmh setup on macos by newbie

2022-11-25 Thread Ralph Corderoy
Hi Torsten, > I hope I can ask for guidance here. Yes, very much so. > inc: -ERR [SYS/PERM] This account requires an encrypted network > connection to login. Your current connection is vulnerable to > villainous voyeurs. Reconnect using transport layer security, aka > SSL/TLS, to access this

ali(1)'s glob Matching is Too Slack.

2022-11-15 Thread Ralph Corderoy
Hi, I was just pootering about adding comments at the start of functions in uip/aliasbr.c to document what they do, which means working out what they do, and noticed this. $ ali -alias <(echo 'foo*bar: xyzzy') foonot xyzzy $ I think the ordinary punter would expect ‘foo*bar’ to need

Re: inc and non-compliant long lines redux

2022-11-15 Thread Ralph Corderoy
Hi, Ken wrote: > Andy wrote: > > > Is this only seen with inc(1) reading from a particular source? > > > > I believe the only problem that I found was inc and reading from a > > POP source; sorry for not being more clear. Specifically in > > popsbr.c and pop_getline(), it would call

Re: inc and non-compliant long lines redux

2022-11-13 Thread Ralph Corderoy
Hi Andy, > Along the way I found 2 other bugs. Not only does inc fail with long > lines that are greater than 32768 bytes, it also truncates lines that > are less than that value and longer than 1024 bytes (not sure if this > behavior is intentional, but it seems like an oversight to me). Is

Re: Misplaced header include in some files for sbr/globals.h?

2022-11-12 Thread Ralph Corderoy
seem to have corrupted the commit message; it should have the [...] bit added: commit 58cbb3bc57ef21309e7e852e122e8dbd46530e12 Author: Ralph Corderoy Date: Sat Nov 12 10:58:21 2022 + rcvtty.c, slocal.c: remove condition on #include-ing globals.h. sbr/globals

Re: inc and non-compliant long lines redux

2022-11-10 Thread Ralph Corderoy
Hi Andy, > Not sure where they went... they used to be defined in mh.h: And elsewhere. They went with C99 being a requirement. commit c08cb60fe34b42b0a83bc88b57fd41b07793863f Author: Ralph Corderoy Date: Mon Sep 4 10:07:35 2017 +0100 Replace FALSE and TRUE with C9

Re: sortm error analysis

2022-10-09 Thread Ralph Corderoy
Hi Dave, > Running sortm on a folder with about 6000 messages, sortm reports "can't > parse date field" on two messages. I've added -verbose but have no clue > to what is wrong with the date field on those messages. ... > Date: Wed, 21 Sep 2022 06:47:55 -0400 > Date: Wed, 21 Sep 2022

Re: 'all' folder msgs from last 3 weeks; of symlinks?

2022-09-13 Thread Ralph Corderoy
Hi Tom, > I have many nmh folders, that get filled by procmail. I'd like to have, an > 'all' > folder that is built by a shell script that could be called by cron daily. > I'd be happy, with all msgs, say from the last 21 days. Perhaps this script > would remove bad symlinks in 'all' each time

Re: Surprising MIME Type from Android.

2022-07-26 Thread Ralph Corderoy
Hi David, > > Something for mhfixmsg(1) to correct? > > At this point, I think the trade-off favors manually fixing the > apparently rare offending messages rather than investing effort in > enhancing mhfixmsg. Fair enough. Either way, I think nmh should baulk at invalid characters in the MIME

Re: Surprising MIME Type from Android.

2022-07-25 Thread Ralph Corderoy
Hi Paul, Haven't noticed a comment in a References field before: References: <20220722115151.80a8221...@orac.inputplus.co.uk> <20220725092852.e055e20...@orac.inputplus.co.uk> (sfid-20220725_052923_626513_424143A1)

Re: Surprising MIME Type from Android.

2022-07-25 Thread Ralph Corderoy
Hi again, > I ran mhstore(1) and was surprised by the ‘81081.2.*’ filename. ... >2 image/* 2985K ... > I haven't checked yet, but I assume it violates the RFCs. It does by my reading of https://datatracker.ietf.org/doc/html/rfc2045#section-5.1 Something for

Surprising MIME Type from Android.

2022-07-22 Thread Ralph Corderoy
Hi, I ran mhstore(1) and was surprised by the ‘81081.2.*’ filename. $ mhlist -nov p=1 msg part type/subtype size description 81081 multipart/mixed 4036K 1 multipart/alternative 3143 1.1 text/html 1327

Re: mhl linewrapping

2022-05-22 Thread Ralph Corderoy
Hi Philipp, > First of all it depends on the terminalsize, if the size is not given > by the arguments. This leads to diffrent linewrapping on reply > depending on the size of the terminal. This could be fixed by going > to some default width when stdout is not a tty. It would seem right to

Re: Formatting annotations in mhl

2022-05-14 Thread Ralph Corderoy
Hi kre, > Does anyone have a good (or even passable) way to write an mhl format > file description which will do something sane (not just ignore) fields > which are annotations added by anno ? I'm not sure what you consider sane. They can be combined, but mhl can only be told a field contains

Re: new release?

2022-04-21 Thread Ralph Corderoy
Hi David, > I rely on the exit status of build_nmh, and only look at the log file > if indicates failure. Ah, I was considering any tests skipped as failure because I was trying to get them all to run. :-) I agree in the general case that's not wanted. > Should we output the summary to the

Re: new release?

2022-04-21 Thread Ralph Corderoy
Hi David, > > > Both releases saw a spew of "Broken pipe" errors after > > > test-mhparam, not sure if that's expected or not. > > > > That's not expected. The test immediately after that test-mhparam > > is test/oauth/test-send. So Jay's later email showed EPIPE was being returned and that

Re: new release?

2022-04-21 Thread Ralph Corderoy
Hi Eric, > I've pushed f188de902b613110d5943210f212adb680a2b44a to master > now, which should resolve this test failure. Thanks, but could you, and any other committers, try to use Git's rebase rather than merge as it preserves your commits and their messages rather than ‘Merge commit

Re: new release?

2022-04-20 Thread Ralph Corderoy
Hi again David, > Installing libgdbm-compat-dev for ndbm.h works, i.e. ./build_nmh > installing to /tmp and leaving the rest to configure ends > > All 99 tests passed > (19 tests were not run) Sometimes, the summary of the tests run by build_nmh do not appear on the terminal. $

Re: new release?

2022-04-20 Thread Ralph Corderoy
Hi Paul, > At first I was missing "yacc". Installing either bison or byacc gets > me to this error. Has configure been re-run since the installation? > $ make > make all-am > make[1]: Entering directory '/home/pgf/src/pdom/nmh/nmh.git' > /bin/bash ./ylwrap sbr/icalendar.l .c

  1   2   3   4   5   6   7   8   9   10   >