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.
gnulib folks, I see that rpmatch() seems to be insensitive to
LC_COLLATE; that is, it doesn't use nl_langinfo to discover YESEXPR
and NOEXPR. I guess this is a deliberate design choice. What's the
thinking behind it? At the moment, find follows gnulib and thus is
not (AIUI) POSIX compliant. Is there a reason I should avoid use of
nl_langinfo?
Thanks,
James.
From e3be8a352b4d33bef0b3436df0dad3e5c4a17beb Mon Sep 17 00:00:00 2001
From: James Youngman <[EMAIL PROTECTED]>
Date: Sun, 27 Apr 2008 20:59:45 +0100
Subject: [PATCH] Describe which environment variables really control the interpretation of the response to -ok.
To: [EMAIL PROTECTED]
Signed-off-by: James Youngman <[EMAIL PROTECTED]>
---
doc/find.texi | 19 +++++++++++++++----
find/find.1 | 6 ++++--
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/doc/find.texi b/doc/find.texi
index aa95456..b3977bd 100644
--- a/doc/find.texi
+++ b/doc/find.texi
@@ -3660,16 +3660,27 @@ The POSIX standard specifies that this variable affects the pattern
matching to be used for the `\-name' option. GNU find uses the
GNU version of the @code{fnmatch} library function.
-POSIX also specifies that the `LC_COLLATE' environment
-variable affects the interpretation of the user's response to the
-query issued by `\-ok', but this is not the case for GNU find.
+POSIX also specifies that the `LC_COLLATE' environment variable
+affects the interpretation of the user's response to the query issued
+by `\-ok', but this is not the case for GNU find. For GNU find, this
+support depends on the localisation of the @code{find} program's
+messages, and that is affeccted by the setting of the `LC_MESSAGES' variable.
+
@item LC_CTYPE
This variable affects the treatment of character classes used with
the @samp{-name} test, if the system's
@code{fnmatch} library function supports this. It has no effect on the behaviour
of the @samp{-ok} expression.
@item LC_MESSAGES
-Determines the locale to be used for internationalised messages.
+Determines the locale to be used for internationalised messages. Also
+determines the interpretation of the response to @code{-okdir} abd @code{-ok},
+though in the latter case this does not conform to POSIX.
[EMAIL PROTECTED] The non-conformance arises because the gnulib rpmatch module depends on _()
[EMAIL PROTECTED] to obtain a regexp matching a yes/no response, hence using LC_MESSAGES
[EMAIL PROTECTED] while POSIX assumes this depends on LC_COLLATE (I assume, via
[EMAIL PROTECTED] nl_langinfo(YESEXPR/NOEXPR).
+
[EMAIL PROTECTED]
@item NLSPATH
Determines the location of the internationalisation message catalogues.
@item PATH
diff --git a/find/find.1 b/find/find.1
index 5fa8680..2c6e635 100644
--- a/find/find.1
+++ b/find/find.1
@@ -1533,8 +1533,10 @@ Supported. POSIX specifies `b', `c', `d', `l', `p', `f' and `s'.
GNU find also supports `D', representing a Door, where the OS provides these.
.IP \fB\-ok\fR
-Supported. Interpretation of the response is not locale-dependent
-(see ENVIRONMENT VARIABLES).
+Supported. Interpretation of the response depends on the language
+localisation of the
+.B find
+program.
.IP \fB\-newer\fR
Supported. If the file specified is a symbolic link, it is always
--
1.5.3.6
