show's checkmime

On a new Linux installation, I have a UTF-8 locale enabled by default.
For this reason, I set MM_CHARSET to UTF-8. Recently, I noticed that
show invokes mhshow for messages with:
  Content-Type: text/plain; charset="us-ascii"
whereas that doesn't occur for ISO-8859-1.

UTF-8 is just as compatible with plain 7bit ASCII so I'll make the
change in the attached patch.

Shouldn't the code somehow be using nl_langinfo(CODESET) instead of the
MM_CHARSET environment variable?

Oliver

Index: sbr/check_charset.c
===================================================================
RCS file: /cvsroot/nmh/nmh/sbr/check_charset.c,v
retrieving revision 1.2
diff -u -r1.2 check_charset.c
--- sbr/check_charset.c	2 Jul 2002 22:09:14 -0000	1.2
+++ sbr/check_charset.c	21 Jan 2005 18:33:40 -0000
 <at>  <at>  -32,8 +32,9  <at>  <at> 
 	    mm_charset = "US-ASCII";
 	mm_len = strlen (mm_charset);

-	/* US-ASCII is a subset of the ISO-8859-X character sets */
-	if (!strncasecmp("ISO-8859-", mm_charset, 9)) {
+	/* US-ASCII is a subset of the ISO-8859-X and UTF-8 character sets */
+	if (!strncasecmp("ISO-8859-", mm_charset, 9) ||
+	        !strncasecmp("UTF-8", mm_charset, 5)) {

Re: show's checkmime

On Fri, 21 Jan 2005 19:55:19 +0100, Oliver Kiddle said:

> UTF-8 is just as compatible with plain 7bit ASCII so I'll make the
> change in the attached patch.

Seems sane, except for one little detail.  There's the corner case where
(for instance) the $LANG is set to something like fr_FR.UTF-8 (which means
that the system understands UTF-8, but it's quite possible that for actual
display, we can't be sure that we have all UTF-8 codeplanes available.  Such
a user may have done 'export MM_CHARSET="$LANG";', so we might want to check
if UTF-8 is found anywhere in the string:

+	if (!strncasecmp("ISO-8859-", mm_charset, 9) ||
+	        strstr(mm_charset,"UTF-8")) {

What do people think?

> Shouldn't the code somehow be using nl_langinfo(CODESET) instead of the
> MM_CHARSET environment variable?

The only reason it doesn't is because MM_CHARSET was created before nl_langinfo()
existed.  Also, we may still be advertising the ability to build it in some old
crufty environments that don't have nl_langinfo() *yet*, so we may need to have
an #ifdef/#else/#endif and some ./configure magic (or heave said environments
from last century over the side and be done with it.. ;)

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org

Re: show's checkmime

Hi Valdis,

> Seems sane, except for one little detail.  There's the corner case
> where (for instance) the $LANG is set to something like fr_FR.UTF-8
> (which means that the system understands UTF-8, but it's quite
> possible that for actual display, we can't be sure that we have all
> UTF-8 codeplanes available.  Such a user may have done 'export
> MM_CHARSET="$LANG";', so we might want to check if UTF-8 is found
> anywhere in the string:
> 
> +	if (!strncasecmp("ISO-8859-", mm_charset, 9) ||
> +	        strstr(mm_charset,"UTF-8")) {
> 
> What do people think?

I'd be wary of the original patch matching `UTF-8080' and this matching
`CRUTF-8'.  If that can't happen and any occurance of `UTF-8' must be
referring to UTF-8 then that's not a problem but I don't have required
knowledge.

Cheers,

Ralph.

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: show's checkmime

On Sat, 22 Jan 2005 11:43:48 GMT, Ralph Corderoy said:
>
> > Seems sane, except for one little detail.  There's the corner case
> > where (for instance) the $LANG is set to something like fr_FR.UTF-8
> > (which means that the system understands UTF-8, but it's quite
> > possible that for actual display, we can't be sure that we have all
> > UTF-8 codeplanes available.  Such a user may have done 'export
> > MM_CHARSET="$LANG";', so we might want to check if UTF-8 is found
> > anywhere in the string:
> > 
> > +	if (!strncasecmp("ISO-8859-", mm_charset, 9) ||
> > +	        strstr(mm_charset,"UTF-8")) {
> > 
> > What do people think?
> 
> I'd be wary of the original patch matching `UTF-8080' and this matching
> `CRUTF-8'.  If that can't happen and any occurance of `UTF-8' must be
> referring to UTF-8 then that's not a problem but I don't have required
> knowledge.

A user could, of course, set MM_CHARSET to some bogus value.  But I've never
encountered a language, charset, or font specification where the substring
"UTF-8" didn't in fact mean a UTF-8....

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: show's checkmime

On 21 Jan,  wrote:
> 
> a user may have done 'export MM_CHARSET="$LANG";', so we might want to check
> if UTF-8 is found anywhere in the string:

User's really shouldn't set MM_CHARSET like that. That'd result in
outgoing mime messages having something like charset="fr_FR.UTF-8" in
the Content-Type header instead of one of the canonical forms. If we
want to make it easier for user's to set MM_CHARSET, using nl_langinfo
is better. It was a mistake that I used strncasecmp with 5, in the
patch, just using strcasecmp is I think better.

> The only reason it doesn't is because MM_CHARSET was created before nl_langinfo()
> existed.  Also, we may still be advertising the ability to build it in some old
> crufty environments that don't have nl_langinfo() *yet*, so we may need to have
> an #ifdef/#else/#endif and some ./configure magic (or heave said environments
> from last century over the side and be done with it.. ;)

How about we continue to look in MM_CHARSET but check nl_langinfo where
possible if the environment variable isn't set. The simple patch for
that follows. The only difficult part is that nl_langinfo doesn't
necessarily return character sets in canonical MIME form. There's code
to convert it at http://www.cl.cam.ac.uk/~mgk25/ucs/norm_charmap.c
If nobody objects, the easiest is just to include that.

Oliver

Index: configure.in
===================================================================
RCS file: /cvsroot/nmh/nmh/configure.in,v

connecting to POP via an external command

One of the patches I apply against the nmh sources is a modification of
Michael Richardson's patch which can be seen here:
http://www.mhonarc.org/archive/html/nmh-workers/2002-07/msg00000.html

My modification to it is to run a different command to get around a
firewall issue I have. Anyway, I've had a go at making the patch more
general by making the command configurable. This means both inc and
msgchk gain a -proxy option for specifying the external command. This is
very similar to fetchmail's plugin option (which is actually what I
normally use) and to ssh's ProxyCommand option.

There are a lot of different uses for this. I haven't tried but it should
make it simpler to use stunnel for SSL support: instead of stunnel
needing to listen on port 110 on the local host, you would just run
it with -proxy. If you look at the original patch, you'll see that it
can be used to run a pop daemon directly, perhaps through ssh or rsh.
My use is 'ssh othermachine netcat -w 1 %h 110' which allows me to go
via a different machine and so bypass a restrictive firewall. The patch
below substitutes the hostname for %h. I've omitted to reindent popsbr.c
so you can see the changes more clearly.

Any comments on this would be welcome.

Oliver

Index: h/popsbr.h
===================================================================
RCS file: /cvsroot/nmh/nmh/h/popsbr.h,v
retrieving revision 1.3
diff -u -r1.3 popsbr.h

Question on compath() in sbr/path.c

Howdy.  I've been trying to figure out exactly what nmh does with folder names
so that I can have an external-to-nmh program treat them the same way.  I
noticed something curious in compath() in sbr/path.c

I'm guessing that the purpose of this function is to "compact a path" by
removing extraneous elements.

One of the tests (second one under case '.') looks for a trailing /.. on a
path.  It would convert a path of /foo/bar/.. to /foo.

This doesn't seem correct to me.  It works unless bar is a symbolic link.  A
/.. after a symbolic link climbs up the tree on the link target side of things,
not the link name.

So two questions:  Should I fix it and what's the correct fix?  If it should
be fixed, the only thing that I can see doing is to remove this section of code
because there's no requirement that the path passed to compath() exists, making
it impossible to test the path elements.

Jon

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Changelog policy

Oh, since I'm probably about to go make some changes again, I had an email from
somebody a while ago who was upset that I wasn't updating the Changelog when
making changes.  I wasn't doing it because I thought that it was done
automatically.  What's the policy on this?  Is it supposed to be done
automatically and is something broken?  Should it be updated manually every
time a change is made?  Or is is updated manually before every release?

Jon

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

More puzzlement - expath() in sbr/path.c

There is code in expath in sbr/path.c that just can't be correct.  The second
main if statement in this function includes what is, after some substitutions,

	if ( ... && strcmp(name, ".") && strcmp(name, "..") && ... )

This can never be true!

Can anybody out there explain to me what this function (and the others in
path.c) are *supposed* to be doing so that I can make them do what they're
supposed to do?

Jon

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: More puzzlement - expath() in sbr/path.c

> Jon Steinhart <jon <at> fourwinds.com> wrote on Jan 28, 2005:
> 
> >There is code in expath in sbr/path.c that just can't be correct.  The secon
> d
> >main if statement in this function includes what is, after some substitution
> s,
> 
> >	if ( ... && strcmp(name, ".") && strcmp(name, "..") && ... )
> 
> >This can never be true!
> 
> I don't see the problem.
> 
>   strcmp() returns non-zero (true) if the strings are *different*.
> 
> It is surely possible for name to be different from "." and to be
> different from ".." at the same time.
> 
>  -NWR

Oops.  Your're right.  Too much code blindness here.

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers