[linux-l] case-less bash

[Steffen Dettmer]

Hi,

erstmal vielen Dank für Deine schnelle, detailierte Antwort.

* Jan-Benedict Glaw wrote on Wed, Nov 21, 2007 at 22:36 +0100:
> Wer regular expressions und Sortierungen durch die shell benutzt,
> sollte heutzutage wissen, daß all das locale-abhängig ist.

Ja, aber warum? Ich kann eh nicht über eine natürliche Sprache mit der
Shell reden ("hey, kopier mir mal die Datei von vorhin" funktioniert
nicht). Warum muss die künstliche formale Sprache /einige/ Komische
Regeln (TM) von einer natürliche Sprache annehmen, die dann auch noch
pro User und Wetter eine andere sein kann?

Das macht die Mathematik ja auch nicht.


   (Den Rest der Mail bitte nicht zu ernst nehmen. Ist grösstenteils
    sarkastisch gemeint)

> > 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.)  

Ja, ich beneide keinen, der das machen muss, wirklich ein kompliziertes
Thema. Merkt man auch daran, wie langsam dann alles wird. Früher konnte
man mit "ue" usw prima leben, heute ist man durch ü's und so verwöhnt
(geht mir ja auch nicht anders). Aber das nun in den Shellprogrammierung
zu berücksichtigen, geht ein bisschen weit, oder? Erwartet man denn,
dass ein "ls" nach locale sortiert ist? Also a und A wie im Duden,
obwohl A und a doch wieder verschieden sind? WENN schon, dann bitte auch
ein nicht-case-sensitives Filesystem. Und auch nicht case-preserving
sondern case-corrective. Anfangsbuchstaben gross, Rest klein oder so.
Da würde ich einen Sinn erkennen (nämlich: wie man es als Mensch in
einer natürlichen Sprache gewohnt ist) - aber dagegen sein :)

> 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.

Na ja, so einfach ist das auch nicht. Im deutschen und englischen gibt
es Einzahl und Mehrzahl - aber z.B. im polnischen muss man für 2,3,4
eine andere Endung verwenden usw.

> > 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.

Versteh ich nicht. Wenn ich selbst keine Shellscripte programmiere,
wieso erwarte ich, dass sie sich dann anders verhalten, je nach dem, wer
sie ausführt?

Gut, ich gebe zu, ich gehe davon aus, dass "vor dem Computer alle gleich
sind". Du sagst, nein, je nach dem, welche Sprache man benutzt, ist es
anders. Aber wer hat (logisch gesehen) Recht? Nur weil irgendwelche
Leute in irgeneinem explorer.exe eine bestimmte Sortierung erwarten?

Früher hat man gelernt, dass a nicht A ist, wie auch in der Mathematik.
Nun ist a vielleicht doch A, nämlich z.B. in de_DE (ausser in der
Mathematik). Ist das logisch? Ein Mathematiker sagt doch auch nicht,
dass die Formel (ohne selbst eine Formel umzuformen) sich an die lokale
Gesetzgebung halten muss?

> 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?

Ergo nimmt man kein "ä" in Dateinamen :-) Ganz einfach :-)

Ist immer noch sprechender als Nummern. Die sind ja sonst total in.
Müssten doch mit Namen alle glücklich sein :) hehe

> (Das ändert sich übrigens gerade, da daran gearbeitet wird, ein
> Groß-Eszett einzuführen.))

echt? na geil. Hoffentlich kommen mit der Vereinfachung genug neue
unlogische Ausnahmen hinzu lol Und natürlich muss man sofort alle
Telefonbücher umdrucken. Alte verbieten und verbrennen?

> 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...

Als /Shell/Programmierer ja nicht...

> > 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.

aber 1000mal testen zu müssen, weil ja einmal pro locale...

> 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.

Wo steht das? Ich hab hier z.B. eine SuSE 8.2 mit z.B. /etc/init.d
Scripten, da ist kein LANG=C oder sowas drin. Sicherlich wird C-like
erwartet, weil ja alt. Ergo ist neu nicht kompatibel, das ist ärgerlich
und gefährlich.

Wir reden doch über Shellscripte. Nicht über den deutschen Index in
einem OpenOffice-Dokument. Bei letzerem sehe ich das total ein, keine
Frage.

> > 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. 

Zitat von oben:
> Es gibt überall entsprechende Gesetze (oder "...Näheres regelt eine
> Verordnung"), an die sich Software ggf. halten muß. Und da gibts viele

Warum gilt das für bash-Programme aber nicht für C-Programme (also die
bash-Sprache aber nicht für die C-Sprache)?

> 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.)

Das sind ja die /Daten/, nicht das Programm selbst. Nee, das reicht
nicht für ein locale-konformes C. Ich muss dann natürlich auch Argv[0]
schreiben dürfen :-)

> > 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.

(ähm... sorry, das war natürlich alles sarkastisch gemeint)

> > 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.

Na ja, früher was das allgemein so. Warte mal ab, kommt alles noch :-)

> > 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.

Ja, aber nur, weil Du keine "modernen Tools" verwendest. Sonst musst Du
oben in Dein C Quelltext

#define LANG=C
#define LC_ALL=C

reinschreiben. SCNR.

  (immer noch sarkatisch gemeint :))

> >          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...

Ja gut, man kann es natürlich auch lassen. Und ein Visual Basic nehmen.
Unter Word sind ja auch die Funktionsnamen übersetzt etc.

Kann man machen. Aber ich will das nicht.

Wenn man nun einfach mal pragmatisch ein Script machen will? Wird das
programmieren jetzt verboten, wenn man eine locale-Freigabe hat? lol

Nee, mal ehrlich, was sollte man denn richtigerweise tun? Was macht man,
wenn man locale erwartet, aber das System das nicht unterstützt oder
anders? Muss man dann /bin/date prüfen, ob das grosse ß schon existierte
oder nicht?

Zeigt ein modernes /bin/cal in de_DE die gregorianische Zeitumstellung
korrekt an?

steffen at link:~/test/xx> LC_ALL=de_DE cal 9 1752
#   September 1752
So Mo Di Mi Do Fr Sa 
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Das ist falsch (1752 war z.B. in US und wohl England, viele andere Länder waren
früher). Wer Österwiehe vor Zwichau erwartet, erwartet sicherlich auch einen
"richtigen" Kalender, oder?

Ja, natürlich ist der Kalender landabhängig. Wie geht man praktisch damit um?
Man lässt sich nichts anmerken und schreibt so ziemlich überall auf der Welt
(inzwischen) das gleiche Datum. Wäre auch nervig, wenn man das umrechnen
müsste, oder? Wäre ja auch blöd, wenn man an jedes Datum das Land ranschreiben
müsste. Müsste man eigentlich, wenn man es genau machen will, und übrigens auch
den Ort und die Zeitzone, weil sich der Tag ja um eine Stunde verschieben kann,
je nach dem, ob man DST hat oder nicht.

Wäre viel zu kompliziert für'n kleines Shellscriptchen. Da definiert man sich
UTC und gut 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.

argh.... ja, grausam, was?

Stelle man sich mal vor: da nimmt man ein deutsches Telefonbuch ins
Ausland mit, öffnet es, und plötzlich ist alles ganz anders, weil man
umgezogen ist? Da stehen die Eltern dann nicht mehr drin, weil sie
unglücklicherweise einen Umlaut im Namen haben, der aber in der locale
gar kein Zeichen ist! Tja, Pech für die lieben Verwandten. Das muss
natürlich dann in die disclaimer "Diese Anwendung darf nur von
Österreichern oder nach Österreich umgezogenen benutzt werden, da nur
diese Gesetzgebung implementiert ist" (sleep heisst dann auch Schlaf
oder Schlafe, beides ist möglich, siehe Duden).

  ( :-) ) 

> 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 .)

WAS? MACH MIR KEINE ANGST!

steffen at link:~/test/xx> touch "Österwiehe" "Zwichau"
steffen at link:~/test/xx> ls | cat
Zwichau
Österwiehe

(puhh, Gott sei Dank)

steffen at link:~/test/xx> ls | cat
Oeserwiehe
Zwichau

(Fixed :))



Mal ehrlich, ein Telefonbuch ist in einer bestimmten Reihenfolge
GEDRUCKT. Egal wer es aufschlägt, es ist immer gleich. Man steht da z.B.
immer auf der gleichen Seite, egal wer es in welchem Land aufmacht. Auch
morgen und nach dem Umzug :-)

Warum korrigiert man eigentlich nicht die Telefonbücher? lol Na ja, ich
muss zugeben, inzwischen find ich Umlaute irgendwie schön. Früher, so
vor 15 Jahren, hätte ich bei einer Abstimmung für die Abschaffung aller
Umlaute gestimmt. Heute wäre ich dagegen.

Nee, das mit der natürlichen Sprache mag für Textverarbeitungen und
Satzsysteme gelten, aber für ausgewählte Programmiersprachen ist es
komisch.

Vielen lieben Dank für Deine Erklärungen. Die waren sehr hilfreich und
aufschlussreich. Interessant, dass Leute erwarten, dass sich Scripte je
nach Nationalität des Nutzers anders verhalten etc und dass man
erwartet, dass eine Shell gesetzeskonform ist, C aber (noch) nicht. Ich
sehe die Gründe (auch wenn ich persönlich ganz anderer Meinung bin).
Vielleicht seh ich das in 15 Jahren (oder morgen) ja auch anders, wie
mit den Umlauten. Obwohl man das als Deutscher nicht sagen sollte, dass
man vielleicht später gern etwas Nationalität in seinen Programmen hätte :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.