[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Describe which environment variables really control the inte
From: |
Bruno Haible |
Subject: |
Re: [PATCH] Describe which environment variables really control the interpretation of the response to -ok. |
Date: |
Sun, 27 Apr 2008 23:36:01 +0200 |
User-agent: |
KMail/1.5.4 |
James Youngman wrote:
> The attached patch updates the findutils documentation to more
> correctly explain the relationship between the environment and the
> behaviour of rpmatch(). However, since I note that other
> POSIX-defined tools should also heed LC_COLLATE (cp, for example) I'm
> copying this to the gnulib mailing list.
I think you are misunderstanding what POSIX says: In [1] it says that
nl_langinfo (YESEXPR) and nl_langinfo (NOEXPR) use the locale category
LC_MESSAGES, not LC_COLLATE as you seem to understand.
In [2] it says that the interpretation of character ranges in the regular
expression returned by these calls uses the locale category LC_COLLATE.
This is what regcomp and regexec do anyway.
> gnulib folks, I see that rpmatch() seems to be insensitive to
> LC_COLLATE
No, it calls regexec and is thus sensitive to LC_COLLATE.
> that is, it doesn't use nl_langinfo to discover YESEXPR
> and NOEXPR. I guess this is a deliberate design choice.
That is a different design choice, that is worth to be documented better.
I'm adding the attached comments.
> What's the thinking behind it? At the moment, find follows gnulib and
> thus is not (AIUI) POSIX compliant.
No. If 'find' is built with ENABLE_NLS, i.e. if locale support is not
explicitly disabled by the user, it will use the LC_MESSAGES and LC_COLLATE
exactly as specified in POSIX [1][2].
The only non-POSIX behaviour is that it fetches the yesexpr and noexpr from
a compiled PO file rather than from the system's nl_langinfo function. I hope
the comments now adequately explain the rationale for this choice.
Bruno
[1] http://www.opengroup.org/susv3/basedefs/langinfo.h.html
[2] http://www.opengroup.org/susv3/utilities/find.html
2008-04-27 Bruno Haible <address@hidden>
* lib/rpmatch.c (rpmatch): Add some comments.
Reported by James Youngman <address@hidden>.
*** lib/rpmatch.c.orig 2008-04-27 23:29:09.000000000 +0200
--- lib/rpmatch.c 2008-04-27 23:17:49.000000000 +0200
***************
*** 1,7 ****
/* Determine whether string value is affirmation or negative response
according to current locale's data.
! Copyright (C) 1996, 1998, 2000, 2002, 2003, 2006 Free Software
Foundation, Inc.
This program is free software: you can redistribute it and/or modify
--- 1,7 ----
/* Determine whether string value is affirmation or negative response
according to current locale's data.
! Copyright (C) 1996, 1998, 2000, 2002, 2003, 2006, 2008 Free Software
Foundation, Inc.
This program is free software: you can redistribute it and/or modify
***************
*** 61,66 ****
--- 61,75 ----
/* Match against one of the response patterns, compiling the pattern
first if necessary. */
+ /* We get the patterns from a PO file. It would be possible to use
+ nl_langinfo (YESEXPR) instead of _("^[yY]"), and nl_langinfo (NOEXPR)
+ instead of _("^[nN]"), if we could assume that the system's locale
+ support is good. But this is not the case e.g. on Cygwin. The
+ localizations of gnulib.pot are of better quality in general.
+ Also, if we used locale info from non-free systems that don't have a
+ 'localedef' command, we would deprive the users of the freedom to
+ localize this pattern for their preferred language. */
+
/* We cache the response patterns and compiled regexps here. */
static const char *yesexpr, *noexpr;
static regex_t yesre, nore;