[linux-l] case-less bash

Sa Nov 24 00:06:47 CET 2007

* Jan-Benedict Glaw wrote on Thu, Nov 22, 2007 at 01:33 +0100:
> 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...

Ja, das ist mein Standpunkt, *eine* Sortierung. 

Durch locale hat man *verschiedene*, damit verhalten sich Programme je
Benutzer, Nationalität und Religion (de_CATHOLIC) anders... lol 

Mensch, da würden sich aber viele aufregen :-)

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

Ja, ging mir damals auch so. Dabei war Win95 einfach nur der Zeit
vorraus und hatte als erstes System korrektes und konsequentes
locale-Handling. :-)

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

Das Problem ist, es reicht eben nicht, einfach eine handvoll
Variablen umzusetzen. Ausserdem passen Texte nicht mehr in Fenster und
so weiter.

... und wer mit einem alten xterm kommt, hat verloren. Das enttäuscht
    mich z.B. maßlos! Auf meiner Workstation läuft ein SuSE 7.0. Da
    gibts ein xterm. Das kann kein unicode und ich brauch das auch
    nicht. Wenn man zu einer normalen aktuellen Linux-Kiste ssh'd,
    funktioniert in so einem xterm ne Menge *nicht*, weil die aktuelle
    Kiste denkt, ach, xterm, klar, dass kann ja unicode.

    Da ist mir ziemlich egal, dass ich jetzt chinesische Kanji-Zeichen
    darstellen könnte, wenn ich denn welche hätte. Mein vim geht erstmal
    nicht! Und nicht nur, dass Zeichen fehlen, NEIN, es ist alles
    verschoben wegen multi-byte. Toll.

    Mit Scripten ist das doch genauso. Man ändert in Wirklichkeit
    heimlich die Sprache, das kann doch nicht richtig sein. Du schreibst:

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

    Warum muss man das Rad plötzlich neuerfinden, bloss weil jemand
    plötzlich default-Werte ändert, weil angeblich Scripte eine
    Sortierung wie im Duden brauchen? MENSCHEN brauchen das vielleicht
    so, dann muss das da konvertiert werden. Dazu kann so ein Mensch,
    der glaubt, er könne mit Computern in natürlichen Sprachen
    kommunizieren (hust hust träumt weiter) ja sein KDE5 nehmen. Na ja,
    ist übertrieben, aber weisst ja, was ich meine.

Vielleicht spart irgendeine KDE Applikation eine Zeile Code deswegen,
keine Ahnung, obwohl wohl kaum eine KDE Applikation awk verwenden wird
(sicherlich gibts ne libkawk, die ein halbes awk neuerfindet und in XML
Programmiert wird, dafür fast 5% der awk Performance erreicht). Wie auch
immer, wäre mir ja egal. Aber warum das awk indirekt dafür sorgt, dass
irgendwelche Scripte kaputtgehen?

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

Ein Traum für jeden Mathematiker und Informatiker: 

   "man kann die Ordnung halt auch ausschalten". 

Ein Durchbruch. :-)

    Na ja, bald kommt jemand und behauptet, bash-Scripte wären
    menschenlesbar und überhaupt natürliche Sprache, klar. Wie SQL. So
    unterhalten wir uns auf Arbeit ja ständig. "SELECT coffee FROM
    coffee_machine LIMIT 1" statt eines missverständlichen "Einen Kaffee aus
    der Maschine". Klar. Es gibt ja auch Leute, die XML für menschenlesbar
    halten. Aber wir haben ja Glaubens- und Bekenntnisfreiheit. SCNR.

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

Nein, beides (Variablennamen und Dateinamen) sind symbolische Namen für
Daten. Da ist kein konzeptioneller Unterschied. Es gibt Speicher (wie
z.B. Dateien), die Namen haben können. Technisch sind es Adressen oder
inodes, egal. Richtig, Namen (Bezeichner wie Variablennamen und
Dateinamen) entstammen typischerweise einer gesprochenen Sprache.

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

    Mit Frankreich hast Du vielleicht Recht, wirklich ein komisches Land,
    war bisher zum Glück nur in Paris. Aber auch in Frankreich gibt es nette
    Leute und nette Läden (gut, fällt einem als Tourist vielleicht nicht
    auf, aber gibt es).

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

    Na ja, vermutlich gibt es da viele ansonstigen überflüssige Stellen, die
    sich irgendwie begründen müssen. Und sei es mit gross-ß. Und warum da
    schon aufhören! Sicherheitshalber erstemal alle Zeichen der
    internationalen Lautschrift aufnehmen und dazu 1% der deutschen Wörter
    anders schreiben. Es hat alles einen tieferen Sinn. Beispielsweise
    Arbeitsplatzsicherung in den Druckereien (die zwar leider aus
    Kostengründen nicht in DE sind, aber egal). SCNR.

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

Nee, leider ja eben nicht...

    Gestern wieder so ein Detail. Laut meiner Installationsanleitung muss
    Support dies und jenes SQL Script ausführen, Output in File und mit
    "grep ERROR" die PostgreSQL Meldungen auslesen.  Im YaST muss bei der
    Installation als Sprache "US" gewählt werden.

    Leider gilt das nur für root, wie's aussieht, irgendwie hat der user
    postgres deutsche locale, WOHER AUCH IMMER, und "grep ERROR" brachte
    nichts aber es ging nicht --- weil es "FEHLER" heisst. 

     Richtig sinnvoll:

    "FEHLER: procedure xyz detected missing default data in table ttt"

    geil. Gigabyteweise Overhead mit dem Ergebnis, dass es nun weder deutsch
    noch englisch ist. Toll.

    Nun muss man also alle SQL Script Fehlermeldungen für alle Sprachen
    implementieren, weil Sprachmischmatsch ja falsch ist oder wie?

    Mal ehrlich, das ist doch Mist. Bloss, weil MicroSoft den Leuten erzählt
    hat, Sekretärinnen könnten Drucker und Datenbanken installieren, muss
    man jetzt die Fehlermeldungen in 5 Sprachen schreiben oder was? Ich
    kann aber gar kein Französisch. Was nun?

Das finde ich ärgerlich. Übrigens versteht ein deutschsprachiger Laie
(z.B. eben eine Sekretärin) eine Meldung "FEHLER: Referentielle
Integrität verletzt" auch nicht besser als "ERROR: referential integrity
violated".

    (wobei es sicherlich Sekretärinnen gibt, die das verstehen, dann
    aber auch in englisch)

Ich hätte ja nichts dagegen, wenn man ein SAS-07 (Strukturierte Abfrage
Sprache 2007) erfindet, die ähnlich SQL ist, aber locale kennt. Die
verhält sich halt anders, OK. Aber warum ist SQL plötzlich anders? Es
hiess seit PostgreSQL 6.1 ERROR. Vermutlich hiess es schon immer ERROR.
Nun wird behauptet, der nicht-menschliche Benutzer postgres würde
Deutsch sprechen. Es ist falsch, also ist es ein Bug.

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

Es verhält sich pro locale anderes, es gibt auch weitere Unterschiede.

    Das mit sk oder was das war ist ja ein Beispiel, wo tief unten ein
    Problem auftrat, wo sich awk und bash unterhalten haben. Was nach
    aktueller Meinung ja in einer natürlichen Sprache stattfinden soll.
    Also awk_DE, kennt ihr sicherlich alle aus dem Wörterbuch.

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

lol

    genau, alles wegschmeissen, funktioniert ja, wie langweilig. Man kann
    natürlich keinem zumuten, ein Programm, was 10 Jahre funktioniert hat,
    noch benutzen zu sollen. Lieber gleich updaten. Gut, braucht man 100
    fache Leistung um 10% der Funktionalität zu kriegen, dafür gibt es aber
    auch nur wenig neue Bugs.

Nee, mal Spass beiseite: WARUM?

    Warum macht man nicht neue Sprachen für neue Sprachen? Kann man doch
    machen: myscript.sh (alt) myscript.sh_de_DE (neu) usw. Da können die
    locale Freaks dann doch prima alles immer wieder neu erfinden und
    doppelt und dreifach machen. Der kernel könnte automatisch LC_EXEC
    anhängen, wenn was gestartet würde. Würde sich bestimmt auch jemand
    finden, der dafür ist :-)

Man braucht das alles nur, weil jemand behauptet, man bräuchte es. Ist
wie mit XML.

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

weil es intuitiv ist. Warum ist ö nicht dabei, wenn es doch jetzt locale
sein sollen, oder ist es dabei? Mein zwei, drei Jahre altes System kann
den Kram anscheinend ja noch nicht (Gott sei Dank, ich glaub, ich darf
nie updaten, dann geht vermutlich gar nichts mehr).

"sauberes Arbeiten"? Das sagt man doch erst *jetzt*, wo man merkt, dass
man Mist gebaut hat. "*Wir* waren das ja nicht, *ihr* habt unsauber
gearbeitet". Heute heisst es, Variabelen wären nicht lokalisiert, morgen
wird es heissen: warum habt ihr auch #define LC_ALL nicht in config.h
gesetzt? Genau wie das heute plötzlich zu export LC_ALL gesagt wird.

    sorry, aber das ist echt nervig. Schon schlimm genug, dass heute
    embedded devices mit diesem XML Kram rumfriemen und alles totbremsen,
    weil der Web-Java-XML-Hype keine Grenzen kannte, nach Unicode jetzt auch
    noch locale in Shellscripten...

(wie gesagt, bei Sachen wie OpenOffice etc seh ich das ein, das ist was
anderes, nämlich keine Programmiersprache)

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

(Das ist aber wirklich sehr an den Haaren herbeigezogen, da brauche ich
ja nichts weiter dazu zu sagen).

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

Das ist falsch, dann würde Argv bei LC_ALL=C nicht als Fehler erkannt.

jajaja, soooo einfach kommste nicht davon!! :-)

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

Das dachte man vor drei Jahren vermutlich über awk auch. Hey, 2004 gab 
es United Linux. Die c++-Streams konnten da noch kein LFS (large file).
2 GB, grössere Dateien gab es in C++ einfach nicht. Heute können sie
das --- aber bash-Scripte gehen nicht mehr. Der Standard ist immer noch
der gleiche C99, soweit ich weiss.

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

Das entscheiden heute ja aber nicht mehr die mit Ahnung (Programmierer,
Informatiker) sondern die ohne (Windows-Umsteiger, die dies und jenes
Windows-XP Hotplug verhalten erwarten und in der Folge den halben kernel
kaputtdamagen lassen und /dev ein tmpfs ist...)

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

genau, kann zwar keiner mehr arbeiten, der mit alten Daten zu tun hat,
aber man kann sagen, es ist etwas richtiger als vorher. Gut, ein
Kalender *ist* ne willkürliche Sache, aber ums Prinzip willen !#?$*&!+

ach egal schlecht für den Blutdruck lol

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

ja und wozu nu?

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

Ich habe bei meiner Post kein Örtliches mit skandinavischer locale
bekommen können. Ich bin mir ziemlich sicher, dass soetwas nicht
existiert. Mir drängt sich der Verdacht auf, dass liegt daran, weil man
es nicht braucht. Möglicherweise erwartet ein Ausländer in einem
deutschen Buch deutsche Sortierung. Ich würde in einem englischem Buch
ja auch keine Umlaute erwarten.

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

Ach so, dann ist es aber einfach: an einem Bildschirm ist locale=POSIX.
Da man ja an einen Bildschirm umzieht, würde man sich also eine andere
Sortierung erhoffen. Ist also ganz einfach, man muss die locale einfach
abschaffen :-)

soooooooooooooooo, Fertig! :-)

oki,

Steffen

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