bug-gnulib
[Top][All Lists]
Advanced

[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;





reply via email to

[Prev in Thread] Current Thread [Next in Thread]