Re: [Nmh-workers] whatnow: can't attach because no header field name was given.

found out about this very recently by searching the lists. It would be nice to have adding attachments work by default... -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] whatnow: can't attach because no header field name was given.

message if one or more matches are found. This conversion occurs before all other processing. > Full disclosure: I am using NMH version 1.3. Alas, version 1.4 has not > been ported to FreeBSD yet. (Is this the real root of the problem?) I'm on 1.4 (it's in OpenBSD ports),

Re: [Nmh-workers] Revert utmpx change?

anyone know what the deal is with that?). I >suspect you don't use those features. Would you be happy with code that >just disabled that support on OpenBSD? Yes, that seems sensible to me for a feature that is (I assume) rarely used on this platform.

Re: [Nmh-workers] Revert utmpx change?

works here. Thanks. -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] MACHINES: notes about BSD builds

sr/bin/vi nmh has been packaged on OpenBSD since 1998, and has never used bash to run configure AFAIK (it certainly doesn't now). Looks like that warning is not necessary. -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@no

Re: [Nmh-workers] [PATCH] nmh.man: reorganize the command listing

Lyndon Nerenberg writes: > > On 2012-10-16, at 6:21 AM, Paul Fox wrote: > > > attached. thank you. but i'm also very happy to do the editing, if > > you can provide an example or template to start from. > > When I updated the manpages for the $PAGER changes I noticed a few things abo > ut how

Re: [Nmh-workers] man page change review

e some problematic constructs, which I asked about on the mandoc mailing list some time ago. Ingo Schwarze, an OpenBSD developer (and a manpage expert if I ever saw one), replied: http://article.gmane.org/gmane.comp.tools.mdocml.user/497/ -- Anthony J. Bentley _

[Nmh-workers] comp: only one message at a time!

as to how to let me use comp again? -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] comp: only one message at a time!

in profile, and the above is what happens when draft exists (now, at least). -use made no difference when I tried it yesterday (it either gave the same message or complained about a missing "draft" file, I can't remember). Chalking it up to a mystery of mh.

Re: [Nmh-workers] Garbage collection

.com/lists/musl/2012/03/04/4). As far as I know the behavior of the utmpx functions are not defined by POSIX either. I just checked and musl implements them as empty stubs. By the letter of the standard that seems to be a compliant implementation. -- Anthony J. Bentley _

Re: [Nmh-workers] Garbage collection

t;POSIX either. > > http://pubs.opengroup.org/onlinepubs/009696899/functions/endutxent.html And on that page utmpx is marked as an XSI extension. To my understanding those are optional and not required to be implemented in POSIX-compliant software. -- Anthony J. Bentley _

Re: [Nmh-workers] Garbage collection

Ken Hornstein writes: > >Please don't remove rcvtty -- I use it too -- and on OpenBSD no less, > >with a tiny patch that brings back utmp support (so few lines, was it > >really necessary to remove it?). > > Yes. We made a decision to migrate to POSIX, I mentioned that utmpx is not required by P

Re: [Nmh-workers] OpenBSD added to the buildbot cluster

gt; > Based on a very quick web search, it looks like they're from the > linker and there's no easy way. We could filter them out of the > linker output. Yes, these are local changes in the linker. I don't know of any way to disable them. -- Anthony J. Bentley _

Re: [Nmh-workers] mhshow display bug

cessarily available in a POSIX-conforming iconv. -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] A non-complaint

ISO-8859-1 is always treated as Windows-1252, due to how common such incorrectly marked documents are on the web. -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Thoughts: header/address parsing

a new -runes that counts runes/glyphs/codepoints would sidestep > the compatibility issue, -runes trumping -width? But characters can consist of multiple codepoints (see: accents). And characters can be double-width. Or zero-width. Or, or, or... -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] forcing a particular character set

t-Type header manually to utf-8. Is there some way I can set nmh 1.6 to always send UTF-8 headers if the message is valid UTF-8, including pure ASCII? (I'm also open to better workflows for composing and replying to PGP-encrypted messages. But that deserves its own thread.) -- Anthony J.

[Nmh-workers] default Content-Type boundary value?

of pragmatism, would it make sense for nmh to pick a boundary value that is less likely to trigger bugs in other software? -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] default Content-Type boundary value?

"Anthony J. Bentley" writes: > I'm guessing this is a bug in the MARC.info software, and I sent a bug > report to the operators. But in the interest of pragmatism, would it > make sense for nmh to pick a boundary value that is less likely to > trigger bugs in othe

[Nmh-workers] show: quotes in email addresses

Hi, When I use this header in my comp(1) draft: From: Anthony J. Bentley the name "Anthony J. Bentley" becomes wrapped in double quotes. My understanding is that this is a RFC requirement due to the dot, so that's fine. However, I don't want to see the quotes in show(

Re: [Nmh-workers] mts.conf has me Baffled.

ou get retry, etc. Many people don't need a MTA, but it's an option worth considering. -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] nmh architecture discussion: format engine character set

ed, there's no guarantee that a UTF-8 locale exists and what it's called if it does exist, but maybe it would be appropriate to have a configure check to find one? -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://

Re: [Nmh-workers] nmh architecture discussion: format engine character set

ges as decoded UTF-8 text files, and sub-hierarchies as necessary for attachments/MIME, however that would work. It seems like a lot of room for error in implementation. But talk about satisfying the Unix philosophy... -- Anthony J. Bentley ___ Nmh-workers

Re: [Nmh-workers] nmh + fdm

action "inbox" pipe "/usr/local/libexec/rcvstore +inbox" match "^From.*blah@example\\.com" in headers action "blah" match all action "inbox" -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Starting the final call for features for 1.7

rg/X.7 Side note: I've thought about converting the nmh documentation to -mdoc (which is really a very good format with a nice long Unix heritage, and these days is probably the second most used troff macro set after -man)... but it would be qu

Re: [Nmh-workers] strncpy(3), die, die, die.

Just check the return value against the size of the buffer. -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Changes to mh-tailor.man

peset in a fixed-width font and as a result the '-' doesn't look unnaturally small. > I have no idea if there is an established convention used by the unix > book publishing industry. At least all of Kernighan's books (such as UPE) use \- for command-line flags. -- Anthony J. Bentley ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Call for testing of nmh 1.7 release candidate 3

n failed: Connection refused post: problem initializing server; [BHST] no servers available (use -snoop for details send: message not delivered to anyone I run OpenSMTPD as a relay to GMail. If I manually pipe a message to OpenSMTPD's sendmail(8), it arrives at the destination. How do I get mail

Re: [Nmh-workers] Call for testing of nmh 1.7 release candidate 3

rt 587 on 'smtp' message submission. > > The -port switch to send(1), post(1), and whom(1) can be used to override. 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 pr

Re: [Nmh-workers] 1.7's `make clean' is Overzealous.

Content-Disposition: attachment; filename="nulls" > Content-Transfer-Encoding: base64 > --- 18,24 OpenBSD's file(1) implementation apparently sees this file differently. $ file -i nmh-1.7/test/mhbuild/nulls nmh-1.7/test/mhbuild/nulls: application/x-not-regular-file -- Anthony J. Bentley -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] 1.7's `make clean' is Overzealous.

change it to octet-stream[1], so nmh tests all pass now. 1: https://marc.info/?l=openbsd-cvs&m=151204021400810&w=2 -- Anthony J. Bentley -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] 1.7's `make clean' is Overzealous.

w days now. It adjusted SYSCONFDIR accordingly (from ${PREFIX}/lib/nmh to ${PREFIX}/lib). -- Anthony J. Bentley -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Where are we at for 1.7.1?

tion a while back; perhaps I should take a look... Personally I think iconv is a perfectly reasonable requirement for a modern mail client, and removing the ability to build nmh without it (especially since it's POSIX-standardized) makes sense for maintenance reasons. -- Anthony J. Bentley -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

does nmh have it turned ON by default!? -- Anthony J. Bentley -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] post 1.71 ug: "long line"/single newline paragraphs

like GMail block images for similar reasons. -- Anthony J. Bentley -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

[nmh-workers] mhshow: invalid BASE64 encoding in --

Hi, I receive many messages on a particular mailing list that fail to render in nmh-1.7.1, giving the error: "mhshow: invalid BASE64 encoding in --" Since it's a public mailing list, one of these messages is enclosed below. Received: by 2002:a25:1505:0:0:0:0:0 with SMTP id 5csp1062256ybv;

Re: [nmh-workers] mhshow: invalid BASE64 encoding in --

seems to be at least minimally usable in these situations. Valdis wrote: > that maybe if we're looking at base64, if we encounter a blank line we > toss the rest of the body part. For what it's worth, this appears to be how GMail treats it. -- Anthony J. Bentley -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [nmh-workers] Thinking about a 1.8 release

me out. Thoughts? Speaking from a packaging perspective: in practice, I far prefer upstreams to err on the side of too many releases than too few. -- Anthony J. Bentley -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: Unsupported nroff macros on MacOS X

Ken Hornstein writes: > - Switch to tbl(1) macros which as far as I can tell are supported by > mandoc and seem to work everywhere. tbl is supported by mandoc, yes. In my opinion, this is the best option. Well, converting to mdoc macros would be nicer, but also much more work, and who would do i

Re: Unsupported nroff macros on MacOS X

Ralph Corderoy writes: > Silencing the .fc warning has easy fixes. > > - Require groff. A win all round. I don't agree. The ideal would be for mandoc to gain support for .fc (listed in its TODO as a desired but low-importance [read: rarely used] manpage feature), but despite its imperfect compati

Re: Unsupported nroff macros on MacOS X

Ken Hornstein writes: > Let's take the example you gave where the first line for a man > page that uses tbl should contain: > > '\" t > > So, my question is ... what does this mean? I understand that \" is > a comment, but I'm confused about the leading single quote. According to mandoc's roff(7)

Re: Unsupported nroff macros on MacOS X

Ralph Corderoy writes: > You're just prolonging the agony. Make nmh on macOS depend on > macOS's troff. Whether that's a virtual package satisfied by others > or an actual package if there's only one. You've identified one thing > mandoc is formatting wrongly. It may be formatting other things

Re: Unsupported nroff macros on MacOS X

Ralph Corderoy writes: > > Apple doesn’t ship any *roff any more. If you look at their > > /usr/bin/man script, they commented out anything to do with groff and > > only rely on mandoc. > > Odd. That doesn't tally with what Ken said earlier. > > https://lists.nongnu.org/archive/html/nmh-worke