[linux-l] case-less bash

[Jan-Benedict Glaw]

On Thu, 2007-11-22 00:18:06 +0100, Steffen Dettmer <steffen at dett.de> wrote:
> * 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?

Zumindest Dateisystem-Objekte sollten einer "sinnvollen" (to be
defined) Sortierung unterworfen sein...

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

Diesen Scheiß hatten wir doch unter Win95 oder so?  Zu den Zeiten ist
mir glaube ich jedes Mal schlecht geworden, wenn ich sowas gesehen
hab'...

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

Wo ist da jetzt genau das Problem? Die Wörter mit gleichem Stamm, aber
unterschiedlicher Endung, würden alphabetisch sortiert werden, aber
vielleicht nicht nach der Anzahl, die damit ausgedrückt wird.

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

Hängt von der Mehrheit ab, die man befriedigen will. Ich für meinen
Teil finds jedenfalls toll, wenn man sich seine Dateien "sinnvoll"
gemäß Duden (und nicht gemäß ASCII oder Unicode-Codepoint) sortieren
/lassen/ kann. Aber man kanns halt auch ausschalten.

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

Du wirfst Namensräume durcheinander. Eine C-Variable muß immer (mit
der Ausnahme implementationsdefinierter erweiterungen) in ihrer exakt
passenden Groß-/Kleinschreibung genutzt werden. Es sind symbolische
Bezeichner eines Sprache, die auch sonst festen syntaktischen Regeln
gehorcht.

Aber (allem voran) Dateinamen enthalten typischerweise nicht soetwas,
sondern sprechende Namen, die einer gesprochenen Sprache entstammen.
Da machts dann schon Sinn, sie im Kontext der Sprache zu sortieren,
ebenso, wie Variablen-Namen im Kontext ihrer Sprache sortiert werden
sollten.

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

...zum Glück bist Du kein Chinese. Und warst auch nie in Frankreich
zum Urlaub in einem Dorf, das französische Umlaute im Namen hatte...
Ich würd' für die Photos ja schon gerne einen Verzeichnisnamen haben,
der der Original-Schreibweise entspricht.

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

Ja, das ist wirklich gerade in der Diskussion. Und da IIRC Ende der
50er Jahre die Umschreibung "SZ" für Groß-Eszett abgeschafft worden
ist ("sz" in Kleinbuchstaben hat es im Druck übrigens nie so gegeben),
fällt das mehr und mehr als Problem auf.

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

Da auch :->

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

Eigentlich muß man nur zwischen zwei Fällen unterscheiden: Will ich
eine Sortierung gemäß der Muttersprache, oder gemäß Zahlenwert der
ASCII-/Unicode-Nummern.  Der Fall, daß Werte gemäß einer spezifischen
locale sortiert werden sollen, hat man wohl eher selten. (Und dann
sollte man die sowieso setzen.)

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

Ja, in der Tat.  In einem ansonsten alten System sollte man keine
neuen Libs und Tools installieren.

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

Nicht nur über Shell-Scripte, sondern auch über sauberes Arbeiten.
Buchstaben-Klassen bei grep und sed gibts doch schon ewig und drei
Tage. Aber warum wird immernoch so gerne [a-z] für Kleinbuchstaben
benutzt?

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

Weil Dateinamen keiner strengen Syntax gehorchen und einem ganz
anderen namespace angehören.

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

#define Argv argv

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

C99 (und auch die Anfänge von C0x) werden nicht so schnell damit
brechen.

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

Natürlich nicht. Aber man sollte wissen, was man will.

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

Klar. Mach' halt 'nen bug auf. (Wenn Deine locale denn auch generiert
war:->)

> Wäre viel zu kompliziert für'n kleines Shellscriptchen. Da definiert man sich
> UTC und gut ist.

...oder man berücksichtigt die Zeitzonen. Und bedenkt auch, daß es
Halb- und Viertelstunden-Sprünge geben kann.

> 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

Stell' Dir vor, ein Ausländer will was in einem deutschen Telephonbuch
finden. Der wird sich /freuen/, wenn das nach seinen Wünschen sortiert
ist. Genauso, wie Du Dir wünscht, daß es nach Deinen Vorstellungen
gelistet ist.

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

Nach dem Umzug, ja, aber Deine Sprache ist ja /auch/ mit Dir
umgezogen! Hättest Du Dich schon an den neuen Ort, die neue Sprache,
adaptiert, würdest Du Dir ggf. eine andere Sortierung erhoffen.

:->

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
Signature of:            http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
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/20071122/cd4b51e2/attachment.sig>