Re: Packages for EL8 distros?
David Levine writes: > I package nmh for Fedora. It won't build for EPEL 7 and I haven't figured > out how to get it into EPEL 8 and 9 to try. FWIW, I have a locally-built RPM that works just fine on RHEL8. I started from the Fedora 28 sources (which was more or less the branch point for RHEL8). The specfile didn't need any changes according to my notes; the only problem was getting hold of the build dependencies. nmh wants w3m which wants perl-NKF which you will not find in core RHEL8. You can get it from the codeready repo though. regards, tom lane
Re: Just updated from CentOS 7 to Rocky Linux 8.5 and can't find nmh anywhere
David Levine writes:
> Tom wrote:
>> One other thing to worry about is that RHEL might not even carry
>> the prerequisites of the package you want. When rebuilding
>> nmh-1.7.1-7 on RHEL8, I found I needed perl-NKF which is not in
>> base RHEL8. Fortunately you can get it from the codeready repo.
> I'm surprised that perl-NKF, or any perl package, is needed.
According to my notes, the Fedora nmh package lists w3m as a build
dependency and w3m wanted perl-NKF as an install dependency.
I didn't stop to inquire about how essential either dependency
actually is.
My vague memory from a previous life working for Red Hat is that their
automatic dependency extractor sometimes misidentifies perl dependencies,
and only fairly nitpicky packaging engineers will trouble to get rid of
bogus ones. So maybe the perl-NKF dependency was bogus and I could've
overridden it ... or not.
regards, tom lane
Re: Just updated from CentOS 7 to Rocky Linux 8.5 and can't find nmh anywhere
Ken Hornstein writes:
>> I thought it would be in EPEL. I've looked around and I can't find it
>> anywhere. I installed from source (1.7.1), but lots of things are broken
>> and I'd prefer to use the rpm version like I had before.
>> Any help would be appreciated. Thanks.
> Hm. I'm a little unclear how that works, actually! I thought that
> Rocky Linux got stuff from Fedora, and we're in Fedora? Maybe?
> Shoot, I admit that I have NO idea! But I am sure that the people that
> DO have an idea are on this list.
Yeah, I just use the version from Fedora. I have a private patch
that hacks up one or two details to suit me, so I'd have to build
locally anyway. But you can typically build any Fedora package
on RHEL pretty easily, as long as you pick the Fedora version that
your version of RHEL branched off from. (For RHEL8, that happened
somewhere between F28 and F29 I believe; so F28 specfiles pretty
much always work, F29 only usually.)
One other thing to worry about is that RHEL might not even carry
the prerequisites of the package you want. When rebuilding
nmh-1.7.1-7 on RHEL8, I found I needed perl-NKF which is not in
base RHEL8. Fortunately you can get it from the codeready repo.
regards, tom lane
Re: Bug reported regarding Unicode handling in email address
Ralph Corderoy writes: > U+0081 as 0x81 is ‘is a character representable as an unsigned char’ for > it's a character, U+0081, and unsigned char holds [0, 0x100) so it > suffers no loss of representation as an unsigned char. Sure, but then what you are feeding the function is *not* UTF8. UTF8 would require two bytes to represent that code point. What you're describing is ISO 8859-1, which is a perfectly fine single-byte encoding, as long as you don't need any characters outside the common western-European languages. Or to put it another way: yes, you can claim that only code points up to U+FF can be passed to these functions, but that hobbles things to the point where you really shouldn't claim to be Unicode-aware at all. I think it's more sensible to consider that per spec, the functions can only deal with single-byte encodings; if you want something more flexible, you have to go to . regards, tom lane
Re: Bug reported regarding Unicode handling in email address
Ken Hornstein writes: >> The macros are just fundamentally broken in any locale that >> has multibyte characters: you cannot squeeze a multibyte character >> into an input that is supposed to be either an "unsigned char" or EOF. >> Vendors can choose either to violate the spec (say, by interpreting >> the "int" input as a Unicode codepoint) or to produce useless results. > It's worth pointing out that the official prototype for the ctype macros > all say they take "int" as an argument, and POSIX says they take as > an argument a "character". So interpreting that argument as a Unicode > codepoint (assuming you're currently in a Unicode locale) is, from my > reading, within the spec. You need to read a bit further down, where POSIX says The c argument is an int, the value of which the application shall ensure is representable as an unsigned char or equal to the value of the macro EOF. If the argument has any other value, the behavior is undefined. (C99 has identical verbiage.) The reason to declare the argument as int is so that these can take EOF, which I suppose is meant to allow them to be applied directly to the result of getc() ... though why anyone would write code that way is not clear to me. Anyway, interpreting the input as a Unicode code point, for values above U+7F (or, if you stretch it unreasonably, U+FF) is very clearly outside the spec. regards, tom lane
Re: Bug reported regarding Unicode handling in email address
Ken Hornstein writes: > So, it seems like the behavior of iscntrl() and isspace() if the value > is > 127 is undefined. If you're in the UTF-8 locale MacOS X treats that > as a Unicode codepoint. But we are NOT treating it like that in this case; > we're processing it on a character-by-character basis. The macros are just fundamentally broken in any locale that has multibyte characters: you cannot squeeze a multibyte character into an input that is supposed to be either an "unsigned char" or EOF. Vendors can choose either to violate the spec (say, by interpreting the "int" input as a Unicode codepoint) or to produce useless results. (As I recall, the MacOS UTF8 locales are badly broken in some other ways, but this problem is not Apple's fault.) > I am wondering if the simplest solution is to put in isascii() in front > of those tests in that function. We only really care about those tests > returning "true" for ASCII characters. Thoughts? Yeah, that seems like a reasonable fix in this context. regards, tom lane
Re: Is nmh suitable for managing multiple email accounts?
"Andy Bradford" writes:
> Thus said Michael Richardson on Sun, 07 Mar 2021 14:04:18 -0500:
>> But that doesn't work anymore unless you control the DNS for all zones
>> in question, and can set up SPF correctly. (Mostly, that actually does
>> apply to me)
> As a counterpoint, I have never setup SPF and generally have no
> problems. I do, however, control the DNS. As a counter counterpoint,
> however, not many people run their own email anymore. :-)
FWIW, I find that checking SPF is a pretty useful component of your spam
filtering strategy (if you are one of the holdouts who do still run your
own mail server). For me it bounces a couple of obvious forgeries per day
on average, which may not seem like a lot considering that the spamhaus
and spamcop blacklists bounce a couple thousand per day ... but as a
fraction of the junk that gets past my other filters, it's fairly
significant. If more people advertised SPF records for their domains,
it'd be even better.
regards, tom lane
Re: Hiding one's email source username/hostname/ISP
David Levine writes: > Tom wrote: >> Received: lines are generally added by each MTA that the message >> passes through. In this case it was smtp.gmail.com that added that; >> it's not under your control. You can probably modify the "Hikaru" >> part, as I believe that just comes from the HELO command your mail >> client uses. I'm not sure which part of the nmh configuration >> that comes from, but it can't be too hard to find. > It derives from the (hidden/undocumented) client switch to send(1). > I'll try sending this message with "send -client HiddenHostname". Ah. And after digging around a bit, I found this on my own machine: $ cat /etc/nmh/mts.conf # nmh mail transport interface customization file. ... # Name shown in HELO header: clientname: sss1.sss.pgh.pa.us which you can match up against the first Received: line in my own outgoing mails. So that's probably a better place to configure it than messing directly with send(1) switches. regards, tom lane
Re: Hiding one's email source username/hostname/ISP
Bob Carragher writes:
> In emails that I send, if you look at the Received: header chain,
> you'd find a line that resembles,
> Received: from Hikaru (x.comcast.net. [IP-address])
> by smtp.gmail.com [...]
Received: lines are generally added by each MTA that the message
passes through. In this case it was smtp.gmail.com that added that;
it's not under your control. You can probably modify the "Hikaru"
part, as I believe that just comes from the HELO command your mail
client uses. I'm not sure which part of the nmh configuration
that comes from, but it can't be too hard to find.
Keep in mind that Received: lines that look falsified in any way
are universally treated as a sure sign of spam.
regards, tom lane
Re: [nmh-workers] Making OpenSSL 1.0.2 minimum version
Ken Hornstein writes:
> I think at this point we should consider OpenSSL
> 1.0.2 the minimum supported version of OpenSSL for nmh. This would
> guarantee we are doing TLS 1.2 everywhere and clean up some #ifdefs.
> Objections?
That would make RHEL6 users, at least, sad:
$ rpm -q openssl
openssl-1.0.1e-57.el6.x86_64
openssl-1.0.1e-57.el6.i686
I am not exactly confident that replacing that with 1.0.2 or later would
be feasible --- didn't they break ABI to some extent in that revision?
regards, tom lane
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] closefds() _before_ fork?
Ken Hornstein writes:
> I realize that dup2() clears the FD_CLOEXEC flag on the new file
> descriptor so the "normal" case of an opened file being dup2() down to 0
> would work correctly, but the wrinkle is that it does NOT if the old and
> new file descriptor are the same. That is admittedly unlikely, but it
> could happen in a few cases so I'd like to be as robust as possible.
But is that really an issue? It'd only occur if you're passing down
your own stdin, which presumably you inherited without FD_CLOEXEC.
regards, tom lane
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] closefds() _before_ fork?
David Levine writes:
> Ken wrote:
>> I suggest we simply remove closefds() completely.
> Great idea!
Makes sense from here. You could back-fill use of CLOEXEC anywhere
it seemed important.
regards, tom lane
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] The State of exmh.
Ken Hornstein writes: > I am subscribed, but occasionally I want to look at the archives. I am > not a member of any other list that is restricted to subscribers only. > Are you actually arguing this makes sense? FWIW, I am on quite a few other lists that restrict their archives to subscribers. It's not that insane a policy, though I agree it doesn't really seem necessary for exmh-users. If you want it changed, this is hardly the right list to be complaining on. regards, tom lane -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] The State of exmh.
Ralph Corderoy writes: > Where does one go for exmh these days? The last I heard on the topic was per attached. It doesn't look like there has been any activity in the sourceforge git tree since then, which seems odd. Anyway, the exmh-users list is definitely still active; I got some traffic from it just a couple weeks ago. regards, tom lane --- Forwarded Message Date:Fri, 10 Nov 2017 00:01:35 -0500 From:valdis.kletni...@vt.edu To: exmh-us...@redhat.com, exmh-work...@redhat.com Subject: GIT tree is now on sourceforge. Finally beat 'git cvsimport' into submission, and when I did a read-only 'git clone', the lib/ directory was essentially the same as the CVS directory I started from, so I can't have botched it *too* badly. 'git log' and similar seem to reflect history properly. So I'll just leave the top level pointer here: https://sourceforge.net/projects/exmh/ See if you can find the git tree, clone it, etc. Yell if there's a problem. If I haven't heard anything in a few weeks, I'll go back and nuke the CVS version. ___ Exmh-users mailing list exmh-us...@redhat.com https://www.redhat.com/mailman/listinfo/exmh-users --- End of Forwarded Message -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Ignorring a Class of Headers
"Martin McCormick" writes:
> I presently have 216 ignores lines in mhl.headers and mhl.format
> which makes most messages simply display normally but then there is
> this type of metadata which is infinitely variable and stopping
> that display is the classic game of Wackamole.
I'm not sure whether this will help for the cases you're worried about,
but for me, it works to use * as a wildcard in .mh_profile's
Header-Suppress entry:
Header-Suppress: Delivery-Date Delivered-To Newsgroups Path Received References
Return-Path Originator Sender Version Errors-To Mime-Version Content-.*
Precedence Mbox-Line Resent-.* Mailbox-Line User-Agent DomainKey-Signature
DKIM-.* Received-SPF Authentication-Results Autocrypt Openpgp SpamDiagnostic.*
Thread-.* List-.* X-.*
But that might be an exmh-ism rather than native nmh, not sure.
regards, tom lane
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] Since the (automatic) upgrade to 1.7.1 on CentOS 7.4.1708, send doesn't work
Ralph Corderoy <ra...@inputplus.co.uk> writes:
>> I was just thinking you could have run 'send' outside of MH-E with the
>> -snoop flag.
> Perhaps MH-E users can live in its silo, never venturing out, and not
> getting near a whatnow(1) prompt, or running send(1)? Maybe some nmh
> users are first and only MH-E users, rather than using nmh and then
> picking up MH-E as an editor integration?
exmh is another case where the user is a bit removed from direct
access to whatnow, let alone send. Not sure if there's anything
better to do than tweak .mh_profile in such cases.
regards, tom lane
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] proposed patch for shell metacharacter failure in nmh-1.7
Paul Vixie <p...@redbarn.org> writes:
> Ken Hornstein wrote:
>>> pointers aren't booleans. in BSD style as used in BIND, this would be:
>>> while ((pp = strchr(pp, '\'')) != NULL && buflen > 3) {
>> Forgive my stupidity ... but this is just a matter of style, correct?
> the same underlying machine code will be generated.
Yeah, it's legal C ...
> i would rather give the compiler an extra chance to yell at me. pointers
> aren't booleans, in spite of C's ability to treat them that way.
Exactly --- there's a lot of distance between legal C and advisable C.
In this example, for instance, the comparison to NULL makes it clearer
that you did not mean to write
while ((pp == strchr (pp, '\'')) && buflen > 3) {
Your compiler may or may not whine about the shorter coding, depending
on which compiler it is and how high you've cranked its warning options.
But there are a lot of static analysis tools that will whine about it
in any case, and usually that stylistic advice is worth taking. C in
the raw is a bear trap waiting to take your foot off --- anything you
can do to make mistakes more obvious is worth doing.
regards, tom lane
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.7's putnum drops data if too close to end of line?
David Levine <levin...@acm.org> writes: > Tom wrote: >> Hm. Is there a way to override that value judgment? > Call it what you like, I will continue to remove any code I find > that silently outputs an incorrect integer. > %(kilo) and %(kibi) can produce partial output, and have the > benefit of a known trailing character. Ah. Replacing "putnum" with "kilo" produces output that I'm perfectly happy with --- thanks for the tip! Though I'm not sure I believe your assertion that these produce a known trailing character; AFAICS there is none below 1K: $ fmttest -format '(%(kilo(size)))' -msgsize 123 -raw foo (123) regards, tom lane -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.7's putnum drops data if too close to end of line?
David Levine <levin...@acm.org> writes:
> Tom wrote:
>> What I'd expect to happen, and what did happen before 1.7, is that the
>> size information would be there and would just be truncated if it didn't
>> fit in the available output width.
> The change was intentional, IIRC. Better to truncate than show
> part of a number. The parentheses in your format would reveal it,
> but without them, the output could be misleading with truncation.
Hm. Is there a way to override that value judgment?
regards, tom lane
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] 1.7's putnum drops data if too close to end of line?
I use a scan format that ends with
%(decode{subject}) (%(putnum(size)))
(all the previous output is fixed-width columns, so not interesting here).
As of 1.7 I'm seeing that the size data drops out if it would run off the
end of the available space. For example, an excerpt from "scan -width
100" output is
89716 12/01 16:53 Alvaro Herrera hack Re: [HACKERS] Custom
compression methods (4659)
89717 12/02 20:27 Jeff Janes perf Re: Bitmap scan is
undercosted? (12398)
89718 12/02 21:52 Oleg Bartunov hack Re: [HACKERS] Custom
compression methods ()
89720 12/02 22:27 chenhj hack Re:Re: [HACKERS]
[PATCH]make pg_rewind to not c
89721 12/02 23:04 Justin Pryzby perf Re: Bitmap scan is
undercosted? - boolean corre
89722 12/03 01:21 Pavel Stehule hack pg_dumpall -r -c try to
drop user postgres ()
What I'd expect to happen, and what did happen before 1.7, is that the
size information would be there and would just be truncated if it didn't
fit in the available output width. For instance, the last message shown
above has size 4467 so it ought to look like
89722 12/03 01:21 Pavel Stehule hack pg_dumpall -r -c try to
drop user postgres (446
This might be related to the issue Ken Hornstein reported in
http://lists.nongnu.org/archive/html/nmh-workers/2017-11/msg00053.html
regards, tom lane
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Cutting a new exmh release...
valdis.kletni...@vt.edu writes:
> The nmh guys are looking at finally deprecating mhn and shipping
> only mhbuild. This raises a few questions:
> 1) Would anybody complain if a new Exmh release said "You must have
> nmh 1.7"?
If I'm understanding the situation correctly, this is going to be a
flag day thing, right? You must upgrade to nmh 1.7 at the same time
you upgrade to exmh-whatever, because neither new nmh with old exmh
nor the reverse case will work?
That's kind of a pain, but on the other hand, we're so overdue for
a new official exmh release that I'd much rather have that sooner
with this restriction than later without. And it sounds like new
nmh with old exmh is going to be broken in any event.
regards, tom lane
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Large MH directories
Ken Hornstein <k...@pobox.com> writes: >> Is this a bad idea? I'm mainly concerned about speed: Other than like >> pick and scan on the whole folder, will anything else get very slow? I'm >> using Fast File System on OpenBSD. > We've been asked about this before; unfortunately, with the current (n)mh > design, it's just going to suck. > A bit of an explanation: right now, pretty much every nmh program that > wants to interpret a folder calls folder_read(). folder_read() does > a readdir() on the ENTIRE folder. It does NOT do a stat() on every > file, but if you have 600k files in a single directory, that's just > going to take some time. FWIW, I have not noticed any real performance problems with folder sizes in the range of 10K-50K messages. I try to keep my folders under 100K, not because performance falls off a cliff but because I begrudge the extra space for the message number in scan listings. It may or may not matter that I use exmh not direct nmh commands. exmh seems to cache the scan output, but then again it adds a lot of its own overhead. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Unexpected munging of outgoing message with nmh 1.6
Ralph Corderoy <ra...@inputplus.co.uk> writes:
>> In a different line of thinking: if mhbuild did take #define as a
>> directive, why didn't it barf on an unrecognized directive?
> What version of nmh is this that doesn't barf in the night?
1.6.
Although now that I see David's mail, I think maybe it did
have -nodirectives active but the backslash removal happened anyway.
regards, tom lane
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Unexpected munging of outgoing message with nmh 1.6
Ralph Corderoy <ra...@inputplus.co.uk> writes: >> You know, just out loud ... it wouldn't surprise me if it only happens >> with lines that start with "#"; I bet even though directives are >> turned off, it's seeing a backslash as the directive line continuation >> character. > Indeedy. But presumably Tom is running with -nodirectives or uses an > `#off' in his draft? No, and no. I never even heard of -nodirectives, and don't see any such thing in the "send" man page. As for #off, why should I be expecting to have to put directives into a plain text message? The workflow I'm accustomed to is that, if I've put any directives into my message, I run mhbuild on them explicitly (using C-c C-e in emacs MH-Letter mode). If I haven't done that, I would really rather that lines that happen to start with '#' not be considered magic. Looking at the send man page, it claims to invoke mhbuild with -auto, which mhbuild's man page suggests implies -nodirectives, but that evidently isn't the behavior I'm getting. In a different line of thinking: if mhbuild did take #define as a directive, why didn't it barf on an unrecognized directive? regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Unexpected munging of outgoing message with nmh 1.6
I just sent out a plain-text message that had some C code in it, including a macro definition with backslashes at the ends of lines. Ordinarily, and in every previous version of nmh, that would have been transmitted as-is. But today, something decided that it needed to be transmitted as quoted-printable, and that seems to have included a decision that backslash-newline sequences should be deleted. Needless to say, I'm pretty annoyed. Fortunately that little bit of editorialization didn't change the meaning of the C code, but it sure made it less readable (very long lines). In other contexts that could have destroyed the intended meaning of the text altogether. Why would some purely ASCII text get converted to quoted-printable? And how can I prevent it from changing the contents of the text when it does that? regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Having configure Check for cc's -pedantic -ansi.
David Levine <levin...@acm.org> writes: > Ralph wrote: >> I've since overridden configure's CFLAGS to add `-pedantic >> -ansi', but I wonder if m4/cppflags.m4 should attempt these >> and add them if they work? > We used to do this, but I removed them in commit 987b10b3. My > thinking was that CFLAGS is up to the user. I still think that's > the right thing to do. We do add -Wall -Wextra with gcc but those > don't cause compilation failure (and I've thought about removing > them). Note that '-ansi -pedantic' produces warnings about all constructs that aren't in C89, which is a much harsher restriction than has any real-world relevance today. I could see a bit more justification for '-std=c99 -pedantic', but that is still kind of problematic. If you've made a configure test for some feature, found it works, and are using it, you don't really want warnings about it. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility
David Levine <levin...@acm.org> writes:
> OK. I'm not going to add a -locale switch, that seems to me to move this
> too close to nmh. I like the locale profile component. Let me ask those
> who might use it: do you also want the NMH_LANG environment variable? I'd
> rather not add a feature that won't be used.
For my purposes, a locale profile component would be sufficient.
regards, tom lane
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Development Questions. check Programs. register.
Ralph Corderoy <ra...@inputplus.co.uk> writes: >>> extern int ctype_identity[257]; /* [n] = n-1 */ >>> #define isupper(c) ((isupper)((ctype_identity + 1)[c])) >> I'm not sure what the point is here, but have you considered that the >> input might be either signed or unsigned char? If it's signed, this >> coding won't work. > IIRC from the git commit log, this is attributed as your idea. :-) The > compiler will warn if type char is used as an array index, regardless of > whether it's signed or unsigned here, because it might be signed > elsewhere and the code wouldn't work as expected. So the above needs c > to be of type unsigned char, for example, to avoid the compiler warning. > It's the warning we're after to catch `isdigit(*s)' instead of > `isdigit((unsigned char)*s)'. Ah, I see. In the Postgres project we're relying on specific buildfarm members whose ctype.h macros actually still use arrays to catch this. Putting in your own layer is a cute idea. If I suggested it, it must've come from a brain cell I don't have anymore. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Development Questions. check Programs. register.
Ralph Corderoy <ra...@inputplus.co.uk> writes: > Thinking about this a bit more. The "generate C at compile time" can be > dropped by > #ifndef NDEBUG > #if EOF != -1 > #error "Please report this to nmh's authors." > #endif FWIW, the POSIX standard specifies The following macro name is defined as a negative integral constant expression: EOF End-of-file return value. I've never heard of an implementation not using -1, though. > extern int ctype_identity[257]; /* [n] = n-1 */ > #define isupper(c) ((isupper)((ctype_identity + 1)[c])) > ... > #endif I'm not sure what the point is here, but have you considered that the input might be either signed or unsigned char? If it's signed, this coding won't work. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility
Ralph Corderoy <ra...@inputplus.co.uk> writes: > If you just have one long-running Emacs then can't that be in the UTF-8 > locale? Or is your C-needing ls(1) run from inside that? I'd rather not run it in non-C locale (for one thing, as you say, shells run inside it would tend to inherit that locale). And I don't really see what that would change anyway. The nmh calls are made from exmh, which is a sibling not a child of the emacs process. For the moment, I've worked around the problem by launching exmh (and nothing else) in en_US.utf8 locale, so that the nmh calls all inherit that. But I regard that as a hack not a fix. It affects directory listings done by exmh, e.g. in save-to-file dialogs, and there may be other side-effects as well; I haven't been using this workaround for long enough to know. If it's decided that there will be no solution provided at the nmh level, I'll probably look into injecting extra code to set the locale envvars in exmh's nmh calls. > Have Emacs highlight non-ASCII characters in that mode wherever they > come from, e.g. paste from web browser? Have a function that maps the > common ones to ASCII, perhaps using recode(1)? Filter the buffer when > writing the file, erroring if it can't be written? Then you can send > valid US-ASCII emails. All of these solutions presuppose that this is my problem and not the software's. I respectfully disagree. I would like it to "just work" whether or not there are stray UTF8 characters. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility
Ken Hornstein <k...@pobox.com> writes: > As I understand it, Tom said his problem was when he forwarded some > email to someone else and it contained 8-bit characters. I suspect this > was done with "forw" (or the Forward button in exmh). Just for the record, I didn't say that; I rarely use "forw". The more common scenario for me is that I'm replying to someone and quoting bits of their message in-line (as I'm doing here), and the most common specific gotcha is that somebody's using fancy quotes rather than plain ASCII ones in the quoted text. Most of the text-munging involved in that doesn't use nmh at all AFAIK --- it's all in Emacs MH-Letter mode macros. And the macro for yanking a message into the buffer and prefixing "> " to each line doesn't pay any attention to the headers of said message, so it's not going to absorb any character set attributions from it. Fortunately for me, there's little enough non-UTF8 stuff in my mail traffic that I can afford to ignore the possibility that what I'm quoting isn't UTF8. I could probably teach the Emacs code to insert a Content-type header just before sending, if the buffer contains any non-ASCII characters. But I don't really see why I should have to, when nmh already contains exactly the logic I need, it's just not packaged in a conveniently-controllable way. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility
Ken Hornstein <k...@pobox.com> writes:
> I ... do not think this would solve this particular problem. The issue
> here seems to be a) nmh programs were given 8 bit characters, and b)
> the locale was set to US-ASCII. If you are going to assume that all
> INPUT is unconditionally UTF-8, then yes, that would solve this problem.
Umm ... I think you are attacking a straw man.
The current state of affairs is that nmh unconditionally assumes that
non-ASCII input is in the character set specified by the LC_CTYPE
environment variable (modulo the various ways that that can be specified).
What I'm suggesting would allow the environment to be overridden by an
mh_profile entry. There is zero difference from an epistemologic
standpoint: either way you're trusting the user to know what her data is.
regards, tom lane
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility
Lyndon Nerenberg <lyn...@orthanc.ca> writes:
> At this point, I think the fact that nobody seems to be able to give a
> simple, clear, and coherent description of the problem suggests that nobody
> really knows what the actual problem is, yet.
Well, my problem is that I want the prevailing session locale to be C,
primarily because I'm used to seeing output from e.g. "ls" in ASCII
ordering. But I'm finding that nmh, or at least send, is effectively
broken in that locale --- unwillingness to cope with non-ASCII data at
all counts as "broken" for me. So I want a way of controlling the locale
used by nmh without side-effects on other programs.
Obviously you could define this as being ls' problem not nmh's problem,
but I respectfully disagree. It was fine for the last twenty years or
thereabouts, and nmh changes are what made it not fine.
regards, tom lane
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility
Ken Hornstein <k...@pobox.com> writes: >> I believe that nmh users are sophisticated enough that they actually >> know what a Locale is, and an encoding, and if they google for more >> information they will understand what they read. I think that they >> are going to want a way to specify what they want in their mh_profile >> though. > Wlll ... my reluctance there is I don't want to duplicate Unix > functionality without a very good reason. And Unix already umpteen > ways to do this; you could wrap all of the nmh commands with aliases > or shell wrappers, for one. It just feels unnecessary. I thought Laura's suggestion was to be able to put something like locale: en_GB.utf8 into ~/.mh_profile, which seems eminently sensible to me. Yes, there are other ways to get the same result, but they're hacks. Wrapping every MH command with a shell wrapper in order to force its locale is surely a hack. The alternative of a session-wide LC/LANG setting may have side-effects that the user doesn't want, so I'd rate that as a hack too. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility
Ken Hornstein <k...@pobox.com> writes: >> Personally I'd love it if send did something like: >> (1) if text is entirely 7-bit: specify charset=us-ascii >> (2) if environment specifies a non-ascii character set, use that >> (3) assume charset=utf-8 (maybe allow this to be overridden in profile) > We already do (1) and (2). OK. > (3) is the problem. Other people who have > thoughts on this topic are free to weigh in. Personally, I believe that > if you're doing LANG=C, you shouldn't be dealing with any 8-bit characters > at all. Isn't that's what that means? Well, whether you intentionally type any and whether some happen to creep into your email are two different things. As an example: I am suspicious now that my problem really stemmed from exmh choosing to use both -push and -forward; the latter is documented as "If -forward is given, then a copy of the draft will be attached to this failure notice." So I am thinking that it stuck the UTF8-containing text onto the failure notice, and then that send attempt failed for exactly the same reason, ie it was rejected by the character set strictness check. Even if you're right that there was no send attempt at all, I'm expecting that once it's there it will fail like this :-( So basically the problem here is one of robustness. Yeah, it would be nice to be sure that what you are sending is 100% valid. But I don't really agree with the tradeoff that's been made of failing when you can't be sure of that. Especially since, if you think you know what non-ASCII encoding a bit of text is in, you're just fooling yourself anyway. It's impossible to distinguish the ISO 8859 variants from each other, and at best heuristic to tell whether text is in UTF-8 or an ISO 8859 variant. Maybe we could just leave off the character set spec if it turns out to be definitely wrong? regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility
Laura Creighton <l...@openend.se> writes:
> Since us-ascii is a perfect subset of utf-8, is there any reason that nmh
> couldn't take a look at the locale, and if it is us-ascii just use uft-8?
All modern character sets are supersets of us-ascii, so that argument
doesn't really get us far :-(.
Personally I'd love it if send did something like:
(1) if text is entirely 7-bit: specify charset=us-ascii
(2) if environment specifies a non-ascii character set, use that
(3) assume charset=utf-8 (maybe allow this to be overridden in profile)
but I'm not sure anyone else cares enough about it.
regards, tom lane
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility
Ken Hornstein <k...@pobox.com> writes: >> Apparently, it's also trying to enforce that by rejecting any >> non-plain-ASCII content. This is a real pain, mainly because whatever >> it's doing isn't playing well with exmh: the post simply silently doesn't >> happen. That's several notches below the already pretty awful handling >> of post errors that I was used to. > AFAIK, when send doesn't happen you should always get an error, and an > exit with a non-zero error code. Certainly when a send fails for me > with exmh I always know about it. This is assuming you don't use -push. > So if this is failing, then that's a bug. If you're using -push ... well, > then what is happening is exactly what is supposed to be happening :-/ Yeah, I've been using exmh's "async" mode, which is documented as doing the send in background and returning errors via email. I see that this appears to boil down to adding "-push -forward" to the arguments to send. If I switch exmh to the "wait" mode and try a failing case, I get a popup window with /usr/bin/mhbuild: exit 1 mhbuild: Text content contains 8 bit characters, but character set is US-ASCII so I guess I'll be changing over to that. > Hm, in theory I see that you're supposed to get email back when push > fails. I'm not sure that's been tested in like forever. I'm not actually > sure what is supposed to do that. Ah, alright ... I see there's an alert() > function in uip/sendsbr.c. I suspect we're not calling that if mhbuild > fails. The problem I've had with it in the past is that in a situation where *no* mail can be sent, you don't get a notification back. Not much surprise there, and I've found that the error message does get left behind in a file in the drafts folder. But this mhbuild failure neither sends warning mail nor leaves any file that I can find. > Which would happen if (a) you put an 8-bit character in your draft, and > (b) your locale is set to US-ASCII. Nmh takes the character set to use > out of the user's locale. I generally run with LANG=C, which I suppose would have that effect. I could probably arrange to override that environment setting while calling "send", but it'd be easier if send had a command line switch for it. Thanks for responding! regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] nmh 1.6: character set checks and exmh compatibility
So I updated to the new RHEL6 package of nmh 1.6 (had been on 1.5).
I've found that it now wants to mime-ify outgoing mail and among
other things attaches
Content-type: text/plain; charset="us-ascii"
Apparently, it's also trying to enforce that by rejecting any
non-plain-ASCII content. This is a real pain, mainly because whatever
it's doing isn't playing well with exmh: the post simply silently doesn't
happen. That's several notches below the already pretty awful handling
of post errors that I was used to.
I don't usually compose mail that isn't straight ASCII, but I've already
been burnt twice this morning by trying to forward text that included
a stray UTF8 character or two.
Any suggestions on how to improve this? Ideally I'd like it to pass
through what it's told to, perhaps changing the charset marking to
utf8 when necessary.
regards, tom lane
___
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
Ken Hornstein <k...@pobox.com> writes:
>> For EL6, the build needs to use autoconf268 instead of
>> autoconf. And it needs automake 1.12, but it looks like
>> automake 1.11 is installed, so that might be a show stopper.
> Do they want to actually build from a git checkout, or a distribution
> tar file? If it's the latter, it shouldn't matter what Autotools version
> is installed.
Normal expectation is that builds should be done from a released tarball
if the upstream publishes such. In my former life as a Red Hat employee,
I did maintain some packages that needed to have patches applied to
configure.in and then were re-autoconf'd from there, but I believe that
was the exception (and generally an indication of poor autoconfiscation,
or a ridiculously ancient autoconf version used by upstream).
I do not know how David came to the conclusion that EL5 does not have
autoconf/automake packaged, but I will state for a fact that it does,
and so did very many Red Hat releases before it, because I maintained
packages that depended on them.
regards, tom lane
___
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
valdis.kletni...@vt.edu writes:
> On Mon, 26 Sep 2016 18:57:43 +0100, Ralph Corderoy said:
>> And nmh in Fedora, but it's not in a Red Hat?
> It's not in the EPEL repos either (which are basically extras
> from Fedora built for Red Hat). Might be hard to get it into
> Red Hat without somebody at RH taking it under its wing, but
> EPEL is controlled by Fedora, so probably could the Fedora
> package owner to roll an EPEL version?
Yeah. Try filing a bugzilla request for that (against the existing
nmh package, I think).
As you say, the hurdle to getting it into core RHEL is a lot higher,
but I think EPEL is pretty easy if there's already a Fedora package.
regards, tom lane
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] TLS certificate validation
Ken Hornstein <k...@pobox.com> writes: > I've been poking around and I see that there is something that MIGHT > be worthwhile to look at: something called "trust on first use" (TOFU) > which basically replicates the SSH key model; upon first connection you > decide to trust the certificate you get, and you save that for later. +1 > How this works when certificates expire is a little unclear to me; > maybe you save the whole certificate chain and you decide to trust new > certs that go back to the original root. Look into what ssh does about it --- I don't recall having seen expired-cert complaints from ssh, so I'm guessing they must deal with this somehow. > If this was enabled by default > we'd get a lot better security out of the box. Certainly better than no security. For people who do want to deal with their own certs, that could be the limiting case of the cert already being present in the right place before first use. regards, tom lane ___ 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
Ken Hornstein <k...@pobox.com> writes: >> Idly, http://www.libressl.org/ is one alternative, aiming to improve the code >> quality amongst other things. It includes a new libtls "designed to >> make it easier to write foolproof applications" as well as "libssl: a >> TLS library, backwards-compatible with OpenSSL". > Well, I can tell you that's how _I_ want to spend my free time: porting > our code to OTHER TLS IMPLEMENTATIONS! :-) It's worse than that: people will expect you to operate with either one, but LibreSSL's "backwards compatible" wrapper is only mostly so. Postgres had to give up depending on OPENSSL_VERSION_NUMBER to make it work: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5c6df67e0c961f68e73e7c1e6312211ed59da00a Somebody will need to test against old openssl, new openssl, *and* libressl before you can be confident that you won't be getting complaints around this area. (No, I'm not volunteering.) > In seriousness ... this is a tough one. I have zero love for the OpenSSL > API (I wish someone would sit down and write how they expect memory > management to work), but as far as I can tell it is by far the most > popular TLS implementation out there; you're guaranteed to find either > it shipped with the operating system or an available package of it. Yeah, exactly --- you will find *some* flavor of that API on just about any platform. Walking away is not a feasible option, despite the fragmentation :-( regards, tom lane ___ 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
Ken Hornstein <k...@pobox.com> writes:
> Hm. It seems that the preferred function is now OPENSSL_init_ssl(), but
> there is a macro which still makes the old SSL_library_init() function
> work. I guess that test doesn't include that header file; that might be
> a bit sneaky to fix, but I think we can do it.
The core issue is that autoconf probe macros like AC_CHECK_LIB() will only
succeed against names that are actual global linker symbols, ie functions,
not C macros. SSL_library_init() is not in that category as of 1.1.0.
You want to pick one that is an actual function in both older and newer
OpenSSL releases. Postgres went with SSL_new(); there are doubtless
others that would work.
regards, tom lane
___
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
Lyndon Nerenberg <lyn...@orthanc.ca> writes:
> This seems more like a package builder error:
> checking for SSL_library_init in -lssl... no
> configure: error: OpenSSL library not found
> debian/rules:24: recipe for target 'build-stamp' failed
Actually, no: OpenSSL 1.1.0 made that function into a macro. They
don't seem to particularly care about ABI compatibility.
The Postgres project has been dealing with this mess over the last few
weeks :-(. See here and here:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=593d4e47db7af1a3a5dd6b6b1971f181b5566dbd
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5c6df67e0c961f68e73e7c1e6312211ed59da00a
nmh's pain points will be a bit different, but you will have some.
regards, tom lane
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] macos x 11 :-P
Lyndon Nerenberg <lyn...@orthanc.ca> writes: > So I tried building on El Torrito Burrito whatever-the-fsck-name current > version of MacOS, tonight. (10.11.3, Xcode 7.2.1 (7C1002).) > Epic fail. cpp doesn't know the location of openssl/ssl.h (which does exist, > in several locations under > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10xxx). > Once upon a time (<= 10.9?) there was a program you could run to switch the > default SDK for the command-line compilation tools. I can't find it any more. > I abandoned MacOS as a development platform a while ago, so I'm woefully > behind on the latest Xcode fu. Are there any MacOS C developers out there > who can catch me up? Apple stopped shipping the openssl headers a year or two back. (The copies you see must be from back-rev SDKs; there are none on my laptop.) It looks like they still provide the shared library, but it's pretty useless if you can't compile new source against it, and it also looks ancient: $ ls -l /usr/lib/*ssl* -rwxr-xr-x 1 root wheel 400608 Sep 9 2014 /usr/lib/libssl.0.9.7.dylib* -rwxr-xr-x 1 root wheel 616560 Aug 5 2015 /usr/lib/libssl.0.9.8.dylib* lrwxr-xr-x 1 root wheel 18 Oct 18 2014 /usr/lib/libssl.dylib@ -> libssl.0.9.8.dylib Personally I just install openssl from source into /usr/local and then build/link against that. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem compiling nmh 1.6 on linux gentoo
Ken Hornstein <k...@pobox.com> writes: > Normally we don't expect anyone to run a 'make clean' after running > configure (I'm trying to figure out why you would want to do that). Really? I should think that would be a supported procedure. FWIW, I would not expect either "clean" or "distclean" to remove files that were shipped in the tarball; only "make maintainer-clean", or some such target not meant to be called by end users, ought to do that. > If you do a 'make clean' or otherwise remove sbr/dtimep.c, it is > generated by lex or flex (probably flex) that is shipped on _your_ > system. In your case, the resulting output was not able to be compiled > by the compiler that exists on your system. As far as I can tell (and I've got quite a bit of data to back me up), there are no C compilers anywhere anymore that don't accept //-style comments by default. gcc will reject them only if you specify -ansi ... which John did: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I./sbr -DNMHETCDIR='"/etc/nmh"' -DMAILSPOOL='"/var/mail"' -DSENDMAILPATH='"/usr/sbin/sendmail"' -DNMHBINDIR='"/usr/bin"' -DNMHLIBDIR='"/usr/lib64/nmh"' -D_GNU_SOURCE -g -O2 -ansi -pedantic ^^^ -Wno-unused-result -Wall -Wextra -MT sbr/sbr_libmh_a-dtimep.o -MD -MP -MF sbr/.deps/sbr_libmh_a-dtimep.Tpo -c -o sbr/sbr_libmh_a-dtimep.o `test -f 'sbr/dtimep.c' || echo './'`sbr/dtimep.c I would put the true blame on whatever decided to add -ansi -pedantic (particularly the latter) to the compiler switches. Those are useful switches for software developers to use, if they are concerned about hewing as closely as possible to ancient C standards ... but one should never ever set things up to select them by default for builds in-the-wild. That won't ever lead to anything but grief, as it did here, because you can't expect that system tools or system header files are going to still be trying to be C89-compliant, let alone satisfy -pedantic. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] problem compiling nmh 1.6 on linux gentoo
Ken Hornstein <k...@pobox.com> writes: >> I would put the true blame on whatever decided to add -ansi -pedantic >> (particularly the latter) to the compiler switches. Those are useful >> switches for software developers to use, if they are concerned about >> hewing as closely as possible to ancient C standards ... but one should >> never ever set things up to select them by default for builds in-the-wild. >> That won't ever lead to anything but grief, as it did here, because you >> can't expect that system tools or system header files are going to still >> be trying to be C89-compliant, let alone satisfy -pedantic. > (Personally, I still think it's rather unfriendly for tools like flex to > generate code with new-style comments, but I'm probably in the minority > on that one). Personally I agree; but it's 2015 and it's not exactly unlikely that people aren't checking their patches against strict-C89 compilers. So on the principle of "be conservative in what you send and liberal in what you accept", the best approach is to make your own code compile under strict settings, but not to assume that everything you'll get compiled with is equally clean. This may mean that there need to be separate "maintainer" compile flags, so that the strict settings aren't part of the default. I haven't studied the nmh build logic in awhile, so not sure how painful that might be. > And you know ... the weirdest thing is, that particular comment in the > flex skeletion does not appear in the revision history of flex anywhere. > It's definitely in the distribution, but not in the tree on sourceforge. > So I don't know who inserted it. Odd. It does not look like it'd be a vendor-specific patch ... regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] better HTML rendering for selective emails
Michael Richardson m...@sandelman.ca writes: I use mh-e under GNU Emacs. (I used to run Xemacs). HTML rendering is okay, and 99% of the time, I prefer the text/plain anyway. But when I need it, I need it bad, and I forw -mime to my gmail account. (Talking HTML emails with tables. The worst offender is a status report *I* wrote. HTML tables was the right answer) I am looking another solution. I have tried exmh, but it's not really better. So I'm back to thinking about an IMAP server on top of MH (running on my desktop) plus thunderbird running wherever, read-only access is just fine, and it comes to UW-IMAP as the best solution. I just want to be sure I'm picking the best solution here. Another solution would extract the HTML into a file, and then tell my web browser (which, if I'm SSH'into my desktop, is the browser on the machine I'm SSH'ed *from*) to load that HTML file. FWIW, exmh has an ability to do effectively that, ie, pass off html chunks to a browser for rendering. I generally don't use it so I'm not sure how smooth it is, but I remember that it's there. What I do use a lot in exmh is the ability to pass off a link to a browser to open. I had to do some additional scripting to get this to work in the case that I care about (exmh is talking to an X server on my Mac laptop, but the browser I like is OS X Safari which doesn't know from X events, so I've got a shim in there to translate to AppleEvents). You could probably jury-rig something similar without bothering with exmh. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] ancient dev systems?
Lyndon Nerenberg lyn...@orthanc.ca writes: On an unrelated note, do any of you ancient MacOS folks have a version of Xcode installed that has the 'bsdmake' command? The bastards at Cupertino have nuked it from recent Xcode. I'm building a replacement, but I need access to the old bsdmake template files, all of which are long gone from my MacOS boxes :-P I see it on both 10.4 and 10.6 ... which files do you want, from which version? regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] First release candidate of nmh 1.6 now available
Jerrad Pierce belg4...@pthbb.org writes: P.S. Although env is noted as a portability measure for scripts, it's worth noting that it is reliant upon a properly configured PATH. FWIW, use of env in this way is a bit of a religious issue; some people think it's good and others say differently. My former employer Red Hat actually has a policy against use of env in this way in distro-supplied scripts (instituted after a long internal discussion that started with a proposal *for* always using env). I don't recall all the arguments, but I think it came down to a decision that such scripts should prefer invoking the official copy of perl and not any unofficial one that someone might have in their PATH. Obviously the stakes get higher for scripts that the root user might run, and I think that was part of it too. Whichever way you do it will make somebody unhappy. But personally, I'd rather see nonstandard-perl-location be handled by explicitly putting the right /path/to/perl into the scripts at build time, based on the configure script's determination of which perl to use. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Compiler warnings and signed vs. unsigned char, again
Ken Hornstein k...@pobox.com writes: So since the prototype for functions like strcpy() and the like are char, in theory this would suppress the warnings. But still ... I understand David's reasons for wanting to use unsigned char (it feels more correct to me as well), but I hate the idea of relying on specific C compiler options. For better or worse the POSIX API has pretty much mandated that C character strings are char, and casting the arguments to the ctype macros seems to be the way the world deals with that. FWIW, strings as char * and then explicitly casting all ctype.h macro arguments to unsigned char is the solution the postgresql project has been using for quite some time, so I'm familiar with it. It works; the main downside is that if you forget the (unsigned char) someplace, you won't get any warning that the usage is unportable, and most likely you won't notice the mistake in testing either. I have one machine on which I've hacked things up so that I do get a warning from such constructs --- what you need is for the ctype macros to expand to array references, and then make sure gcc's warn-for-char- used-as-subscript option is on. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] fseek(fp, 0, SEEK_CUR)?
Ken Hornstein k...@pobox.com writes: inc.c contains two occurrences of this: fseek (fp, 0L, SEEK_CUR); pos = ftell (fp); Is that fseek() ever necessary? Hrm. According to the man page, a successful call to fseek() clears the eof indicator and undoes any ungetc() call. Not sure we want the latter, but maybe they're trying to do the former? fp is opened using fdopen(.., w+), so I could see it being at EOF. If it's opened w+, maybe the point is to be sure the ftell reports the current EOF rather than wherever we last wrote ourselves. Is the file in question likely to be concurrently extended by other processes? regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] fseek(fp, 0, SEEK_CUR)?
I wrote: If it is read/write, I seem to recall that fseek is advised when switching between read and write modes. Here's a more precise statement from an old HPUX fopen() man page: When a file is opened for update, both input and output can be done on the resulting stream. However, output cannot be directly followed by input without an intervening call to fflush() or to a file positioning function (fseek(), fsetpos(), or rewind()), and input cannot be directly followed by output without an intervening call to a file positioning function unless the input operation encounters end-of- file. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Git Annoyances
Lyndon Nerenberg lyn...@orthanc.ca writes: What would be useful, though, would be links to a set of diffs that could be viewed externally. FWIW, Postgres (my main project) sends out commit log mail that links to commitdiff displays on our gitweb server. Samples can be seen in the list archives here: http://archives.postgresql.org/pgsql-committers/ and you can click through to the gitweb pages if you want. I don't know much about the infrastructure underlying that service, but I know who to ask if you want details. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] colorized/highlighted scan output?
Ken Hornstein k...@pobox.com writes: - Can we use curses? Short answer: no. Check. - Can we use terminfo? Short answer: maybe. My gut feeling is that terminfo seems to be what people have converged to using. It's not apparant at first glance how you translate a terminfo capability to the actual output characters, but let's assume it's possible (hm, looks like what you do is tparm()/tputs()). So that would mean we'd have to add a fair number of format functions that would do the various terminfo stuff, but maybe that wouldn't be so bad. I was envisioning just one function, that takes the terminfo symbolic name of a capability and gives back the actual string. - Can we just stick with the original idea of outputting escape characters? Well ... maybe. The problem is the limitation of the format language. For example, you can't have an argument to a function which contains a ')' character. Maybe that isn't a concern. We might need two new format functions, ones that turn zero width mode on and off (and thus two new format instructions). Good point. I'm inclined to think that it's a good idea to provide this even if we also provide the terminfo-accessing function, since there is always going to be somebody who wants to do something that doesn't fit into what (his) terminfo knows. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] colorized/highlighted scan output?
David Levine levin...@acm.org writes: Ken wrote: My issue is straightforward and doesn't require any user-visible changes, but I am thinking your issue might. I am wondering if you've thought about how you'd make this work; maybe a format escape that says, Don't count these characters against the width total? Or something else? I was thinking of looking for ANSI sequences and not counting them. But I don't know if that could get into trouble with multibyte characters. mbtowc() is too much of a mystery to me. That format escape would avoid the issue. +1 for a don't count this format escape. I don't think scan should be assuming anything about what the terminal might take to be an escape sequence. They're not that well standardized. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Message-IDs and Content-IDs
David Levine levin...@acm.org writes: Non-qualified hostnames do get used, even to this list. I looked at a small collection of spam and saw hardly any random hostname parts, but the sample is biased (it got through some filters) and very small. I have a rather larger collection of spam handy ... and there's quite a lot of unqualified hostnames in there, as well as quite a lot of raw IP addresses. I would suggest trying to make sure that the phony-hostname part doesn't look like either of those categories. I don't personally use such a thing as spam sign, but I bet some people do. Perhaps it would do to intentionally insert a couple of dots in the otherwise random string, ie instead of ...@QcTLPy+DeAJLdhEN something like ...@QcTLP.y+DeA.JLdhEN. Personally I'd be inclined to limit the characters used for the random data to alphanumerics, too, to make it look more like a hostname. If you want 64 characters so that it works like base64, maybe add - and _ to the repertoire. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Message-IDs and Content-IDs
Ken Hornstein k...@pobox.com writes: What still doesn't have /dev/random, and what does software do to compensate? I'm only mentioning this because we got recent bug reports about things not working right because of a buggy snprintf() on an ancient HPUX box. Does the ancient HPUX box in question have /dev/random? Good question; dunno. That was mine, and no it doesn't have /dev/random. But, as I said earlier, I'd prefer to opt-out of this whole cryptographic host part concept anyway. I think as long as you provide an option to still use the regular host name for message IDs, people who don't have /dev/random have an escape. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Message-IDs and Content-IDs
David Levine levin...@acm.org writes: Do you want LocalName(0), which can use localname from mts.conf? Or is the current use of LocalName(1) OK? The current way is fine with me, but I don't think the other would be a problem either. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Message-IDs and Content-IDs
David Levine levin...@acm.org writes: I've been thinking more about Message-IDs. The way nmh, sendmail, and Fedora configure things by default, the host part is worthless, but I expect that's common in these halcyon days of NAT. Agreed ... that's a problem ... but So I'm thinking of generating a Message-ID based on a MAC address. ... MAC addresses are just as forge-able; there are utilities on any modern OS to let you spoof that. Moreover, if I have a machine that *is* exposing a real, legitimate, vendor-assigned MAC address, I'm not sure I want to publish that to the world. At the least it's telling anybody who wants to know what sort of hardware I'm running. More generally, I'd prefer to opt out of any scheme that involves creating an anonymized message ID. It looks way too much like something a spammer would do. I know I've got filters that will bit-bucket messages with all-hex message IDs; I'm probably not the only one. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan -width behaves oddly in 1.5RC3
Ken Hornstein k...@pobox.com writes: So my conjecture is that on your systmes if snprintf() cannot fit a value in the width specified then it simply refuses to put anything in there. My reading of the specification is that this is the correct behavior. Whoops, I meant to say this is INCORRECT behavior. But the more I look at it the more I'm thinking you're getting tripped up by the old glibc bug with snprintf(). Well, this is an ancient HPUX box, and it most certainly isn't using glibc. I think that portable software shouldn't be assuming very much about what snprintf does when the string doesn't fit; it's only in rather recent editions of POSIX that that's nailed down, and even there it seems to be only implied, not stated explicitly, that the buffer should be filled as far as possible. I will take a look and see how painful it is to remove the assumption. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan -width behaves oddly in 1.5RC3
Ken Hornstein k...@pobox.com writes: I suspect if you check the return value of snprintf() in this case you'll find it's been set to -1. And in my reading of the standard it seems clear that it's supposed to write as many bytes as will fit in the buffer. I haven't had time to check, but I suspect -1 is what it's giving. I disagree with your reading of the standard though: -1 means failure, and in a failure case there is not any specification about what went into the buffer. I am prepared to agree that if the result is positive, then the buffer should have been filled to min(result, buflen) bytes. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] scan -width behaves oddly in 1.5RC3
Ken Hornstein k...@pobox.com writes: I haven't had time to check, but I suspect -1 is what it's giving. I disagree with your reading of the standard though: -1 means failure, and in a failure case there is not any specification about what went into the buffer. I agree with that ... but why is it failing? If the only reason it's failing is because the buffer isn't big enough, that is wrong; it's supposed to return the number of bytes it wanted to write. My reading of the code we have now is that it's correctly rejecting the case where snprintf() returns -1. [ some experimenting later ... ] What it appears to be doing is filling the buffer to the specified length and then returning -1 anyway. Given your argument that there is no reason for it to fail, I suppose the quickest hack is to assume that -1 means the same as buffer filled. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] 1.5RC3 no longer honors mts.conf localname setting for Message-ID?
I notice that Message-IDs are now generated using LocalName(1), ie, it ignores any localname setting from mts.conf. This seems bizarre and unfortunate, as surely forcing the Message-ID host part is one of the main use-cases for setting localname in the first place. For the moment I intend to carry a local patch to s/1/0/ at those call sites, but I wonder if this decision could be revisited. (I failed to find any discussion of it in the archives, though quite likely I didn't know what to search for.) BTW, while I am looking at this, it seems even more bizarre that LocaleName will apply localdomain even when it's ignoring localname. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.5RC3 no longer honors mts.conf localname setting for Message-ID?
I wrote: Well, that's probably fine, but then how do I get post to *not* generate a Message-ID? That is the default out-of-the-box behavior AFAICT, Oh, scratch that, I found send: -msgid buried in my .mh_profile. That's been there so long that I don't know what the origin was ... In any case, if the code is going to have the ability to generate a Message-ID at all, meseems it ought to be configurable. I still stand by this opinion though. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.5RC3 no longer honors mts.conf localname setting for Message-ID?
Ken Hornstein k...@pobox.com writes: Hrm. I guess I hadn't completely thought about the implications of how localdomain was implemented; I didn't really think about the issue of LocalName(0) versus LocalName(1). But your point is well taken; it doesn't really make sense to apply localdomain to both, does it? I think that if you're using localname you would be expected to supply a FQDN, and localdomain should only apply in the LocalName(1) case. My gut feeling is that localdomain is so rarely used nowadays that it's not worth fixing it for 1.5. Thoughts from anyone else? For post-1.5 I'd be fine with either using localdomain for only the LocalName(1) case or junking support for it completely. Or perhaps doing something else altogether. Thoughts? ISTM there is a fairly clear use-case for using localdomain to fill out an unqualified hostname returned by getaddrinfo(). I have no idea whether there are still any platforms on which getaddrinfo() would act that way, but if there are, they would want this feature. On the other hand, it's not clear to me what the use-case is for specifying an unqualified localname and then filling it out with localdomain; why not just write localname as the FQDN to start with? It seems like the first method could possibly be useful if there are any places where localname is used without appending localdomain, but I don't see any such places in the current code. (Not that I know the code well enough to know whether there are any non-obvious access paths.) So AFAICS it makes sense to redefine localdomain as only being used with the getaddrinfo result. Furthermore, if the LocalName(0) versus LocalName(1) business is new in 1.5, I'd argue for making the change now, so that people only have to cope with one behavioral change not two successive ones. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.5RC3 no longer honors mts.conf localname setting for Message-ID?
JerryHeyman heym...@bellsouth.net writes: fwiw, I've always used a localname entry in my mts.conf file. I do know that I needed it when I wanted to use userid@domainname as my return address rather than userid@machine.domainname - as the machine name isn't exposed to the internet, but my domainname is. Yeah, mine is the same situation: sss.pgh.pa.us is a domain name, not the whole FQDN of any one machine in my house network. The reason I was griping about Message-ID usage is that I prefer the message IDs to not expose internal machine names, either. (BTW, after some experimentation I realized that there is a good reason to have post assign Message-IDs rather than let the MTA do it: if post does it then the Message-ID gets included in the Fcc-filed copy, which at least for me is a significant advantage. So I don't plan to take Ken's advice of dropping the -msgid switch, and will persist with hacking the source code to make the message IDs be generated the way I want.) regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.5RC3 no longer honors mts.conf localname setting for Message-ID?
Ken Hornstein k...@pobox.com writes: (BTW, after some experimentation I realized that there is a good reason to have post assign Message-IDs rather than let the MTA do it: if post does it then the Message-ID gets included in the Fcc-filed copy, which at least for me is a significant advantage. So I don't plan to take Ken's advice of dropping the -msgid switch, and will persist with hacking the source code to make the message IDs be generated the way I want.) To be fair ... I wasn't suggesting that's what you do; my point only was that the last time people talked about that, the majority of responses (actually, all of them) indicated that they didn't use -msgid. If people think there's justification for a knob that controls the hostname used for message-id generation (among other things) then I'm fine with that. Contributed code would be welcome. It seems like the cleanest solution would be to have a parameter analogous to clientname, that overrides the normal default (ie, the host name returned by getaddrinfo) for the specific usage of generating the message-ID host part. This is analogous to clientname in that clientname overrides the default for the specific usage of sending the HELO message. If that seems sensible, and we can agree on a name for the thing (any suggestions?), I'd be willing to draft a patch. BTW, thinking about clientname, I wonder why that wasn't folded in as another responsibility of LocalName(). I'd certainly be inclined to implement localname, clientname, and this new parameter as facets of a single mechanism. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] A € for your thoughts - should we fix UTF-8 subject output in scan for 1.5?
Ken Hornstein k...@pobox.com writes: My question back to you: do the is* functions take bytes, or characters? If they take bytes, then I agree with you. If they take characters ... well, I'm not sure what is right. Quoting POSIX:2008, for isalnum and friends: The c argument is an int, the value of which the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF. If the argument has any other value, the behavior is undefined. So these functions only work portably in single-byte encodings. Particular implementations might choose to make them do something useful for input values above 255, but you couldn't expect that to work everywhere. To work portably in UTF8 and other multi-byte encodings, you have to go over to the wide-character functions in wctype.h. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] A € for your thoughts - should we fix UTF-8 subject output in scan for 1.5?
Ken Hornstein k...@pobox.com writes: So these functions only work portably in single-byte encodings. Particular implementations might choose to make them do something useful for input values above 255, but you couldn't expect that to work everywhere. To work portably in UTF8 and other multi-byte encodings, you have to go over to the wide-character functions in wctype.h. Yeah, but the issue isn't about values about 255, it's about values above 127. Your locale is UTF-8, and you call isspace(0xa0). Does that mean the character 0xa0, which is U+00A0 (a space)? Or does it mean one byte of a multibyte character, in which case ... who knows? Well, I would say that the standard's authors wrote character with malice aforethought, and that what they meant was that the value had to represent a character, not one byte of a multibyte character. So if isspace(0xa0) means anything in UTF8 encoding, it would have to refer to the Unicode code point U+00A0. However, in practice I'm not sure what good it does you to worry about whether or not that works, because if you want to support anything beyond LATIN1 you need to be using iswspace() anyway. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] A € for your thoughts - should we fix UTF-8 subject output in scan for 1.5?
Ken Hornstein k...@pobox.com writes: The question I have, however, is this: should this be fixed for 1.5? I would argue that it should because this is (for me) a significant charset bug. Another part of me says this might be too much this late in the release cycle. Thoughts? Considering that this has never worked before, it seems a bit late in the release cycle to be fixing it post-RC2. I'm for fixing it soon, mind you, but adding new features during RC seems to invalidate the whole concept of a release QA cycle. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Portability issues in nmh 1.5-RC2
Ralph Corderoy ra...@inputplus.co.uk writes: Hi David, Tom wrote: Another problem I ran into is that the regression test scripts use some shell features that the bare-bones /bin/sh on this machine doesn't recognize. I would be interested to know what shell incompatibilities you ran into so we could fix them. I tested with heirloom-sh but that apparently wasn't good enough. You could try dash(1) but perhaps it's HP's sh not being POSIX enough as opposed to nmh using non-POSIX features. Hmm, I dunno. The symptom I saw was that about half of the regression tests reported FAIL: test-name without any other output whatsoever. After I switched the shell to use /bin/ksh (Korn shell) they worked. If anyone's got an idea how to debug such failures, I'm game to look into it ... but I'm not really sure it's worth your time. An easy way to override the shell selection seems like a good idea in any case, and I'm perfectly happy if that's all you do. regards, tom lane ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
