String auf Großbuchstaben bringen - wie?
Egon A. Rath
Wie kann ich einen String, der in einer Variable steht (und zur Zeit
gemischte Groß- und Kleinschreibung hat) auf Großbuchstaben umwandeln?
Danke, Egon
Olaf Dietrich
>
> Wie kann ich einen String, der in einer Variable steht (und zur Zeit
> gemischte Groß- und Kleinschreibung hat) auf Großbuchstaben umwandeln?
Mit (n)awk und toupper.
Olaf
Cornelius Krasel
> Wie kann ich einen String, der in einer Variable steht (und zur Zeit
> gemischte Groß- und Kleinschreibung hat) auf Großbuchstaben umwandeln?
echo $var | tr '[a-z]' '[A-Z]'
--Cornelius.
--
/* Cornelius Krasel, U Wuerzburg, Dept. of Pharmacology, Versbacher Str. 9 */
/* D-97078 Wuerzburg, Germany email: kra...@wpxx02.toxi.uni-wuerzburg.de */
/* "Science is the game we play with God to find out what His rules are." */
Juergen P. Meier
>Egon A. Rath <Egon...@sr.lkh.ooe.gv.at> wrote:
>> Wie kann ich einen String, der in einer Variable steht (und zur Zeit
>> gemischte Groß- und Kleinschreibung hat) auf Großbuchstaben umwandeln?
>
>echo $var | tr '[a-z]' '[A-Z]'
verfeinert:
var=`eval echo \"$var\" | tr '[a-z]' '[A-Z]'`
So funktioiniert das auch mit fuehrenden und folgenden leerzeichen.
tested mit: bash (v2), ksh (Sun's ksh88), pdksh, sh (Sun), zsh.
Juergen
--
J...@lrz.fh-muenchen.de - "This World is about to be Destroyed!"
jsaul
> Cornelius Krasel <kra...@wpxx02.toxi.uni-wuerzburg.de> wrote:
> >Egon A. Rath <Egon...@sr.lkh.ooe.gv.at> wrote:
> >> Wie kann ich einen String, der in einer Variable steht (und zur Zeit
> >> gemischte Groß- und Kleinschreibung hat) auf Großbuchstaben umwandeln?
> >
> >echo $var | tr '[a-z]' '[A-Z]'
>
> verfeinert:
>
> var=`eval echo \"$var\" | tr '[a-z]' '[A-Z]'`
>
> So funktioiniert das auch mit fuehrenden und folgenden leerzeichen.
Schöne Lösung, nur leider falsch.
Test mit:
var=" a b c " # 2 Blanks zwischen a und b
var=`eval echo \"$var\" | tr '[a-z]' '[A-Z]'`
echo "$var"
zsh: Klappt.
pdksh, bash und SunOS 5.7 /bin/ksh:
> A B C <
(Ein Blank unterschlagen)
Es klappt dagegen (ohne eval) und auf bash, zsh, pdksh und SunOS 5.7
/bin/ksh:
var=`echo "$var" | tr '[a-z]' '[A-Z]'`
Und da wir schon dabei sind:
var=`echo "$var" | tr '[:lower:]' '[:upper:]'`
...Wie war das noch gleich, mit der FAQ für eval?
Gruß,
jsaul
--
+++ jsaul +++ http://www.jsaul.de +++
Juergen Salk
> Cornelius Krasel <kra...@wpxx02.toxi.uni-wuerzburg.de> wrote:
>>echo $var | tr '[a-z]' '[A-Z]'
> verfeinert:
> var=`eval echo \"$var\" | tr '[a-z]' '[A-Z]'`
> So funktioiniert das auch mit fuehrenden und folgenden leerzeichen.
Sicher?
$ var=" äöü "
$ echo "|${var}|"
| äöü |
$ var=`eval echo \"$var\" | tr '[a-z]' '[A-Z]'`
$ echo "|${var}|"
| äöü |
Soll heissen: Führende und folgende Leerzeichen werden
*nicht* richtig umgesetzt. Umlaute werden eventuell gar
nicht übersetzt.
Besser vielleicht mit Character-Klassen (Korrekt eingestellte
Locales vorausgesetzt):
$ var=" öäü "
$ var=`echo "$var" | tr '[:lower:]' '[:upper:]'`
$ echo "|${var}|"
| ÖÄÜ |
Beste Grüsse - Jürgen
Juergen P. Meier
>Juergen P. Meier <J...@lrz.fh-muenchen.de> wrote:
>> Cornelius Krasel <kra...@wpxx02.toxi.uni-wuerzburg.de> wrote:
>>>echo $var | tr '[a-z]' '[A-Z]'
>> verfeinert:
>> var=`eval echo \"$var\" | tr '[a-z]' '[A-Z]'`
>> So funktioiniert das auch mit fuehrenden und folgenden leerzeichen.
>
>Sicher?
Nein :-/
>$ var=" äöü "
>$ var=`eval echo \"$var\" | tr '[a-z]' '[A-Z]'`
>$ echo "|${var}|"
>| äöü |
>
>Soll heissen: Führende und folgende Leerzeichen werden
>*nicht* richtig umgesetzt. Umlaute werden eventuell gar
>nicht übersetzt.
>
>Besser vielleicht mit Character-Klassen (Korrekt eingestellte
>Locales vorausgesetzt):
>
>$ var=" öäü "
>$ var=`echo "$var" | tr '[:lower:]' '[:upper:]'`
>$ echo "|${var}|"
>| ÖÄÜ |
Argh, zuviel geqoutet. (die \" waren hier ueberfluessig.)
Mit den charackterklassen hast du natuerlich recht, solange das
der verwendete tr dies kann.
jsaul
> Juergen Salk <juerge...@gmx.de> wrote:
> >Juergen P. Meier <J...@lrz.fh-muenchen.de> wrote:
> >> Cornelius Krasel <kra...@wpxx02.toxi.uni-wuerzburg.de> wrote:
> >>>echo $var | tr '[a-z]' '[A-Z]'
> >> verfeinert:
> >> var=`eval echo \"$var\" | tr '[a-z]' '[A-Z]'`
> >> So funktioiniert das auch mit fuehrenden und folgenden leerzeichen.
> >
> >Sicher?
>
> Nein :-/
>
> >$ var=" äöü "
> >$ var=`eval echo \"$var\" | tr '[a-z]' '[A-Z]'`
> >$ echo "|${var}|"
> >| äöü |
> >
> >Soll heissen: Führende und folgende Leerzeichen werden
> >*nicht* richtig umgesetzt. Umlaute werden eventuell gar
> >nicht übersetzt.
> >
> >Besser vielleicht mit Character-Klassen (Korrekt eingestellte
> >Locales vorausgesetzt):
> >
> >$ var=" öäü "
> >$ var=`echo "$var" | tr '[:lower:]' '[:upper:]'`
> >$ echo "|${var}|"
> >| ÖÄÜ |
>
> Argh, zuviel geqoutet. (die \" waren hier ueberfluessig.)
Nicht nur überflüssig, sondern hier genau fehl am Platze, ebenso wie das
eval.
Was mich aber in dem Zusammenhang etwas stutzig macht ist, ob du dein
Konstrukt mit irgendwas anderem als der zsh wirklich ausprobiert hast.
Das würde dann nämlich versionsabhängiges Verhalten bedeuten, was
natürlich extrem lästig wäre, s.u.
In article <slrn9o9lr...@fm.rz.fh-muenchen.de> Juergen P. Meyer
wrote:
# tested mit: bash (v2), ksh (Sun's ksh88), pdksh, sh (Sun), zsh.
> Mit den charackterklassen hast du natuerlich recht, solange das
> der verwendete tr dies kann.
Liegt wohl weniger am tr als an der richtig eingestellten locale (s.o.,
Jürgen Salks Antwort). Hier auf SunOS 5.7 funktioniert's tadellos.
Gruß aus P,
Egon A. Rath
Danke für die Infos!!
Egon
Heiner Marxen
Cornelius Krasel <kra...@wpxx02.toxi.uni-wuerzburg.de> wrote:
>Egon A. Rath <Egon...@sr.lkh.ooe.gv.at> wrote:
>> Wie kann ich einen String, der in einer Variable steht (und zur Zeit
>
>echo $var | tr '[a-z]' '[A-Z]'
Uuh, das hat mich schon gebissen. Was fuer das a-z bzw. A-Z expandiert
wird, haengt davon ab, wie das locale gesetzt ist. Ein typisches
deutsches LC_COLLATE erzeugt recht wundersame Resultate. Also entweder
(a) ganz ausschreiben: abcdefghijklmnopqrstuvwxyz, oder
(b) character classes verwenden: [:lower:], oder
(c) ein Tool wie awk verwenden, das "tolower" als Funktion (builtin) hat.
[ Ich glaube ksh hat typeset-Optionen fuer sowas ]
In meinem Fall war (a) richtig, da die Operation unabhaengig vom aktuellen
locale sein sollte, und sowas wie Umlaute dort gar nicht vorkommen konnte.
--
Heiner Marxen hei...@insel.de http://www.drb.insel.de/~heiner/
jsaul
> In article <gcg2m9...@wpxx02.toxi.uni-wuerzburg.de>,
> Cornelius Krasel <kra...@wpxx02.toxi.uni-wuerzburg.de> wrote:
>>Egon A. Rath <Egon...@sr.lkh.ooe.gv.at> wrote:
>>> Wie kann ich einen String, der in einer Variable steht (und zur Zeit
>>> gemischte Gross- und Kleinschreibung hat) auf Grossbuchstaben umwandeln?
>>
>>echo $var | tr '[a-z]' '[A-Z]'
>
> Uuh, das hat mich schon gebissen. Was fuer das a-z bzw. A-Z expandiert
> wird, haengt davon ab, wie das locale gesetzt ist. Ein typisches
> deutsches LC_COLLATE erzeugt recht wundersame Resultate. Also entweder
> (a) ganz ausschreiben: abcdefghijklmnopqrstuvwxyz, oder
Nein. '[a-z]' entspricht '[abcdefghijklmnopqrstuvwxyz]'. Es hindert dich
selbstverständlich niemand daran, explizit '[abcdefghijklmnopqrstuvwxyz]'
zu verwenden, genauso wie dich niemand daran hindert, den Hosenknopf mit
ner Kneifzange zuzumachen ;-)
> (b) character classes verwenden: '[:lower:]', oder
Sauberer, denn eine korrekt eingestellte Locale muss man annehmen dürfen.
Wenn nicht, ist der Fehler dort zu suchen. Warum würdest du denn
'[:lower:]' verwenden, aber '[abcdefghijklmnopqrstuvwxyz]' statt '[a-z]'?
Leuchtet mir nicht ein. '[:lower:]' ist doch abhängig von der Locale,
'[a-z]' dagegen nicht.
Gruß,
Gunnar Ritter
> '[:lower:]' ist doch abhängig von der Locale, '[a-z]' dagegen nicht.
Falsch und in tr(XCU), SUSv2 oder den Solaris-Manuals nachzulesen.
»a-z« bezieht sich auf die collation order, die in LC_COLLATE=C mit
ASCII übereinstimmt. Allerdings funktioniert das eigentlich nirgendwo
hunderprozentig, wie es sollte; die collation order der Locale de_DE
auf Solaris 8 ist offenbar total broken, wie man mit grep überprüfen
kann:
$ echo ö | LC_CTYPE=de_DE LC_COLLATE=de_DE /usr/xpg4/bin/grep '[a-z]'
$
Führt man dasselbe mit der entsprechenden UTF-8-Locale und zugehörigen
Daten aus, klappt es, wie es sollte:
$ echo ö |
LC_CTYPE=de_DE.UTF-8 LC_COLLATE=de_DE.UTF-8 /usr/xpg4/bin/grep '[a-z]'
ö
$
aber mit tr gibt es trotzdem nur Müll:
$ echo ö | LC_CTYPE=de_DE.UTF-8 LC_COLLATE=de_DE.UTF-8 \
/usr/xpg4/bin/tr -s a-z A-Z
ø
$
Es ist ja m.W. auch nicht gesagt, daß wenigstens die Anzahl der Elemente
zwischen a-z und A-Z in einer gegebenen collation order übereinstimmt.
Fazit: Man setze LC_COLLATE auf C und schreibe Umlaute aus, wenn einem
die umstandsunabhängige Lauffähigkeit der Software wichtig ist. Wenn man
auf [:lower:], [:upper:] ausweicht, hat das immerhin den Vorteil, daß
das von der offenbar weniger problematischen LC_CTYPE-Locale abhängt.
Grüße,
Gunnar
Helmut Schellong
>
> Heiner Marxen <hei...@DrB.Insel.DE> wrote:
>
> >>echo $var | tr '[a-z]' '[A-Z]'
> >
> > Uuh, das hat mich schon gebissen. Was fuer das a-z bzw. A-Z expandiert
> > wird, haengt davon ab, wie das locale gesetzt ist. Ein typisches
> > deutsches LC_COLLATE erzeugt recht wundersame Resultate. Also entweder
> > (a) ganz ausschreiben: abcdefghijklmnopqrstuvwxyz, oder
>
> Nein. '[a-z]' entspricht '[abcdefghijklmnopqrstuvwxyz]'. Es hindert dich
> selbstverständlich niemand daran, explizit '[abcdefghijklmnopqrstuvwxyz]'
> zu verwenden, genauso wie dich niemand daran hindert, den Hosenknopf mit
> ner Kneifzange zuzumachen ;-)
>
> > (b) character classes verwenden: '[:lower:]', oder
>
> Sauberer, denn eine korrekt eingestellte Locale muss man annehmen dürfen.
> Wenn nicht, ist der Fehler dort zu suchen. Warum würdest du denn
> '[:lower:]' verwenden, aber '[abcdefghijklmnopqrstuvwxyz]' statt '[a-z]'?
> Leuchtet mir nicht ein. '[:lower:]' ist doch abhängig von der Locale,
> '[a-z]' dagegen nicht.
Es wird der Zahlenwert verwendet, der hinter 'a' bzw. 'z' steckt.
Bei ASCII funktioniert [a-z] immer.
Auch '[a-z]äöü' '[A-Z]ÄÖÜ' funktioniert immer, solange man die
Umlaute optisch korrekt sieht und die Daten diesem Zeichensatz
entsprechen.
Bei EBCDIC ist das Alphabet je zweimal durch undefinierte
Bereiche zerrissen, aber sonst ist alles wie bei ASCII,
sodaß keine Probleme zu erwarten sind, solange diese
undefinierten Werte nicht vorkommen.
--
Mit freundlichen Grüßen
Helmut Schellong po...@schellong.de po...@schellong.com
http://www.schellong.de http://www.schellong.com
http://home.t-online.de/home/schellong sche...@t-online.de
Gunnar Ritter
> '[:lower:]' ist doch abhängig von der Locale, '[a-z]' dagegen nicht.
Falsch und in tr(XCU), SUSv2 oder den Solaris-Manuals nachzulesen.
»a-z« bezieht sich auf die collation order, die in LC_COLLATE=C mit
ASCII übereinstimmt. Allerdings funktioniert das eigentlich nirgendwo
hunderprozentig, wie es sollte; die collation order der Locale de_DE
auf Solaris 8 ist offenbar total broken, wie man mit grep überprüfen
kann:
$ echo ö | LC_CTYPE=de_DE LC_COLLATE=de_DE /usr/xpg4/bin/grep '[a-z]'
$
Führt man dasselbe mit der entsprechenden UTF-8-Locale und zugehörigen
Daten aus, klappt es, wie es sollte:
$ echo ö |
LC_CTYPE=de_DE.UTF-8 LC_COLLATE=de_DE.UTF-8 /usr/xpg4/bin/grep '[a-z]'
ö
$
aber mit tr gibt es trotzdem nur Müll:
$ echo ö |
LC_CTYPE=de_DE.UTF-8 LC_COLLATE=de_DE.UTF-8 /usr/xpg4/bin/tr a-z A-Z
ø
$
Vergleiche Singlebyte-Locales:
$ echo a | LC_COLLATE=C /usr/xpg4/bin/tr a-z A-Z
A
$ echo a | LC_COLLATE=de_DE /usr/xpg4/bin/tr a-z A-Z
Z
Juergen Salk
> Nein. '[a-z]' entspricht '[abcdefghijklmnopqrstuvwxyz]'.
Vorsicht. Ich habe mal auf einer SuSE 6.3 (IIRC) folgendes
Spielchen gemacht:
| juergen@anna:~/scratch > touch a b c A B C
| juergen@anna:~/scratch > ls -a
| . .. A B C a b c
| juergen@anna:~/scratch > echo $LC_COLLATE
| POSIX
| juergen@anna:~/scratch > ls [a-z]
| a b c
| juergen@anna:~/scratch > ls [A-Z]
| A B C
| juergen@anna:~/scratch > ls [[:lower:]]
| a b c
| juergen@anna:~/scratch > ls [[:upper:]]
| A B C
|
| juergen@anna:~/scratch > export LC_COLLATE=de_DE
| juergen@anna:~/scratch > echo $LC_COLLATE
| de_DE
| juergen@anna:~/scratch > ls [a-z]
| A B C a b c
| juergen@anna:~/scratch > ls [A-Z]
| A B C b c
| juergen@anna:~/scratch > ls [[:lower:]]
| a b c
| juergen@anna:~/scratch > ls [[:upper:]]
| A B C
Locales können teuflisch sein.
Beste Grüsse - Jürgen
--
Einstein also said: "God does not gamble." thereby denying the -o)
existence of true stochastic processes. So, he clearly did not know /\\
everything, but does that make him stupid? (P.-H. van der Giessen) _\_v
Olaf Dietrich
>
> Fazit: Man setze LC_COLLATE auf C und schreibe Umlaute aus, wenn einem
> die umstandsunabhängige Lauffähigkeit der Software wichtig ist.
Anzumerken bleibt, daß keine tr(1)-Lösung deutschen Text
mit ß richtig umsetzt, da dieses zu SS werden müßte.
Olaf
jsaul
> jsaul <ne...@jsaul.de> wrote:
>
>> Nein. '[a-z]' entspricht '[abcdefghijklmnopqrstuvwxyz]'.
>
> Vorsicht. Ich habe mal auf einer SuSE 6.3 (IIRC) folgendes
> Spielchen gemacht:
> [...]
> Locales können teuflisch sein.
Ja, deine Beispiele haben mich überzeugt. Sorry Heiner Marxen. Die
Kneifzange geht heute an mich ;-)
Nicht mal bei [a-z] etc. kann man also davon ausgehen (wie ich
irrtümlicherweise), dass diese so, wie man es erwarten würde,
"nebeneinander" liegen.
Auch wenn ich deine Beispiele nicht anzweifle, konnte ich sie hier (SuSE
7.2) nicht reproduzieren:
$ touch a b c A B C
$ export LC_COLLATE=de_DE
$ echo $LC_COLLATE
de_DE
$ ls [a-z]
a b c
$ ls [A-Z]
A B C
Aber es ist gut zu wissen, dass man sich /nicht/ darauf verlassen darf.
Helmut Schellong
Ich hatte seit 1989 meine eigene Locale konstruiert,
(univ_int.pc8: /usr/lib/lang/univ/int/pc8/*)
mit den kleinen Compilern chrtbl,timtbl,coltbl,...
Von daher weiß ich, daß Locales durchaus Fehler enthalten können,
sogar Fehler in eben diesen kleinen table-Compilern, die ja bei der
Installation von Skripten benutzt werden.
Z.B. sort: zabcdefgh...y
U.a. deshalb hatte ich mir eine eigene Locale gemacht.
Zweitens muß man die Programme unterscheiden, die [a-z]
verwenden. Es ist möglich, daß je nach Programmaufgabe
und internem Lösungskonzept, Unterschiede (bei fehlerhafter Locale)
auftreten.
Was J.Salk zeigte, ist für mich ein Locale-Fehler.
Denn bei ASCII sind die Zeichen 0(32)..127 bei jeder Locale gleich.
Martin Hermanowski
> jsaul <ne...@jsaul.de> wrote:
>
>> Nein. '[a-z]' entspricht '[abcdefghijklmnopqrstuvwxyz]'.
>
> Vorsicht. Ich habe mal auf einer SuSE 6.3 (IIRC) folgendes
> Spielchen gemacht:
>
> | juergen@anna:~/scratch > export LC_COLLATE=de_DE
> | juergen@anna:~/scratch > echo $LC_COLLATE
> | de_DE
> | juergen@anna:~/scratch > ls [a-z]
> | A B C a b c
> | juergen@anna:~/scratch > ls [A-Z]
> | A B C b c
> | juergen@anna:~/scratch > ls [[:lower:]]
> | a b c
> | juergen@anna:~/scratch > ls [[:upper:]]
> | A B C
Soeben mit SuSE 6.4 verifiziert:
,--
| martin@mail:~/t > touch a b c A B C
| martin@mail:~/t > ls -a
| . .. A B C a b c
| martin@mail:~/t > echo $LC_COLLATE
| POSIX
| martin@mail:~/t > ls [a-z]
| a b c
| martin@mail:~/t > ls [A-Z]
| A B C
| martin@mail:~/t > ls [[:lower:]]
| a b c
| martin@mail:~/t > ls [[:upper:]]
| A B C
| martin@mail:~/t > export LC_COLLATE=de_DE
| martin@mail:~/t > echo $LC_COLLATE
| de_DE
| martin@mail:~/t > ls [a-z]
| A B C a b c
| martin@mail:~/t > ls [A-Z]
| A B C b c
| martin@mail:~/t > ls [[:lower:]]
| a b c
| martin@mail:~/t > ls [[:upper:]]
| A B C
`--
MfG
Martin
--
PGP/GPG encrypted mail preferred, see header
,--
| Nur tote Fische schwimmen mit dem Strom
`--
jsaul
> Juergen Salk in de.comp.os.unix.shell wrote:
>> jsaul <ne...@jsaul.de> wrote:
>>
>>> Nein. '[a-z]' entspricht '[abcdefghijklmnopqrstuvwxyz]'.
>>
>> Vorsicht. Ich habe mal auf einer SuSE 6.3 (IIRC) folgendes
>> Spielchen gemacht:
>>
> [...]
>> | juergen@anna:~/scratch > export LC_COLLATE=de_DE
>> | juergen@anna:~/scratch > echo $LC_COLLATE
>> | de_DE
>> | juergen@anna:~/scratch > ls [a-z]
>> | A B C a b c
>> | juergen@anna:~/scratch > ls [A-Z]
>> | A B C b c
>> | juergen@anna:~/scratch > ls [[:lower:]]
>> | a b c
>> | juergen@anna:~/scratch > ls [[:upper:]]
>> | A B C
> [...]
>
> Soeben mit SuSE 6.4 verifiziert:
[das gleiche Ergebnis wie bei Jürgen Salk]
Gut, dass ich auf meinem Notebook noch SuSE 6.4 laufen habe. Und kann dort
obiges Verhalten prompt wieder nicht reproduzieren. Dann gleicher Versuch
mit bash (statt zsh) und siehe da,
$ ls [A-Z]
A B C b c
etc. Dann noch schnell mal unter 7.2 mit der bash, genau das gleiche. Aber:
Zumindest hier /nur/ bei der bash, dagegen /nicht/ bei zsh, pdksh, ksh93,
tcsh.
jsaul
> | juergen@anna:~/scratch > export LC_COLLATE=de_DE
> | juergen@anna:~/scratch > echo $LC_COLLATE
> | de_DE
> | juergen@anna:~/scratch > ls [a-z]
> | A B C a b c
> | juergen@anna:~/scratch > ls [A-Z]
> | A B C b c
> | juergen@anna:~/scratch > ls [[:lower:]]
> | a b c
> | juergen@anna:~/scratch > ls [[:upper:]]
> | A B C
>
> Locales können teuflisch sein.
Und /richtig/ gemein wird es dann bei
rm [a-z]*
Ein interessantes Posting in dem Zusammenhang ist
<handler.95285.D95285....@bugs.debian.org>
Anscheinend ist das Bash-Verhalten völlig korrekt, und entspricht dem, was
in den Locales festgelegt ist. Dann sind es also die /anderen/ Shells
(ksh93, pdksh, zsh, tcsh), die sich über die Locales hinwegsetzen?
Gunnar Ritter
> Was J.Salk zeigte, ist für mich ein Locale-Fehler.
> Denn bei ASCII sind die Zeichen 0(32)..127 bei jeder Locale gleich.
Quatsch. Beschäftige Dich einmal ernsthaft mit dem Thema, z.B. indem
Du einen Blick in /usr/share/i18n/locales/iso14651_t1 der aktuellen
GNU libc wirfst und die zugehörigen Standards liest, und Du wirst
sehen, daß Du auch hier mal wieder nichts als gequirlte Scheiße von
Dir gibst. Daß Großbuchstaben zwischen [a-z] in der collation order
stehen, ist zwar fragwürdig, aber mit ASCII hat das ganze außer bei
LC_COLLATE=C bzw. LC_COLLATE=POSIX rein gar nichts mehr zu tun.
Grüße,
Gunnar
Gunnar Ritter
> Anscheinend ist das Bash-Verhalten völlig korrekt, und entspricht dem, was
> in den Locales festgelegt ist.
Das hängt offensichtlich davon ab, *was* nun in der entsprechenden
Locale festgelegt ist. Ferner ist das ganze etwas komplizierter,
man werfe hierzu einen Blick in die Base Definitions der SUSv2,
»Locale«, »LC_COLLATE«:
# Each collating element is assigned a collation value defining its order
# in the character (or basic) collation sequence. This ordering is used
# by regular expressions and pattern matching and, unless collation
# weights are explicitly specified, also as the collation weight to be
# used in sorting.
und lese einfach weiter, bis man die Sache mit den »weights« verstanden
hat.
Nun macht die de_DE-Locale der glibc aber ausgiebig Gebrauch von weights,
und damit gibt es einen Unterschied zwischen den Ordnungen innerhalb von
range expressions und beim Sortieren von Strings. Die basic collation
sequence ist hier case sensitive, das ordering by weights nicht.
> Dann sind es also die /anderen/ Shells (ksh93, pdksh, zsh, tcsh),
> die sich über die Locales hinwegsetzen?
Die ksh93 verhält sich bei LC_COLLATE=de_DE unter glibc 2.2.4 völlig
korrekt:
$ touch a Ä b A Ä B
$ echo [a-z]
a ä b
$ echo [A-Z]
A Ä B
$ echo [a-zA-Z]
a A ä Ä b B
$
Man kann schön erkennen, daß die Auswahl der Dateinamen mittels range
expressions case sensitive ist und daß die Sortierung der ermittelten
Dateinamen schließlich unabhängig davon erfolgt.
Grüße,
Gunnar
Felix von Leitner
> Anscheinend ist das Bash-Verhalten völlig korrekt, und entspricht dem, was
> in den Locales festgelegt ist. Dann sind es also die /anderen/ Shells
> (ksh93, pdksh, zsh, tcsh), die sich über die Locales hinwegsetzen?
Niemand zwingt dich, die collate-Regeln zu setzen.
Ich habe im Zusammenhang noch nie etwas anderes als LC_CTYPE benötigt
oder gesetzt. Eindeutschungen finde ich zum Kotzen und obige
Undeterminismen muß ich nicht haben.
Felix
Gunnar Ritter
> Anscheinend ist das Bash-Verhalten völlig korrekt, und entspricht dem, was
> in den Locales festgelegt ist.
Das hängt offensichtlich davon ab, *was* nun in der entsprechenden
Locale festgelegt ist. Ferner ist das ganze etwas komplizierter,
man werfe hierzu einen Blick in die Base Definitions der SUSv2,
»Locale«, »LC_COLLATE«:
# Each collating element is assigned a collation value defining its order
# in the character (or basic) collation sequence. This ordering is used
# by regular expressions and pattern matching and, unless collation
# weights are explicitly specified, also as the collation weight to be
# used in sorting.
und lese einfach weiter, bis man die Sache mit den »weights« verstanden
hat.
Nun macht die de_DE-Locale der glibc aber ausgiebig Gebrauch von weights,
und damit gibt es einen Unterschied zwischen den Ordnungen innerhalb von
range expressions und beim Sortieren von Strings. Die basic collation
sequence ist hier case sensitive, das ordering by weights nicht.
> Dann sind es also die /anderen/ Shells (ksh93, pdksh, zsh, tcsh),
> die sich über die Locales hinwegsetzen?
Die ksh93 verhält sich bei LC_COLLATE=de_DE unter glibc 2.2.4 völlig
korrekt:
$ touch a Ä b A Ä B
$ echo [a-z]
a ä b
$ echo [A-Z]
A Ä B
$ echo [a-zA-Z]
a A ä Ä b B
$
Man kann schön erkennen, daß die Auswahl der Dateinamen mittels range
expressions case sensitive ist und daß der Sortierung der ermittelten
Dateinamen schließlich eine andere Anordnung zugrundeliegt, die einen
Großbuchstaben direkt nach dem entsprechenden Kleinbuchstaben einfügt.
In anderen Locales mag das anders sein, siehe etwa das fragmentarische
Beispiel am Ende des genannten SUSv2-Abschnittes.
Grüße,
Gunnar
Helmut Schellong
> $ echo [A-Z]
> A Ä B
> $ echo [a-zA-Z]
> a A ä Ä b B
> $
--
Gunnar Ritter
> jsaul <ne...@jsaul.de> wrote:
>> Dann sind es also die /anderen/ Shells (ksh93, pdksh, zsh, tcsh),
>> die sich über die Locales hinwegsetzen?
>
> Die ksh93 verhält sich bei LC_COLLATE=de_DE unter glibc 2.2.4 völlig
> korrekt: [...]
Bzw. die bash macht den Fehler, strcoll() zur Evaluation von range
expressions einzusetzen. Dafür ist es aber nicht gedacht, da dieser
Funktion wie erläutert die Sortierreihenfolge und nicht die basic
collation sequence zugrunde liegt.
Grüße,
Gunnar
Gunnar Ritter
> Gunnar Ritter wrote:
>> $ touch a Ä b A Ä B
>> $ echo [a-z]
>> a ä b # na, auch zerstreut? ä?!
Lies die Standards. Ich habe das jetzt länglich und mit einigen
Quellenangaben zur weiteren Lektüre erläutert; wenn Du unfähig
bist, dem zu folgen, schäm Dich in irgendeiner dunklen Ecke,
anstatt hier öffentlich herumzukaspern.
Grüße,
Gunnar
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> wrote:
>
> > Was J.Salk zeigte, ist für mich ein Locale-Fehler.
> > Denn bei ASCII sind die Zeichen 0(32)..127 bei jeder Locale gleich.
>
> Quatsch. Beschäftige Dich einmal ernsthaft mit dem Thema, z.B. indem
> Du einen Blick in /usr/share/i18n/locales/iso14651_t1 der aktuellen
> GNU libc wirfst und die zugehörigen Standards liest, und Du wirst
> sehen, daß Du auch hier mal wieder nichts als gequirlte Scheiße von
Hast Du real schon mal Scheiße gequirlt?
Man nehme einen Eimer ... ich kann Dir sagen, das kann sogar
richtig Spaß machen und bei allen Anwesenden für großes
Vergnügen sorgen.
> Dir gibst. Daß Großbuchstaben zwischen [a-z] in der collation order
> stehen, ist zwar fragwürdig, aber mit ASCII hat das ganze außer bei
> LC_COLLATE=C bzw. LC_COLLATE=POSIX rein gar nichts mehr zu tun.
In den Quelltexten, die die Basis sind, spielt ASCII allerdings
doch eine Hauptrolle. Dort werden Bereiche a-b,c-d,e-f,...
angegeben, wo ich schon fehlerhafte Umsetzungen entdeckte.
Nach Änderung in Einzelangaben war's dann plötzlich in Ordnung.
Unter UnixWare habe ich zwar bisher keine eigene Locale kreiert,
aber nach einigen Diskussionen mit mir auf die Schnelle
folgendes eingestellt:
LANG=en_US
LC_ALL=
LC_COLLATE=C
LC_CTYPE=en_US
LC_MESSAGES=de_DE
LC_MONETARY=en_US
LC_NUMERIC=en_US
LC_TIME=de_DE
Und zwar, weil ich die 'normale' COLLATE mit a A ... absolut
beschissen finde und weil ich bei de_DE massive Fehler
entdeckte, wie z.B. daß man unter X kein Fenster mehr
schließen konnte mit Maus oder Alt+F4 - war ausgegraut.
Im Zusammenhang mit Locale sind mir bisher soviel Fehler über
den Weg gelaufen, daß ich gar keine Lust mehr habe, damit
detailliert umzugehen, sondern eher zu schnellen Pauschallösungen
oder Deaktivierung neige.
Helmut Schellong
Gucke mal oben touch ... genau an.
Gunnar Ritter
> Im Zusammenhang mit Locale sind mir bisher soviel Fehler über
> den Weg gelaufen, daß ich gar keine Lust mehr habe, damit
> detailliert umzugehen, sondern eher zu schnellen Pauschallösungen
> oder Deaktivierung neige.
Schön für Dich. Dann halte Dich aber gefälligst heraus, wenn sich
andere ernsthaft mit diesem Thema auseinandersetzen.
Grüße,
Gunnar
Gunnar Ritter
> Gunnar Ritter wrote:
>> Helmut Schellong <sche...@t-online.de> wrote:
>> > Gunnar Ritter wrote:
>> >> $ touch a Ä b A Ä B
>> >> $ echo [a-z]
>> >> a ä b # na, auch zerstreut? ä?!
>>
>> Lies die Standards. [..]
> Gucke mal oben touch ... genau an.
Na, da hast Du aber wirklich einen phänomenalen Fehler entdeckt. Hast Du
eigentlich irgendetwas gehaltvolles zu dieser Diskussion beizutragen oder
willst Du nur mal wieder ein bißchen herumtrollen?
Grüße,
Gunnar
Sven Mascheck
> [...] auf die Schnelle folgendes eingestellt:
> LANG=en_US
> LC_ALL=
> LC_COLLATE=C
> LC_CTYPE=en_US
> LC_MESSAGES=de_DE
> LC_MONETARY=en_US
> LC_NUMERIC=en_US
> LC_TIME=de_DE
Zeilen 4, 6 und 7 sind Fall redundant.
Und zwar - offenbar - aus genau dem Grund, der Dir Kopfschmerzen
bereitet ohne das Du es gemerkt hast. LANG setzt implizit alle
konkreteren Kategorien. Selbst in diversen FAQs/HOWTOs liest man
oft über LANG (oder sogar LC_ALL), meist geht es tatsächlich aber
nur um LC_CTYPE. setlocale(3), environ(4/5) u.ä. sind informativer.
> Im Zusammenhang mit Locale sind mir bisher soviel Fehler über den
> Weg gelaufen, daß ich gar keine Lust mehr habe, damit detailliert
> umzugehen, sondern eher zu schnellen Pauschallösungen oder
> Deaktivierung neige.
Aha. Wer nicht will, der hat schon. Und warum sollten dann Deine
Einstellungen interessieren?
Von LC_COLLATE mal ebgesehen - was denn eigentlich für Fehler genau?
Followup-To: de.comp.os.unix.misc (ggf. passend quoten),
die Shell ist dann nur eine von vielen gleichgestellten Anwendungen.
Sven Mascheck
> [...] auf die Schnelle folgendes eingestellt:
> LANG=en_US
> LC_ALL=
> LC_COLLATE=C
> LC_CTYPE=en_US
> LC_MESSAGES=de_DE
> LC_MONETARY=en_US
> LC_NUMERIC=en_US
> LC_TIME=de_DE
Zeilen 4, 6 und 7 sind in diesem Fall redundant.
Und zwar - offenbar - aus genau dem Grund, der Dir Kopfschmerzen
bereitet ohne das Du es gemerkt hast. LANG setzt implizit alle
konkreteren Kategorien. Selbst in diversen FAQs/HOWTOs liest man
oft über LANG (oder sogar LC_ALL), meist geht es tatsächlich aber
nur um LC_CTYPE. setlocale(3), environ(4/5) u.ä. sind informativer.
> Im Zusammenhang mit Locale sind mir bisher soviel Fehler über den
> Weg gelaufen, daß ich gar keine Lust mehr habe, damit detailliert
> umzugehen, sondern eher zu schnellen Pauschallösungen oder
> Deaktivierung neige.
Aha. Wer nicht will, der hat schon. Und warum sollten dann Deine
Helmut Schellong
>
> Helmut Schellong <sche...@t-online.de> wrote:
>
> > Gunnar Ritter wrote:
> >> Helmut Schellong <sche...@t-online.de> wrote:
> >> > Gunnar Ritter wrote:
> >> >> $ touch a Ä b A Ä B
> >> >> $ echo [a-z]
> >> >> a ä b # na, auch zerstreut? ä?!
> >>
> >> Lies die Standards. [..]
> > Gucke mal oben touch ... genau an.
>
> Na, da hast Du aber wirklich einen phänomenalen Fehler entdeckt. Hast Du
> eigentlich irgendetwas gehaltvolles zu dieser Diskussion beizutragen oder
> willst Du nur mal wieder ein bißchen herumtrollen?
Im Moment - letzteres.
Florian Weimer
> Ein interessantes Posting in dem Zusammenhang ist
> <handler.95285.D95285....@bugs.debian.org>
> Anscheinend ist das Bash-Verhalten völlig korrekt, und entspricht dem, was
> in den Locales festgelegt ist.
Ja, siehe auch
<392-e6837644ca3c948e34...@cert.uni-stuttgart.de>
bzw. http://cert.uni-stuttgart.de/ticker/article.php?mid=392 .
Dort wird auch noch LC_ALL erwähnt, mit der etwas verwirrenden
Semantik.
Es ist davon auszugehen, daß sich andere Shells auch in diese Richtung
entwickeln werden, es sei den, die Vorschriften in SUSv2 werden
geändert.
Florian Weimer
> Bzw. die bash macht den Fehler, strcoll() zur Evaluation von range
> expressions einzusetzen.
Das entspricht der Spezifikation:
| A range expression represents the set of collating elements that fall
| between two elements in the current collation sequence, inclusively.
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> writes:
>> Bzw. die bash macht den Fehler, strcoll() zur Evaluation von range
>> expressions einzusetzen.
>
> Das entspricht der Spezifikation:
Nein.
> | A range expression represents the set of collating elements that fall
> | between two elements in the current collation sequence, inclusively.
Right, ich wiederhole nochmal das Zitat aus <3B8B7A55...@bigfoot.de>
(i.e. »Locale« in den Base Definitions der SUSv2):
# Each collating element is assigned a collation value defining its order
# in the character (or basic) collation sequence. This ordering is used
# by regular expressions and pattern matching and, unless collation
# weights are explicitly specified, also as the collation weight to be
# used in sorting.
Es gibt einen Unterschied zwischen der collation sequence (also einfach
der Abfolge, in der die Zeichen hinter »order_start« erscheinen) und
dem Sortiervorgang bei Zeichenketten, den strcoll(), strxfrm() usw.
vornehmen. Beispiel aus /usr/share/i18n/locales/iso14651_t1, der Quelle
der GNU libc für die de_DE-Locale:
order_start <LATIN>;forward;backward;forward;forward,position
[...]
<U0061> <a>;<BAS>;<MIN>;IGNORE # 198 a
<U00AA> <a>;<PCL>;<EMI>;IGNORE # 199 ª
<U00E1> <a>;<ACA>;<MIN>;IGNORE # 200 á
<U00E0> <a>;<GRA>;<MIN>;IGNORE # 201 à
<U00E2> <a>;<CIR>;<MIN>;IGNORE # 202 â
<U00E3> <a>;<TIL>;<MIN>;IGNORE # 203 ã
<U00E4> <a>;<REU>;<MIN>;IGNORE # 204 ä
<U00E5> <a>;<RNE>;<MIN>;IGNORE # 205 å
<U0103> <a>;<BRE>;<MIN>;IGNORE # 206 <a(>
<U0105> <a>;<OGO>;<MIN>;IGNORE # 207 <a;>
<U0101> <a>;<MAC>;<MIN>;IGNORE # 208 <a->
<U00E6> "<a><e>";"<LIG><LIG>";"<MIN><MIN>";IGNORE # 209 æ
<U0062> <b>;<BAS>;<MIN>;IGNORE # 210 b
<U0063> <c>;<BAS>;<MIN>;IGNORE # 211 c
<U00E7> <c>;<CDI>;<MIN>;IGNORE # 212 ç
[...]
<U007A> <z>;<BAS>;<MIN>;IGNORE # 315 z
<U017A> <z>;<ACA>;<MIN>;IGNORE # 316 <z'>
<U017E> <z>;<CAR>;<MIN>;IGNORE # 317 <z<>
<U017C> <z>;<PCT>;<MIN>;IGNORE # 318 <z.>
<U00FE> <th>;<BAS>;<MIN>;IGNORE # 318b Þ #
<U0041> <a>;<BAS>;<CAP>;IGNORE # 319 A
<U00C1> <a>;<ACA>;<CAP>;IGNORE # 320 Á
<U00C0> <a>;<GRA>;<CAP>;IGNORE # 321 À
<U00C2> <a>;<CIR>;<CAP>;IGNORE # 322 Â
<U00C3> <a>;<TIL>;<CAP>;IGNORE # 323 Ã
<U00C4> <a>;<REU>;<CAP>;IGNORE # 324 Ä
In der ersten Spalte vor dem Leerzeichen steht der Unicode-Wert des
entsprechenden Zeichens. Die Anordnung in dieser Spalte ist für range
expressions relevant. Beim Vergleichen von Strings hingegen werden die
weights in den folgenden Spalten benutzt. Zunächst wird der String von
vorne nach hinten (»forward«) nach dem Wert in der zweiten Spalte (vor
dem ersten Semikolon) verglichen. Dieser ist nicht case-sensitive. In
einem zweiten Schritt wird der String von hinten nach vorne unter
Berücksichtigung diakritischer Zeichen ausgewertet, und in einem
dritten wird von vorne nach hinten Groß- und Kleinschreibung (MIN/CAP)
getrennt. Der vierte Schritt ist für unsere Betrachtung nicht relevant.
Daraus ergibt sich, daß es im konkreten Fall (LC_COLLATE=de_DE in der
aktuellen glibc) einen deutlichen Unterschied zwischen der Anordnung bei
range expressions und beim Sortieren gibt. Das Verhalten der bash ist
falsch (das der ksh93 im Detail ebenfalls, es kam hier nur zufällig
hin). Korrekt verhält sich z.B. die ksh aus SunOS 5.8, die fnmatch()
zur Auswertung von range expressions verwendet. fnmatch() und regexec()
der glibc stützen meine Darstellung, indem auch sie die basic collation
sequence und nicht die Reihenfolge für Sortierfunktionen verwenden.
Flup2 dcoum.
Grüße,
Gunnar