[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Merkwürdige Locale-Effekte in Bash (war: Re: Wohin mit den eigenen init-Skripten?)



Martin Steigerwald <martin@lichtvoll.de> wrote:

> Mal sehen, wie find das sieht:

> root@merkaba /t/test# find -name "[A-Z]"
> ./C
> ./B
> ./A
> root@merkaba /t/test# find -name "[a-z]"
> ./c
> ./b
> ./a

> Also so oder so ist das in sich inkonsistent: bash macht es anders als find, 
> das ebenfalls aus dem GNU-Projekt ist, und anders als die Z-Shell.

Ja, da scheint es im GNU-Projekt keine einheitliche Haltung dazu zu
geben. In der Doku zu find:

   <http://www.gnu.org/software/findutils/manual/html_mono/find.html#Shell-Pattern-Matching>

steht:

   [string]
           Matches exactly one character that is a member of the string
	   string. This is called a character class. As a shorthand,
	   string may contain ranges, which consist of two characters
	   with a dash between them. For example, the class `[a-z0-9_]'
	   matches a lowercase letter, a number, or an underscore. You
	   can negate a class by placing a `!' or `^' immediately after
	   the opening bracket. Thus, `[^A-Z@]' matches any character
	   except an uppercase letter or an at sign.

Da steht also ganz explizit drin, dass Groß-/Kleinschreibung beachtet
wird. Zur locale steht in der find-Doku:

   <http://www.gnu.org/software/findutils/manual/html_mono/find.html#Environment-Variables>

   LC_COLLATE
           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 fnmatch library function.

           This variable also affects the interpretation of the
	   response to -ok; while the LC_MESSAGES variable selects
	   the actual pattern used to interpret the response to -ok,
	   the interpretation of any bracket expressions in the
	   pattern will be affected by the LC_COLLATE variable.

Das kann man so verstehen, dass LC_COLLATE beachtet wird, und damit
also auch Lokalisierungen. Oder auch so, dass find den POSIX-Standard
beachtet, und POSIX definiert LC_COLLATE offenbar wie in LC_COLLATE=C,
nämlich strikt nach ASCII. Siehe:

   LC_COLLATE
   # This is the POSIX locale definition for the LC_COLLATE category.
   # The order is the same as in the ASCII codeset.
 
in:

   <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html>

Oder missverstehe ich das? Ich kann mir schlecht vorstellen, dass POSIX
keine Lokalisierungen für LC_COLLATE zulässt.

Alles etwas unübersichtlich, finde ich.

Gruß, Martin


Reply to: