Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread Ralph Corderoy
Hi, Ken wrote: > And if we're voting ... I would rather have only one additional way to > specify a nmh-specific locale (well, I'd rather have ZERO additional > ways, but I think more than one way is overkill). I'd rather have zero. :-) Anything above that surely warrants an nmhlocale(1). > (A

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread Ken Hornstein
>> (And it occurs to me that even setting the locale properly probably >> will not fix your specific problem, as you have described it; >> forwarding messages using MIME will). > >I don't think this got addressed. If a nmh-specific locale doesn't fix >the problem then let's not add it. As I under

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread Ken Hornstein
>But we aren't. I am saying UTF-8 is the native internal character >set. What happens at the boundaries becomes everyone else's problem. >And after all the grief in this discussion over the last five+ years, >don't you think it should be someone else's problem? Yeah, this is the part I don't under

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread Paul Fox
ken wrote: > >> (And it occurs to me that even setting the locale properly probably > >> will not fix your specific problem, as you have described it; > >> forwarding messages using MIME will). > > > >I don't think this got addressed. If a nmh-specific locale doesn't fix > >the problem then

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread Tom Lane
Ken Hornstein 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 com

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread Ralph Corderoy
Hi Tom, 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? 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 ASCI

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread Tom Lane
Ralph Corderoy 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 real

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread Laura Creighton
In a message of Tue, 18 Oct 2016 14:17:24 +0100, Ralph Corderoy writes: >Hi Tom, > >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? > >Have Emacs highlight non-ASCII characters in that mode wherever they >come from,

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread Ken Hornstein
>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-effec

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread Ralph Corderoy
Hi Tom, > All of these solutions presuppose that this is my problem and not the > software's. I respectfully disagree. Me too. :-) There's a mechanism for telling a hierarchy of programs their locale; environment variables. You're using it, but you're telling some of them a different locale t

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread Laura Creighton
In a message of Tue, 18 Oct 2016 15:13:49 +0100, Ralph Corderoy writes: >There's a mechanism for telling a hierarchy of programs their locale; >environment variables. You're using it, but you're telling some of them >a different locale to what you really want them to use. People do this a lot aro

Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

2016-10-18 Thread David Levine
Laura wrote: > I don't know about Tom, but my problem isn't that I want to send valid > US-ASCII emails, but that I _never_ want to send valid us-ascii emails. > And the last thing I want to happen is for nmh to not be able to > tell what I want, stick in us-ascii (because the thing needs a > con

[Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Ken Hornstein
Hi, I noticed that test/install-mh/test-version-check is hanging for me on MacOS X. Specifically, the "script" command on MacOS X seems to be the problem; for reasons I don't understand quite yet when "script" is run the input is set to /dev/null, and it turns out when THAT happens there is appar

Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread David Levine
Ken wrote: > I noticed that test/install-mh/test-version-check is hanging for me > on MacOS X. Specifically, the "script" command on MacOS X seems to be > the problem; for reasons I don't understand quite yet when "script" is > run the input is set to /dev/null, and it turns out when THAT happens

Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Ralph Corderoy
Hi, Ken wrote: > I noticed that test/install-mh/test-version-check is hanging for me on > MacOS X. Specifically, the "script" command on MacOS X seems to be > the problem; for reasons I don't understand quite yet when "script" is > run the input is set to /dev/null I've found a Mac Mini I can SS

Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Ken Hornstein
>I assume that it's not failing on this: > >if script -S /bin/sh 'echo OK' /dev/null 2>&1 | egrep 'OK' >/dev/null; > >because I don't think that MacOS X script supports -S. Yes, that's correct. The strange thing is ... the problem is _input_ redirection. This works fine on MacOS X: % script

Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Ken Hornstein
>I've found a Mac Mini I can SSH into, "15.6.0" if that means anything. Hm. I have that at home, but not at work (work is slightly older). >A git clone, brew install of a few things like openssl, and > >CPPFLAGS=-I/usr/local/opt/openssl/include \ >LDFLAGS=-L/usr/local/opt/openssl/lib \ >

Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Ken Hornstein
>Hm. At home, running El Capitan, it works. So, guess it's a bug in the >older version of "script". Yeah, THIS works fine on El Capitan: > >% script < /dev/null So, I see that the script(1) on El Capitan (but not the previous version of MacOS X) says: If script reads zero bytes from the t

Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Lyndon Nerenberg
> On Oct 18, 2016, at 4:21 PM, Ralph Corderoy wrote: > > I've found a Mac Mini I can SSH into, "15.6.0" if that means anything. Once I get back online I will have a VM running Sierra (macOS 10.12, aka kernel 16.0) to add to the buildbot cluster. I also have an older 32-bit Mini running Snow

Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Ken Hornstein
Alright, so what I've figured out is: - If you background a process in a shell script, it sets stdin to /dev/null. Which makes sense; it's just not something I ever thought about. So that explains why stdin for script was set to /dev/null. - The real problem isn't the tight loop for script(1

Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Lyndon Nerenberg
> On Oct 18, 2016, at 12:51 PM, Ken Hornstein wrote: > > I noticed that test/install-mh/test-version-check is hanging for me > on MacOS X. Specifically, the "script" command on MacOS X seems to be > the problem; for reasons I don't understand quite yet when "script" is > run the input is set to