[linux-l] case-less bash

[Jan-Benedict Glaw]

On Wed, 2007-11-21 21:30:27 +0100, Steffen Dettmer <steffen at dett.de> wrote:
> erstmal Danke an alle für die vielen interessanten Erklärungen.
> 
> * Peter Ross wrote on Mon, Nov 19, 2007 at 22:30 +1100:
> > > Es hilft zwar nicht :-), aber das macht mutt beim Suchen auch (IIRC 
> > > schon immer) so. 
> > 
> > Vielleicht, weil es 'runter' auf die gleiche libc-Funktionen geht?
> > 
> > Auf FreeBSD-current ist ein Thread:
> > 
> > "Setting LANG=sv_SE.ISO_8859-1 breaks 7.0 buildworld"
> 
> Wirklich geil...
> 
> Wer kam auf die glorreiche Idee? Ich habe nie verstanden, warum die
> Macros (und VB Befehle) in einem deutschen Word anders heissen müssen,
> als in einem englischen (und warum copy&paste trotzdem manchmal ein
> bisschen funktioniert). Was haben wir über die Windows-Filesysteme
> gelacht (z.B. halt makefile und Makefile)!

Naja, genaugenommen ist diese "glorreiche Idee", die da zum
Nicht-Funktionieren des build systems führt, ein Bug darin.

Wer regular expressions und Sortierungen durch die shell benutzt,
sollte heutzutage wissen, daß all das locale-abhängig ist.

Es gibt eben einen Unterschied zwischen '[a-z]' und '[[:lower:]]', den
man verstanden haben sollte.  Wenn man Annahmen macht, die halt nicht
zutreffend sind, dann brichts ins Essen. Aber das hat jetzt niemand
anders erwartet, oder?

> Und jetzt installiert SuSE das standardmässig so? Ich mein, gut, man
> kann es wenigstens abstellen (ich stell immer Console Unicode ab und
> CTYPE auf ... erm... C? oder so? Müsste ich nachgucken lol).

Ich für meinen Teil finde Unicode (bzw. UTF-8) eine wirklich ganz
tolle Idee. Was hab' ich mir vor vielen Jahren Gedanken darum machen
müssen, wie ich die Umlaute unterschiedlicher Schriften abgebildet
bekomme. (Stichwort: Kassensysteme mit Waren aus unterschiedlichen
Ländern.)  Das ist jetzt einfach trivial; man muß sich nur *einmal*
Gedanken darüber machen, welche Zeichensatz-Kodierung man will, welche
Sortierung, welche Tausender-Striche etc. bei Zahlen und Währungen,
..., und dann hat man fertig. Das ganze gemäß der Gesetze eines
anderen Landes? Kein Problem. Eine handvoll Variablen umsetzen und das
wars.

> Gibt es einen Vorteil von diesem komischen Verhalten? Oder ist die Idee,

Ja. Damit kann man sich, ohne /selbst/ programmieren zu müssen, z.B.
an die lokale Gesetzgebung bzw. die lokalen Regulierungen halten. Es
gibt überall entsprechende Gesetze (oder "...Näheres regelt eine
Verordnung"), an die sich Software ggf. halten muß. Und da gibts viele
subtile Unterschiede, bei denen man sich totmachen würde, sollte man
das alles in die einzelnen Applikationen einprogrammieren. (Wird 'ä'
jetzt gleich noch wie 'a' beim Sortieren behandelt, oder wie 'ae',
oder kommt alles mit 'ä' hinter 'a', oder, weils ein Umlaut ist, der
in ISO-8859-1 einen viel größeren Zahlwert als 'a' hat, hinter 'z'? Wo
kommt das 'ß' hin? Und ist isupper('ß') jetzt gegeben oder doch nicht?
(Das ändert sich übrigens gerade, da daran gearbeitet wird, ein
Groß-Eszett einzuführen.))

Als Programmierer hat man stets die Wahl, ob man Funktionen benutzt,
die nach alter C-Manier funktionieren, oder solche, die die locale
berücksichtigen. Man sollte seine Wahl gut treffen...

> dass man sich jetzt auch noch eigene locale definieren soll, so
> de_STEFFENS wo dann auch in der Shell makefile und Makefile wieder was
> anderes sind?

Die Idee ist, nicht alles 1000mal implementieren zu müssen.

> > According http://sv.wikipedia.org/wiki/Svenska_alfabetet the 
> > separation of v and w has been official since 2006."
> 
> Tja, ein schönes Ende für ein Beispiel lol
> 
> Da kann man sich dann ja schon auf noch mehr kaputte Shellscripte
> freuen.

Bingo. Die Scripte sind kaputt. Nicht grep, sed oder was auch immer.
Wenn das Script erwartet, daß sich die Tools C-like verhalten, gehört
da ganz vorne ein

LANG=C
LC_ALL=C
export LANG LC_ALL

hinein. Ansonsten werden moderne Tools die locale entsprechend
berücksichtigen.

> Und der Gerechtigkeit halber muss das natürlich auch in C gehen (also
> Umlaute in Bezeichnern erlaubt etc). Prima, kann man int a deklarieren
> und A benutzen (wie im Duden, klar) und Funktionen am Satzanfang gross
> schreiben, Klasse. Dann muss man nur noch Dolmetsch-Linker erfinden,

Naja, Groß- und Kleinbuchstaben des lateinischen Alphabetes für
Variablen werden unterschieden. Aber es ist Sache der Implementierung,
ob sie darüber hinaus noch Sonderzeichen annimmt und wie deren
upper/lower case behandelt wird.

Ebenso hat man eine C99-kompatible Umgebung, wenn z.B. die übergebenen
Argumente, die hinterher in argv[] landen, /nicht/ in ihrer
ursprünglichen Groß-/Kleinschreibung im Programm ankommen. (Sie müssen
dann nach "klein" konvertiert sein.)

C ist nicht einfach.  Und locales sind es auch nicht.  Aber beides
kann's doch einfacher machen :->

> damit man eine deutsche Applikation gegen eine englische Lib linken kann
> (Java-like Laufzeit-Bremsung muss man halt hinnehmen). Und ich definiere
> meine locale/ctype so, dass Zeilenvorschübe Wortzeichen sind, damit ich
> endlich mehrzeilige Funktionsnamen verwenden kann, ohne den Präprozessor
> zu bemühen. Gut, man muss ein paar Konventionen anpassen ("Cat cat;"

Nein, das alles wird leider nicht klappen. Solange Du keine
Multibyte-Sonderzeichen benutzt (die Dein Compiler nicht akzeptieren
/muß/, aber es doch tun /darf/), bist Du da auf der sicheren Seite,
weil zumindest C99 da entsprechend enggefaßt ist.

> kann man dann in C++ ja nicht mehr machen). Überhaupt schreibt man statt
> "class Worker" dann "Klasse ArbeiterInnen". Obwohl, das "Innen" ist

Nein. C99 (und auch schon C++ als früher Ableger) schreiben fest, daß
keywords nicht lokalisierbar sind.

> eigentlich falsch. Also "Klasse Arbeiterinnen und Arbeiter" oder "Klasse
> Arbeiter und Arbeiterinnen" heisst es richtig. Beides ist natürlich
> falsch, weil es dann zwei Klassen mit gleichem Namen geben würde (der
> Name ist die deutsche Übersetung von Worker, die ja zwei Schreibweisen
> erlaubt). Ist es ein Kompilerfehler, wenn man ein Eigennamen als
> Variable klein schreibt ("int klaus" statt "int Klaus")? Bei deutsche
> locale auf jeden Fall! 

"int klaus" und "int Klaus" sind laut Standard ganz sicher zwei
unterschedliche Kläuse.

>          wahhhhhhhhh ichhh drehhhhhh duuuurchhhhhhhhh
> 
>          -- neeeeeeeeee -- ist mir alles absolut unklar

C99-Standard lesen. Und sich /dann/ wundern, wie einfach die Welt
unter Linux doch ist, wenn man zu nahezu 100%iger Wahrscheinlichkeit
nie mit den (zulässigen) Stolpersteinen in Berührung kommen wird. Und
wenn man damit durch ist, POSIX.1 oder SuSv3 lesen. Dann kommen aufmal
Welten ins Wanken und man lernt, daß '#!/bin/sh' eine ganz dämliche
Idee ist...

> Ich muss mich aber total irren, weil so bekloppt kann das ja gar nicht
> sein, hätten ja schon viele gemerkt... Was übersehe ich?

Du guckst aus einer altbackenen C-Programmierer-Sicht auf die Materie.
Du kennst ein Byte, daß 256 verschiedene Zustände annehmen kann. Aber
menschliche Sprache ist komplizierter und das moderne C runtime
environment haben sich dem angenommen.

Das "principle of least surprise" sollte Dich hoffen lassen, daß (wenn
Dein System ordentlich konfiguriert ist) ein `ls' in einem
Verzeichnis, in dem sich diverse Dateien mit Umlauten und sonstigen
Schweinereien befinden, diese in der Reihenfolge erscheinen, wie sie
im Duden, Telephonbuch oder Lexikon stehen. Und genau das ist heute
möglich.  ...und wenn Du umziehst: Variable entsprechend neusetzen und
gut.

jbglaw at bixie:~/test/xx$ LC_ALL=C LANG=C ls | cat
N
O
P
n
o
p
Ö
ö

jbglaw at bixie:~/test/xx$ LC_ALL=de_DE.UTF-8 LANG=de_DE.UTF-8 ls | cat
n
N
o
O
ö
Ö
p
P

(Niemand wird "Österwiehe" nach "Zwichau" erwarten. Niemand. Zumindest
nicht in .de .)

> Welche Aspekte gibt es, die für diese muttersprachlichen Shells ("locale
> für alle") sprechen?

Principle of least surprise.  (Depends on majorities, though.)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
  Signature of:                           Wenn ich wach bin, träume ich.
  the second  :
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20071121/72ecc9fa/attachment.sig>