Re: Eigenatiges BASH problem...
On Wed, Mar 23, 2005 at 09:25:14PM +0100, Michelle Konzack wrote: [EMAIL PROTECTED] Das ist das Problem. LANG wird von der bash nur interpretiert, wenn es vor dem Start der bash schon gesezt ist. (LANG hat Einfluss auf LC_COLLATE wenn dieses nicht gesetzt ist). $ locale | fgrep COL LC_COLLATE=C $ export | grep LC_COL\|LANG $ ls A B C a b c $ ls [A-Z]* A B C # Soweit so gut $ export LANG=en_US $ locale | fgrep LC_COL LC_COLLATE=en_US $ ls [A-Z]* A B C # ??? $ unset LANG; LC_COLLATE=en_US $ ls [a-z]* A B C a b c $ unset LC_COLLATE; export LANG=en_US $ exec bash $ ls [a-z]* a A b B c C /GM -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
Bruno Hertz wrote on 24/03/2005 02:39: Sven Mueller [EMAIL PROTECTED] writes: Bruno Hertz wrote on 24/03/2005 00:01: [stripped] Also irgendwie ist das Verhalten der Bash bei mir schon sehr merkwürdig. Voraussetzung: Verzeichnis mit leeren Dateien der Namen a b c d e f g A B C D E F G weiterhin: Skript (../t.sh vom fraglichen Verzeichnis aus) mit folgendem Inhalt: == #!/bin/bash unset LC_CTYPE LC_ALL LC_COLLATE export LC_CTYPE=$1 printenv | grep LC for i in `echo [A-C]`; do echo $i done == Dann noch in der aktuellen interaktiven Shell LC_COLLATE=de_DE gesetzt. So, jetzt rufe ich das Skript auf: # ../t.sh C LC_COLLATE=C A b B c C Hä? Laut Deiner Aussage müsste das eigentlich nur A B und C (nach LC_COLLATE=C) ausgeben. Wenn ich statt C de_DE oder us_US angebe, dann bleibt die Ausgabe wie oben gezeigt. Setze ich jetzt in meiner interaktiven Shell LC_COLLATE auf C (oder lösche es samt der anderen LC_* Variablen), dann bleibt die Ausgabe des Scripts wieder völlig unbeeindruckt vom Übergabeparameter, abgesehen von der Ausgabe der LC_COLLATE-Zeile. Nur sieht es diesmal so aus: # ../t.sh de_DE LC_COLLATE=de_DE A B C Hä? Laut Deiner Aussage müsste das Script eigentlich A b B c C ausgeben, oder? Vergiss mal das unset LC_ALL. Das ändert nichts. LC_COLLATE hat Vorrang vor LC_ALLLC_CTYPE. Um es richtig schön zu machen, hier noch zwei Beispiele: # LC_COLLATE=C ../t.sh de_DE LC_COLLATE=de_DE A B C # LC_COLLATE=de_DE ../t.sh C LC_COLLATE=C A b B c C S.o. Jetzt schlauer? Hint: Selbst die angeblichen Subshells sind nicht wirklich eigene Instanzen der Bash sondern werden intern aufgelöst. Schlauer, ja, in Bezug auf dich :) Erzähl doch nochmal genau was 'intern aufgelöst' heißt. Ich versteh das irgendwie nicht ... :) Ganz einfach: Die Bash startet für Prozesse in `` keinen eigenen Prozess, wenn sondern erstellt nur einen neuen internen Context. Programme in `` werden natürlich ebenso gestartet, wie auch bei direktem Aufruf. Auch für Pseudo-Subshells wie ( ls; echo N ) wird kein eigener Shell-Prozess gestartet, sondern nur ein Thread bzw. neuer interner Context. Deshalb macht es auch absolut keinen Unterschied für die Auflösung von Aufzählungen auf der Kommandozeile, ob Du vor einem for i in [A-C]; do echo $i; done nun LC_COLLATE ändert oder nicht. Leg mal ein Verzeichnis an mit den Dateien a A b B (das reicht für die Demonstration) und mache nacheinander folgendes: unset LC_ALL LC_CTYPE LC_COLLATE bash # wird ohne locales-Spezifikationen im Environment gestartet for i in [A-B]; do echo $i ; done LC_COLLATE=de_DE for i in [A-B]; do echo $i ; done LC_COLLATE=C for i in [A-B]; do echo $i ; done exit export LC_COLLATE=de_DE bash # hat jetzt LC_COLLATE=de_DE gesetzt for i in [A-B]; do echo $i ; done LC_COLLATE=de_DE for i in [A-B]; do echo $i ; done LC_COLLATE=C for i in [A-B]; do echo $i ; done exit export LC_COLLATE=C bash # hat jetzt LC_COLLATE=C gesetzt for i in [A-B]; do echo $i ; done LC_COLLATE=de_DE for i in [A-B]; do echo $i ; done LC_COLLATE=C for i in [A-B]; do echo $i ; done exit Und versuche zu verstehen, warum die Ausgaben so aussehen, wie sie aussehen. die Shell die Pattern Expansion macht, ist also fraglich, was bei ihrem Aufruf der Wert von LC_COLLATE war. Und so habe ich das obige Script dazu gebracht, das zu tun, was ich wollte: Nochmal: Dafür, wie die Shell ein Pattern auflöst ist nicht der Wert von LC_COLLATE zum Zeitpunkt der Pattern-Expansion zuständig, sondern der Wert von LC_COLLATE (oder LC_ALL, wenn LC_COLLATE nicht gesetzt ist) zu dem Zeitpunkt, als die Shell aufgerufen wurde. Die Bash initialisiert die locales-Klamotten nicht neu, wenn die Environment-Variablen geändert werden. Daher ist es ihr völlig schnuppe, wenn man die während der Laufzeit der Bash ändert. Andererseits sind die geänderten Werte für aufgerufene Programme (und dazu gehören Shellscripte) natürlich schon wichtig. Alles klar? Sicher. Scheinbar nicht. Meine Empfehlungen (in dieser Reihenfolge): man -S 7 locale http://www.opengroup.org/onlinepubs/007908799/xbd/locale.html und schließlich die glibc Mailingliste. Kenne ich, danke. Ich weiss, wie locales funktioniert. Du aber scheinbar nicht vollständig. Ciao, Sven -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
On Thu, Mar 24, 2005 at 04:09:28PM +0100, Sven Mueller wrote: Die Bash initialisiert die locales-Klamotten nicht neu, wenn die Environment-Variablen geändert werden. Daher ist es ihr völlig schnuppe, wenn man die während der Laufzeit der Bash ändert. Andererseits sind die Nicht ganz: bash$ ls A B C a b c bash$ echo $LC_COLLATE $LANG bash$ ls [a-z]* a b c bash$ export LC_COLLATE=en_US bash$ ls [a-z]* a A b B c C bash$ unset LC_COLLATE; export LANG=en_US bash$ ls [a-z]* a b c bash$ exec bash bash$ ls [a-z]* a A b B c C LC_COLLATE beachtet sie sehrwohl, LANG hingegen nicht. /GM -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
Sven Mueller [EMAIL PROTECTED] writes: Vergiss mal das unset LC_ALL. Das ändert nichts. LC_COLLATE hat Vorrang vor LC_ALLLC_CTYPE. Quatsch. Probier's mal aus. Teste mal (mit LANG != C/POSIX) LC_COLLATE=C echo * unset LC_ALL echo * LC_CTYPE hat mit dem Thema übrigens gar nichts zu tun. Fängt ja gut an ... Ganz einfach: Die Bash startet für Prozesse in `` keinen eigenen Prozess, wenn sondern erstellt nur einen neuen internen Context. Programme in `` werden natürlich ebenso gestartet, wie auch bei direktem Aufruf. Auch für Pseudo-Subshells wie ( ls; echo N ) wird kein eigener Shell-Prozess gestartet, sondern nur ein Thread bzw. neuer interner Context. Selten so dämliches Zeug gelesen. Selbst für ein builtin wie echo wird in backticks ein child process erzeugt, erst recht für binaries. Lass mal deine Scripts mit strace -f laufen und schau dir mal die clones/forks an. Weiss gar nicht warum ich auf solchen Blödsinn überhaupt antworte ... Deshalb macht es auch absolut keinen Unterschied für die Auflösung von Aufzählungen auf der Kommandozeile, ob Du vor einem for i in [A-C]; do echo $i; done nun LC_COLLATE ändert oder nicht. Leg mal ein Verzeichnis an mit den Dateien a A b B (das reicht für die Demonstration) und mache nacheinander folgendes: unset LC_ALL LC_CTYPE LC_COLLATE Du hast noch immer nicht verstanden was 'unset LC_ALL' bewirkt. Meld' dich wieder, wenn du einen Schimmer hast (kann allerdings nicht garantieren, daß ich so lange warte). Und versuche zu verstehen, warum die Ausgaben so aussehen, wie sie aussehen. Versuch's mal besser selbst. Ich räum' dir allerdings wenig Chancen ein. Kenne ich, danke. Ich weiss, wie locales funktioniert. Du aber scheinbar nicht vollständig. Wie kann man nur so peinlich sein. Und das auch noch öffentlich, auf von Suchmaschinen indizierten Listen ... kaum glaublich.
Re: Eigenatiges BASH problem...
Am 2005-03-22 12:57:59, schrieb Bruno Hertz: On Tue, 2005-03-22 at 09:12 +0100, Michelle Konzack wrote: $HOME/devel/bash/[A-Z]*.tmp Beim Obigen sollte er aber nur Dateien anzeigen die mit den Großbuchstaben [A-Z] anfangen... Genau darüber reden wir die ganze Zeit, von den Buchstaben 'A bis Z'. Wenn die collation order aber z.B. a A b B z Z ist, sind das aber eben nicht nur Grossbuchstaben (sondern alle Gross- und Kleinbuchstaben von a bis z ausser 'klein a'). LC_COLLATE=C ls $HOME/devel/bash/[A-Z]*.tmp zeigt aber ebenfals klein und gross Buchstaben an... LC_COLLATE hat NICHTS mit RegExp zu tun, sonern nur mit der Reihenfolge Also ich mache jetzt zur Zeit ein LIST=`LC_COLLATE=C $HOME/devel/bash/*.tmp` womit ich sortiert die Dateien angezeigt bekomme, erst die mit Großbuchstaben anfangen, dann den Rest. Na also, Problem gelöst. Nee, denn es ist nicht die Loesung zu ls $HOME/devel/bash/[A-Z]*.tmp Ich nehme daher an, dass du in der interaktiven Shell ein Setting hast, das eben nicht in Skripte exportiert wird (?) ??? Wie denn das ??? Indem du LC_COLLATE (e.g. im profile) zwar setzt aber nicht exportierst. Alles as ich verwende ist [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] was die die ganze Zeit auch funktioniert hat. Ich frage mich nur, warum mitten in einem Release wie WOODY sowas geändeet wird... Gute Frage. Wie gesagt handelt es sich um die glibc. Wenn also irgendwo ein 'Fehler' ist, liegt er dort. Steht irgendwo im BTS und auch in der debian-devel Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Eigenatiges BASH problem...
Michelle Konzack [EMAIL PROTECTED] wrote: LC_COLLATE=3DC ls $HOME/devel/bash/[A-Z]*.tmp zeigt aber ebenfals klein und gross Buchstaben an... Ja. Weil es garnicht zum tragen kommt. Wer expandiert Wildcards? Wer bekommt das LC_COLLATE? Genau. regards Mario -- Whenever you design a better fool-proof software, the genetic pool will always design a better fool. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
Michelle Konzack [EMAIL PROTECTED] writes: Am 2005-03-22 12:57:59, schrieb Bruno Hertz: Genau darüber reden wir die ganze Zeit, von den Buchstaben 'A bis Z'. Wenn die collation order aber z.B. a A b B z Z ist, sind das aber eben nicht nur Grossbuchstaben (sondern alle Gross- und Kleinbuchstaben von a bis z ausser 'klein a'). LC_COLLATE=C ls $HOME/devel/bash/[A-Z]*.tmp zeigt aber ebenfals klein und gross Buchstaben an... Logisch. LC_COLLATE=C wird hier nur an ls exportiert, für die Shell bleibt es aber unwirksam. D.h. hier greift immer noch dein locale setting. Um auch für die Shell also LC_COLLATE auf C zu setzen LC_COLLATE=C ls $HOME/devel/bash/[A-Z]*.tmp Um es auch für Subshells/geforkte Prozesse wirksam zu machen export LC_COLLATE=C LC_COLLATE hat NICHTS mit RegExp zu tun, sonern nur mit der Reihenfolge Wie du auf RegExp kommst ist mir ein Rätsel. Hat das irgendjemand erwähnt? Und brüllen mußt du auch nicht unbedingt ... Na also, Problem gelöst. Nee, denn es ist nicht die Loesung zu ls $HOME/devel/bash/[A-Z]*.tmp Ich könnt's nochmal erklären, spare es mir aber. Es ist wirklich alles gesagt. Alles as ich verwende ist [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Dann poste auch mal die Ausgabe von locale. Gute Frage. Wie gesagt handelt es sich um die glibc. Wenn also irgendwo ein 'Fehler' ist, liegt er dort. Steht irgendwo im BTS und auch in der debian-devel Stimmt. Bei all den Bug Reports schien sich aber bisher zu bewahrheiten, dass es kein Bug war sondern eben Unverständnis der collate Thematik. Ich sehe kein offenes/relevantes Bug Listing zu diesem Thema.
Re: Eigenatiges BASH problem...
Am 2005-03-23 21:07:53, schrieb Bruno Hertz: Logisch. LC_COLLATE=C wird hier nur an ls exportiert, für die Shell bleibt es aber unwirksam. D.h. hier greift immer noch dein locale setting. Um auch für die Shell also LC_COLLATE auf C zu setzen LC_COLLATE=C ls $HOME/devel/bash/[A-Z]*.tmp Hä ? Für was ? Ein 'ls $HOME/devel/bash/[A-Z]*.tmp' benötigt kein LC_COLLATE. Das LC_COLLATE ist nur bei 'ls $HOME/devel/bash/*.tmp' witksam. Um es auch für Subshells/geforkte Prozesse wirksam zu machen export LC_COLLATE=C Das will ich aber nicht... LC_COLLATE=de_DE So ist es seit 03/1999 und hat funktioniert. LC_COLLATE hat NICHTS mit RegExp zu tun, sonern nur mit der Reihenfolge Wie du auf RegExp kommst ist mir ein Rätsel. Hat das irgendjemand erwähnt? Und brüllen mußt du auch nicht unbedingt ... Esa geht darum das die BASH [A-Z]* expandiert, aber ein SCRIPT in der gleichen Shell es ignoriert. Na also, Problem gelöst. Nee, denn es ist nicht die Loesung zu ls $HOME/devel/bash/[A-Z]*.tmp Ich könnt's nochmal erklären, spare es mir aber. Es ist wirklich alles gesagt. Ihr redet nur con LC_COLLATE was nichts damit zu tun hat. Ich habe erste heute vormittag eine WOODY Maschine von den 3.0r0 CD's installiert und mein Script funktioniert... Nach dem Update auf r4 funktionierren keine BACKUP-Scripts und jede menge andere Scrips nicht mehr. Soweit ich das aus GOOLGE erfahren habe hängt das mit dem Security update der libc6 zusammen... da ist was kaputt gegangen. Alles as ich verwende ist [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Dann poste auch mal die Ausgabe von locale. [EMAIL PROTECTED] LC_CTYPE=[EMAIL PROTECTED] LC_NUMERIC=[EMAIL PROTECTED] LC_TIME=[EMAIL PROTECTED] LC_COLLATE=[EMAIL PROTECTED] LC_MONETARY=[EMAIL PROTECTED] [EMAIL PROTECTED] LC_PAPER=[EMAIL PROTECTED] LC_NAME=[EMAIL PROTECTED] LC_ADDRESS=[EMAIL PROTECTED] LC_TELEPHONE=[EMAIL PROTECTED] LC_MEASUREMENT=[EMAIL PROTECTED] LC_IDENTIFICATION=[EMAIL PROTECTED] LC_ALL= Stimmt. Bei all den Bug Reports schien sich aber bisher zu bewahrheiten, dass es kein Bug war sondern eben Unverständnis der collate Thematik. Ich sehe kein offenes/relevantes Bug Listing zu diesem Thema. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Eigenatiges BASH problem...
Michelle Konzack [EMAIL PROTECTED] writes: Am 2005-03-23 21:07:53, schrieb Bruno Hertz: Um auch für die Shell also LC_COLLATE auf C zu setzen LC_COLLATE=C ls $HOME/devel/bash/[A-Z]*.tmp Hä ? Für was ? Stimmt, war falsch. Richtig: export LC_COLLATE=C ls $HOME/devel/bash/[A-Z]*.tmp Ein 'ls $HOME/devel/bash/[A-Z]*.tmp' benötigt kein LC_COLLATE. Inkorrekt. Es braucht es sogar zweimal: (1) $HOME/devel/bash/[A-Z]*.tmp wird von der Shell expandiert. Die Reihenfolge wird dabei bestimmt von LC_COLLATE. man bash, 'path expansion' und 'range expression' (2) ls erhält die expandierte Parameterliste und sortiert jetzt aber nochmal, wieder gemäß LC_COLLATE. Deshalb oben das export. man strcoll (wird von ls verwendet) Das LC_COLLATE ist nur bei 'ls $HOME/devel/bash/*.tmp' witksam. Leider falsch. man bash. Um es auch für Subshells/geforkte Prozesse wirksam zu machen export LC_COLLATE=C Das will ich aber nicht... LC_COLLATE=de_DE Das wird nicht gehen. Entgegen eines vorherigen Postings von mir (hatte einen Fehler gemacht weil bei mir de_DE überhaupt nicht installiert war, deshalb hatte ein entsprechendes collate setting auch keine Auswirkung) ist die collation order für de_DE die gleiche wie bei en_US, nämlich a A b B z Z D.h. eine range expression der Form [A-C] enthält die Buchstaben A b B c C d.h. eben nicht nur Grossbuchstaben, und gemäß dieser Reihenfolge wird auch sortiert. Du kannst aber [ABCDEFGHIJKLMNOPQRSTUVWXYZ] schreiben, das geht dann auch mit de_DE :) Die collation order ist für die country locales vor einiger Zeit mal umgestellt worden (sie war vorher wie ASCII, i.e. entsprechend LC_COLLATE=C). Das ist aber schon Jahre her, meine ich ... Wie du auf RegExp kommst ist mir ein Rätsel. Hat das irgendjemand erwähnt? Und brüllen mußt du auch nicht unbedingt ... Esa geht darum das die BASH [A-Z]* expandiert, aber ein SCRIPT in der gleichen Shell es ignoriert. Du meinst daß das Skript anders expandiert als die Shell. Mit regexps hat das aber nichts zu tun, und das hat auch niemand behauptet. Ihr redet nur con LC_COLLATE was nichts damit zu tun hat. Ich habe erste heute vormittag eine WOODY Maschine von den 3.0r0 CD's installiert und mein Script funktioniert... Unser Thema war die Sortierreihenfolge von Ausdrücken wie ls /irgendeinpfad/[A-Z]*.irgendwas und welche Buchstaben (klein,groß) in solchen range expressions vorkommen. Und das ist sowohl was die shell expansion als auch die Sortierung von ls angeht bestimmt von LC_COLLATE. Probier's dochmal mit einem Testskript der Form LC_COLLATE=$1 echo $LC_COLLATE # shell expansion gemäß $1 echo /irgendeinpfad/[A-Z]*.irgendwas # shell expansion und sortierung von ls; da LC_COLLATE nicht # exportiert wurde, greift $1 hier noch nicht ls /irgendeinpfad/[A-Z]*.irgendwas export LC_COLLATE # shell expansion gemäß $1 echo /irgendeinpfad/[A-Z]*.irgendwas # ausgabe von ls sollte mit vorherigem echo korrespondieren # da LC_COLLATE exportiert wurde ls /irgendeinpfad/[A-Z]*.irgendwas und ruf es mit skript.sh C resp. de_DE und wasnoch auf. Dann wird die Sache vielleicht klarer. Nach dem Update auf r4 funktionierren keine BACKUP-Scripts und jede menge andere Scrips nicht mehr. Schlimm. Soweit ich das aus GOOLGE erfahren habe hängt das mit dem Security update der libc6 zusammen... da ist was kaputt gegangen. Kann sein. Wie gesagt habe ich kein Woody, nur Sarge. Letztres ist aber up-to-date, und die Dinge funktionieren hier genau so wie von mir beschrieben. LC_COLLATE=[EMAIL PROTECTED] OK, das sollte dann aber auch für die interaktive Shell gelten. Wenn die mit diesem setting [A-Z] in A B C ... Z expandiert, ist etwas komisch. Sie sollte es in a A b B ... z Z expandieren, interaktiv ebenso wie per Skript.
Re: Eigenatiges BASH problem...
Am 2005-03-23 22:38:19, schrieb Bruno Hertz: Inkorrekt. Es braucht es sogar zweimal: (1) $HOME/devel/bash/[A-Z]*.tmp wird von der Shell expandiert. Die Reihenfolge wird dabei bestimmt von LC_COLLATE. man bash, 'path expansion' und 'range expression' Was bedeutet das GNU/Linux plötzlich Case-Insensitive geworden ist. denn bei mir sind A-Z GROSSbuchstaben und a-z kleinBUCHSTABEN. (2) ls erhält die expandierte Parameterliste und sortiert jetzt aber nochmal, wieder gemäß LC_COLLATE. Deshalb oben das export. man strcoll (wird von ls verwendet) Aber die expandierte Liste ist enen nur [A-Z]* . Also woher kommt dann [a-z]* ? Das LC_COLLATE ist nur bei 'ls $HOME/devel/bash/*.tmp' witksam. Leider falsch. man bash. Dann darf es am BASH Prompt ja auch nicht funktionieren, was es aber tut. Um es auch für Subshells/geforkte Prozesse wirksam zu machen export LC_COLLATE=C Das will ich aber nicht... LC_COLLATE=de_DE Das wird nicht gehen. Entgegen eines vorherigen Postings von mir (hatte Das wiederspricht dann aber das am BASH prompt es auch funktiniert. wenn ich z.b. for i in `ls -d` ; do ls $i/[A-Z]* ; echo ; done ^ Sub-SHELL Sub-SHELL aufrufe funktioniert es einwqndfrei, wogegen Deine Erklärung nicht standhällt. einen Fehler gemacht weil bei mir de_DE überhaupt nicht installiert war, deshalb hatte ein entsprechendes collate setting auch keine Auswirkung) ist die collation order für de_DE die gleiche wie bei en_US, nämlich a A b B z Z D.h. eine range expression der Form [A-C] enthält die Buchstaben A b B c C Ich habe innerhalb des Scripts locale aufgerufen und es liefert die gleiche Antwort wie am BASH prompt. Wenn am BASH Prompt 'ls [A-Z]*' funktioniert und im BASH Script die gleichen locale vorhanden sind, muß der Fehler noch woanderst liegen. Die collation order ist für die country locales vor einiger Zeit mal umgestellt worden (sie war vorher wie ASCII, i.e. entsprechend LC_COLLATE=C). Das ist aber schon Jahre her, meine ich ... Dann wurde locale mit der libc6 aud WOODY r1 geändert. Ihr redet nur con LC_COLLATE was nichts damit zu tun hat. Ich habe erste heute vormittag eine WOODY Maschine von den 3.0r0 CD's installiert und mein Script funktioniert... Unser Thema war die Sortierreihenfolge von Ausdrücken wie ls /irgendeinpfad/[A-Z]*.irgendwas und welche Buchstaben (klein,groß) in solchen range expressions vorkommen. Und das ist sowohl was die shell expansion als auch die Sortierung von ls angeht bestimmt von LC_COLLATE. Ich gebe ja an das ich nur Dateien die mit GROSS Buchstaben anfangen haben will. LC_COLLATE hat aber mit der Sortierreihenfolge zu tun. (hat mir jemand von der debian-devel klar gemacht) Probier's dochmal mit einem Testskript der Form LC_COLLATE=$1 echo $LC_COLLATE # shell expansion gemäß $1 echo /irgendeinpfad/[A-Z]*.irgendwas # shell expansion und sortierung von ls; da LC_COLLATE nicht # exportiert wurde, greift $1 hier noch nicht ls /irgendeinpfad/[A-Z]*.irgendwas export LC_COLLATE # shell expansion gemäß $1 echo /irgendeinpfad/[A-Z]*.irgendwas # ausgabe von ls sollte mit vorherigem echo korrespondieren # da LC_COLLATE exportiert wurde ls /irgendeinpfad/[A-Z]*.irgendwas und ruf es mit skript.sh C resp. de_DE und wasnoch auf. Dann wird die Sache vielleicht klarer. __( command 'skript.sh de_DE' )___ / | de_DE | /home/michelle.konzack/devel/bash/[A-Z]*.tmp | /home/michelle.konzack/devel/bash/BASE.tmp | /home/michelle.konzack/devel/bash/help_version.tmp | /home/michelle.konzack/devel/bash/pid.tmp | /home/michelle.konzack/devel/bash/prog_parts_by_option.tmp | /home/michelle.konzack/devel/bash/read_config.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help_and_pid.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help.tmp | /home/michelle.konzack/devel/bash/SKEL_with_pid.tmp | /home/michelle.konzack/devel/bash/td.tmp | /home/michelle.konzack/devel/bash/[A-Z]*.tmp | /home/michelle.konzack/devel/bash/BASE.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help_and_pid.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help.tmp | /home/michelle.konzack/devel/bash/SKEL_with_pid.tmp | /home/michelle.konzack/devel/bash/help_version.tmp | /home/michelle.konzack/devel/bash/pid.tmp | /home/michelle.konzack/devel/bash/prog_parts_by_option.tmp | /home/michelle.konzack/devel/bash/read_config.tmp | /home/michelle.konzack/devel/bash/td.tmp \__ Das ist aber nicht das was ich will, denn ich habe ja [A-Z]* angegeben und nicht [A-Za-z]*. Im Script wird einfach GROS und klein Schreibung ignoriert. LC_COLLATE sortiert zwar richtig, aber 'ls' zeigt falsch an. Kann sein. Wie gesagt habe ich kein Woody, nur Sarge. Letztres ist aber up-to-date, und die Dinge funktionieren hier genau so wie von mir beschrieben. Also ich
Re: Eigenatiges BASH problem...
Michelle Konzack [EMAIL PROTECTED] writes: Am 2005-03-23 22:38:19, schrieb Bruno Hertz: (1) $HOME/devel/bash/[A-Z]*.tmp wird von der Shell expandiert. Die Reihenfolge wird dabei bestimmt von LC_COLLATE. man bash, 'path expansion' und 'range expression' Was bedeutet das GNU/Linux plötzlich Case-Insensitive geworden ist. denn bei mir sind A-Z GROSSbuchstaben und a-z kleinBUCHSTABEN. S.u. (2) ls erhält die expandierte Parameterliste und sortiert jetzt aber nochmal, wieder gemäß LC_COLLATE. Deshalb oben das export. man strcoll (wird von ls verwendet) Aber die expandierte Liste ist enen nur [A-Z]* . Also woher kommt dann [a-z]* ? Unter de_DE ist [A-Z] = A b B c C ... z Z Dann darf es am BASH Prompt ja auch nicht funktionieren, was es aber tut. Skript und interaktive Shell sollten mit demselben LC_COLLATE gleich arbeiten, richtig. Wenn es das bei dir nicht tut, hast du (noch) ein anderes Problem. Bei mir funktioniert es einheitlich. LC_COLLATE=de_DE Das wird nicht gehen. Entgegen eines vorherigen Postings von mir (hatte Das wiederspricht dann aber das am BASH prompt es auch funktiniert. wenn ich z.b. for i in `ls -d` ; do ls $i/[A-Z]* ; echo ; done ^ Sub-SHELL Sub-SHELL aufrufe funktioniert es einwqndfrei, wogegen Deine Erklärung nicht standhällt. Kann ich nichts zu sagen ohne Verzeichnisinhalte und output. Ich habe innerhalb des Scripts locale aufgerufen und es liefert die gleiche Antwort wie am BASH prompt. Wenn am BASH Prompt 'ls [A-Z]*' funktioniert und im BASH Script die gleichen locale vorhanden sind, muß der Fehler noch woanderst liegen. Kann sein. Ich gebe ja an das ich nur Dateien die mit GROSS Buchstaben anfangen haben will. LC_COLLATE hat aber mit der Sortierreihenfolge zu tun. (hat mir jemand von der debian-devel klar gemacht) Hier versucht dir auch einer was klar zu machen, und es gestaltet sich sehr mühsam. Deine Aussage, du gäbest an 'nur GROSS Buchstaben' haben zu wollen, ist verkehrt. Unter de_DE heißt [A-Z] eben nicht 'nur GROSS Buchstaben', sondern alle Buchstaben die gemäß der wirksamen Sortierreihenfolge in dem Range A bis Z enthalten sind. Wenn die Sortierung aber eben a A b B ... z Z ist, sind in dem Range auch alle Kleinbuchstaben außer (klein) a enthalten. __( command 'skript.sh de_DE' )___ / | de_DE | /home/michelle.konzack/devel/bash/[A-Z]*.tmp Wieso wird das nicht expandiert? Hast du quotes eingefügt? | /home/michelle.konzack/devel/bash/BASE.tmp | /home/michelle.konzack/devel/bash/help_version.tmp | /home/michelle.konzack/devel/bash/pid.tmp | /home/michelle.konzack/devel/bash/prog_parts_by_option.tmp | /home/michelle.konzack/devel/bash/read_config.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help_and_pid.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help.tmp | /home/michelle.konzack/devel/bash/SKEL_with_pid.tmp | /home/michelle.konzack/devel/bash/td.tmp Wie erwartet unter de_DE (für ls greift hier deine default locale). | /home/michelle.konzack/devel/bash/[A-Z]*.tmp Wieso wird das nicht expandiert? So können wir es nicht mit der Ausgabe von ls vergleichen. | /home/michelle.konzack/devel/bash/BASE.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help_and_pid.tmp | /home/michelle.konzack/devel/bash/SKEL_with_help.tmp | /home/michelle.konzack/devel/bash/SKEL_with_pid.tmp | /home/michelle.konzack/devel/bash/help_version.tmp | /home/michelle.konzack/devel/bash/pid.tmp | /home/michelle.konzack/devel/bash/prog_parts_by_option.tmp | /home/michelle.konzack/devel/bash/read_config.tmp | /home/michelle.konzack/devel/bash/td.tmp Das sollte nicht sein, da du das Skript mit de_DE aufgerufen hast, was sowieso deiner default locale entspricht. Ein export macht also gar keinen Unterschied. Der Range wird zwar noch richtig von der Shell expandiert (inklusive Kleinbuchstaben), aber ls sortiert gemäß C locale. Ist dein ls veraltet (strcmp statt strcoll für Vergleiche) ? Aber dann sollte es oben ja das gleiche sein, da du ja mit de_DE eigentlich sowieso nichts änderst. Sehr undurchsichtig. Hast du ein LC_COLLATE=C vor das zweite ls gesetzt? Im übrigen wäre der Vergleich mit C ja sowieso das interessante gewesen ... \__ Das ist aber nicht das was ich will, denn ich habe ja [A-Z]* angegeben und nicht [A-Za-z]*. Im Script wird einfach GROS und klein Schreibung ignoriert. LC_COLLATE sortiert zwar richtig, aber 'ls' zeigt falsch an. Ich rede über die Expansion von ranges jetzt nicht nochmal. Wenn du jetzt noch nicht verstanden hast daß [A-Z] nicht automatisch 'nur Großbuchstaben' heißt kann ich auch nichts mehr dazu sagen. Also ich habe hier eine Develststion mit POTATO, WOODY, SARGE und SID chroots... Ich habe überall den gleichen Fehler... (i386 + amd64) Auf 68k und powerpc habe ich das ergebnis wie bei Dir. Wenn der
Re: Eigenatiges BASH problem...
Bruno Hertz wrote on 24/03/2005 00:01: [stripped] Also irgendwie ist das Verhalten der Bash bei mir schon sehr merkwürdig. Voraussetzung: Verzeichnis mit leeren Dateien der Namen a b c d e f g A B C D E F G weiterhin: Skript (../t.sh vom fraglichen Verzeichnis aus) mit folgendem Inhalt: == #!/bin/bash unset LC_CTYPE LC_ALL LC_COLLATE export LC_CTYPE=$1 printenv | grep LC for i in `echo [A-C]`; do echo $i done == Dann noch in der aktuellen interaktiven Shell LC_COLLATE=de_DE gesetzt. So, jetzt rufe ich das Skript auf: # ../t.sh C LC_COLLATE=C A b B c C Hä? Laut Deiner Aussage müsste das eigentlich nur A B und C (nach LC_COLLATE=C) ausgeben. Wenn ich statt C de_DE oder us_US angebe, dann bleibt die Ausgabe wie oben gezeigt. Setze ich jetzt in meiner interaktiven Shell LC_COLLATE auf C (oder lösche es samt der anderen LC_* Variablen), dann bleibt die Ausgabe des Scripts wieder völlig unbeeindruckt vom Übergabeparameter, abgesehen von der Ausgabe der LC_COLLATE-Zeile. Nur sieht es diesmal so aus: # ../t.sh de_DE LC_COLLATE=de_DE A B C Hä? Laut Deiner Aussage müsste das Script eigentlich A b B c C ausgeben, oder? Um es richtig schön zu machen, hier noch zwei Beispiele: # LC_COLLATE=C ../t.sh de_DE LC_COLLATE=de_DE A B C # LC_COLLATE=de_DE ../t.sh C LC_COLLATE=C A b B c C Jetzt schlauer? Hint: Selbst die angeblichen Subshells sind nicht wirklich eigene Instanzen der Bash sondern werden intern aufgelöst. Da die Shell die Pattern Expansion macht, ist also fraglich, was bei ihrem Aufruf der Wert von LC_COLLATE war. Und so habe ich das obige Script dazu gebracht, das zu tun, was ich wollte: == #!/bin/bash LOOPED=0 if [ $1 = -loop ]; then LOOPED=1 shift fi unset LC_CTYPE LC_ALL LC_COLLATE export LC_COLLATE=$1 if [ $LOOPED = 0 ]; then printenv | grep LC $0 -loop $@ else echo looped: printenv | grep LC for i in [A-C]; do echo $i done fi == Alles klar? Ciao, Sven -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
Sven Mueller [EMAIL PROTECTED] writes: Bruno Hertz wrote on 24/03/2005 00:01: [stripped] Also irgendwie ist das Verhalten der Bash bei mir schon sehr merkwürdig. Voraussetzung: Verzeichnis mit leeren Dateien der Namen a b c d e f g A B C D E F G weiterhin: Skript (../t.sh vom fraglichen Verzeichnis aus) mit folgendem Inhalt: == #!/bin/bash unset LC_CTYPE LC_ALL LC_COLLATE export LC_CTYPE=$1 printenv | grep LC for i in `echo [A-C]`; do echo $i done == Dann noch in der aktuellen interaktiven Shell LC_COLLATE=de_DE gesetzt. So, jetzt rufe ich das Skript auf: # ../t.sh C LC_COLLATE=C A b B c C Hä? Laut Deiner Aussage müsste das eigentlich nur A B und C (nach LC_COLLATE=C) ausgeben. Wenn ich statt C de_DE oder us_US angebe, dann bleibt die Ausgabe wie oben gezeigt. Setze ich jetzt in meiner interaktiven Shell LC_COLLATE auf C (oder lösche es samt der anderen LC_* Variablen), dann bleibt die Ausgabe des Scripts wieder völlig unbeeindruckt vom Übergabeparameter, abgesehen von der Ausgabe der LC_COLLATE-Zeile. Nur sieht es diesmal so aus: # ../t.sh de_DE LC_COLLATE=de_DE A B C Hä? Laut Deiner Aussage müsste das Script eigentlich A b B c C ausgeben, oder? Vergiss mal das unset LC_ALL. Um es richtig schön zu machen, hier noch zwei Beispiele: # LC_COLLATE=C ../t.sh de_DE LC_COLLATE=de_DE A B C # LC_COLLATE=de_DE ../t.sh C LC_COLLATE=C A b B c C S.o. Jetzt schlauer? Hint: Selbst die angeblichen Subshells sind nicht wirklich eigene Instanzen der Bash sondern werden intern aufgelöst. Schlauer, ja, in Bezug auf dich :) Erzähl doch nochmal genau was 'intern aufgelöst' heißt. Ich versteh das irgendwie nicht ... :) die Shell die Pattern Expansion macht, ist also fraglich, was bei ihrem Aufruf der Wert von LC_COLLATE war. Und so habe ich das obige Script dazu gebracht, das zu tun, was ich wollte: == #!/bin/bash LOOPED=0 if [ $1 = -loop ]; then LOOPED=1 shift fi unset LC_CTYPE LC_ALL LC_COLLATE export LC_COLLATE=$1 if [ $LOOPED = 0 ]; then printenv | grep LC $0 -loop $@ else echo looped: printenv | grep LC for i in [A-C]; do echo $i done fi == Alles klar? Sicher. Meine Empfehlungen (in dieser Reihenfolge): man -S 7 locale http://www.opengroup.org/onlinepubs/007908799/xbd/locale.html und schließlich die glibc Mailingliste.
Re: Eigenatiges BASH problem...
Noch'n Bonus aus /usr/share/doc/bash/COMPAT.gz : --- 13. The behavior of range specificiers within bracket matching expressions in the pattern matcher (e.g., [A-Z]) depends on the current locale, specifically the value of the LC_COLLATE environment variable. Setting this variable to C or POSIX will result in the traditional ASCII behavior for range comparisons. If the locale is set to something else, e.g., en_US (specified by the LANG or LC_ALL variables), collation order is locale-dependent. For example, the en_US locale sorts the upper and lower case letters like this: AaBb...Zz so a range specification like [A-Z] will match every letter except `z'. Other locales collate like aAbBcC...zZ which means that [A-Z] matches every letter except `a'. The portable way to specify upper case letters is [:upper:] instead of A-Z; lower case may be specified as [:lower:] instead of a-z. Look at the manual pages for setlocale(3), strcoll(3), and, if it is present, locale(1). You can find your current locale information by running locale(1): caleb.ins.cwru.edu(2)$ locale LANG=en_US LC_CTYPE=en_US LC_NUMERIC=en_US LC_TIME=en_US LC_COLLATE=en_US LC_MONETARY=en_US LC_MESSAGES=en_US LC_ALL=en_US My advice is to put export LC_COLLATE=C into /etc/profile and inspect any shell scripts run from cron for constructs like [A-Z]. This will prevent things like rm [A-Z]* from removing every file in the current directory except those beginning with `z' and still allow individual users to change the collation order. Users may put the above command into their own profiles as well, of course. --- Klarer geht's dann wohl kaum (und ich hätt' mir nicht den Mund fusselig reden müssen - naja, für's nächste mal ...)
Re: Eigenatiges BASH problem...
Am 2005-03-22 01:48:34, schrieb Bruno Hertz: On Tue, 2005-03-22 at 01:28 +0100, Michelle Konzack wrote: Fehlt nur noch das Problem, warum $HOME/devel/bash/[A-Z]*.tmp in der BASH funktioniert, während in Scripten alle Dateien gemischt werden, also [A-Z] einfach ignoriert wird. Also, ich habe LC_COLLATE=en_US, und bei mir werden auch auf der bash Kommandozeile Gross- und Kleinschreibung in 'range expressions' nicht Beim Obigen sollte er aber nur Dateien anzeigen die mit den Großbuchstaben [A-Z] anfangen... Unter SLINK, POTATO und WOODY r0 funktioniert es... Genaugenommen über 30 meiner alten Scripte. Seit r1 oder r2 habe ich nur noch Fehlermeldungen. Ich mußte feststellen das bei WOODY seit release 0 einiges kaputt gegangen ist... unterschieden. Ich habe also auch in diesem Fall das gleiche Verhalten, wie du es nur für Skripte beobachtest. Also ich mache jetzt zur Zeit ein LIST=`LC_COLLATE=C $HOME/devel/bash/*.tmp` womit ich sortiert die Dateien angezeigt bekomme, erst die mit Großbuchstaben anfangen, dann den Rest. Ich nehme daher an, dass du in der interaktiven Shell ein Setting hast, das eben nicht in Skripte exportiert wird (?) ??? Wie denn das ??? In meiner Loginshell habeich nichts besonderes, was das verhalten der BASH verändert. Die Geschichte ist insgesamt nicht ganz durchsichtig, insbesondere was die glibc Implementierung angeht. Generell arbeite ich daher lieber mit character classes wie [[:upper:]]. Genau, denn ich hatte da was im BTS gelesen das da etwas in WOODY r1/2 verändert wurde.. Seitdem habe ich mit unzähligen Scripten Probleme. Hier ist ein Thread, in dem das Thema (weiter unten, ab Posting 9) diskutiert wird http://groups.google.ch/groups?hl=delr=threadm=9qd9ot0e1b4cpboupq7p78ch9o4ub6vcb1%404ax.com inklusive Beschimpfungen, aber leider auch nicht erschöpfend :) Mal sehn... Für letztendlichen Durchblick ist wohl das Verständnis von /usr/share/i18n/locales/iso14651_t1 nötig ... Ich frage mich nur, warum mitten in einem Release wie WOODY sowas geändeet wird... Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Eigenatiges BASH problem...
Am 2005-03-22 02:05:31, schrieb Gerhard Meier: Das liegt daran, dass die bash imho kaputt ist. Siehe http://www.linuxhaters.de/Shell Werd ich mir ansehen... D.h sie verhaelt sich nur den Umgebungsvariablen entsprechend, wenn die Umgebungsvariablen beim Start der Bash schon gesetzt sind. Ähm, wenn Du das Script in der BASH startest haste die Umgebungsvariablen. Hat ja bis vor 2 Jahren funktioniert... Sprich, die Scripte funktionierten unte WOODY r0 (und ev. r1) /GM Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Eigenatiges BASH problem...
Am 2005-03-22 02:45:46, schrieb Bruno Hertz: Kann ich nicht bestätigen: [EMAIL PROTECTED]:~/tmp$ ls -l total 0 -rw-r--r-- 1 bhertz bhertz 0 2005-03-22 02:40 a -rw-r--r-- 1 bhertz bhertz 0 2005-03-22 02:40 A -rw-r--r-- 1 bhertz bhertz 0 2005-03-22 02:40 z -rw-r--r-- 1 bhertz bhertz 0 2005-03-22 02:40 Z [EMAIL PROTECTED]:~/tmp$ locale | grep COLLATE LC_COLLATE=en_US Mach hier de_DE [EMAIL PROTECTED]:~/tmp$ ls [A-Z] A z Z Dann bekommste hier:A Z [EMAIL PROTECTED]:~/tmp$ ls [a-z] a A z genauso wie hier: a z [EMAIL PROTECTED]:~/tmp$ export LC_COLLATE=C Das habe ich auch schon exportiert [EMAIL PROTECTED]:~/tmp$ ls [A-Z] A Z [EMAIL PROTECTED]:~/tmp$ ls [a-z] a z und ein:ls * liefert:A Z a z Also der Effect den ich ursprünglich erreichen wollte. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Eigenatiges BASH problem...
Am 2005-03-22 01:44:37, schrieb Gerhard Meier: On Tue, Mar 22, 2005 at 12:07:17AM +0100, Michelle Konzack wrote: LIST1=`ls $HOME/devel/bash/[A-Z]*.tmp` LIST2=`ls $HOME/devel/bash/[a-z]*.tmp` Ganz nebenbei, useless use of backticks: LIST1=$HOME/devel/bash/[A-Z]*.tmp LIST2=$HOME/devel/bash/[a-z]*.tmp ??? Ich will nicht $HOME/devel/bash/[A-Z]*.tmp als String haben, sondern die Ausgabe von `ls $HOME/devel/bash/[A-Z]*.tmp`. /GM Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Eigenatiges BASH problem...
On Tue, 2005-03-22 at 09:12 +0100, Michelle Konzack wrote: $HOME/devel/bash/[A-Z]*.tmp Beim Obigen sollte er aber nur Dateien anzeigen die mit den Grobuchstaben [A-Z] anfangen... Genau darber reden wir die ganze Zeit, von den Buchstaben 'A bis Z'. Wenn die collation order aber z.B. a A b B z Z ist, sind das aber eben nicht nur Grossbuchstaben (sondern alle Gross- und Kleinbuchstaben von a bis z ausser 'klein a'). Unter SLINK, POTATO und WOODY r0 funktioniert es... Genaugenommen ber 30 meiner alten Scripte. Seit r1 oder r2 habe ich nur noch Fehlermeldungen. Ich mute feststellen das bei WOODY seit release 0 einiges kaputt gegangen ist... Mag sein, ich habe kein Woody installiert. Die Thematik ist jedoch nicht neu. Du wirst einige bug filings finden, die hiermit zusammen hngen, aber eigentlich keine bugs sind. Also ich mache jetzt zur Zeit ein LIST=`LC_COLLATE=C $HOME/devel/bash/*.tmp` womit ich sortiert die Dateien angezeigt bekomme, erst die mit Grobuchstaben anfangen, dann den Rest. Na also, Problem gelst. Ich nehme daher an, dass du in der interaktiven Shell ein Setting hast, das eben nicht in Skripte exportiert wird (?) ??? Wie denn das ??? Indem du LC_COLLATE (e.g. im profile) zwar setzt aber nicht exportierst. Ich frage mich nur, warum mitten in einem Release wie WOODY sowas gendeet wird... Gute Frage. Wie gesagt handelt es sich um die glibc. Wenn also irgendwo ein 'Fehler' ist, liegt er dort. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
On Tue, 2005-03-22 at 09:17 +0100, Michelle Konzack wrote: LC_COLLATE=en_US Mach hier de_DE Mach ich auch mal ... (Sarge) [EMAIL PROTECTED]:~/tmp$ ls [A-Z] A z Z Dann bekommste hier:A Z Bekomm ich damit auch mit de_DE. [EMAIL PROTECTED]:~/tmp$ ls [a-z] a A z genauso wie hier: a z Dito. und ein:ls * liefert:A Z a z Kriege ich auch mit de_DE. Die collation order ist hier also insoweit 'in Ordnung', als sie der von ASCII entspricht, anders als z.B. in en_US. Die Frage bleibt also, warum bei dir das bei einigen/allen (?) Skripten anders ist. Fr mich gibt z.B. echo.sh #!/bin/sh echo $LC_COLLATE ls [A-Z]* ls [a-z]* ls * die Ausgabe de_DE A Z a z A Z a z also wie du es haben wolltest, und (erwartungsgemss) genauso wie in der interaktiven Shell. Wie rufst du denn deine Skripte auf? Ich kann nur vermuten, dass irgendwo die locale (resp. LC_COLLATE) umgesetzt wird ... -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
On Tue, 2005-03-22 at 00:07 +0100, Michelle Konzack wrote: ??? - Sprich, die Dateien werden AaBbCcDdEe... sortiert. Liegt an der collation order, die (bestenfalls) mit LC_COLLATE=C der von ASCII entspricht. Also export LC_COLLATE=C ls [A-Z]*.tmp oder besser ls [[:upper:]]*.tmp -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
Am 2005-03-22 01:20:03, schrieb Bruno Hertz: On Tue, 2005-03-22 at 00:07 +0100, Michelle Konzack wrote: ??? - Sprich, die Dateien werden AaBbCcDdEe... sortiert. Liegt an der collation order, die (bestenfalls) mit LC_COLLATE=C der von ASCII entspricht. Danke, habe jetzt LIST=`LC_COLLATE=C $HOME/devel/bash/*.tmp` Funktioniert einwandfrei... Fehlt nur noch das Problem, warum $HOME/devel/bash/[A-Z]*.tmp in der BASH funktioniert, während in Scripten alle Dateien gemischt werden, also [A-Z] einfach ignoriert wird. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Eigenatiges BASH problem...
On Tue, Mar 22, 2005 at 12:07:17AM +0100, Michelle Konzack wrote: LIST1=`ls $HOME/devel/bash/[A-Z]*.tmp` LIST2=`ls $HOME/devel/bash/[a-z]*.tmp` Ganz nebenbei, useless use of backticks: LIST1=$HOME/devel/bash/[A-Z]*.tmp LIST2=$HOME/devel/bash/[a-z]*.tmp /GM -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
On Tue, 2005-03-22 at 01:28 +0100, Michelle Konzack wrote: Fehlt nur noch das Problem, warum $HOME/devel/bash/[A-Z]*.tmp in der BASH funktioniert, whrend in Scripten alle Dateien gemischt werden, also [A-Z] einfach ignoriert wird. Also, ich habe LC_COLLATE=en_US, und bei mir werden auch auf der bash Kommandozeile Gross- und Kleinschreibung in 'range expressions' nicht unterschieden. Ich habe also auch in diesem Fall das gleiche Verhalten, wie du es nur fr Skripte beobachtest. Ich nehme daher an, dass du in der interaktiven Shell ein Setting hast, das eben nicht in Skripte exportiert wird (?) Die Geschichte ist insgesamt nicht ganz durchsichtig, insbesondere was die glibc Implementierung angeht. Generell arbeite ich daher lieber mit character classes wie [[:upper:]]. Hier ist ein Thread, in dem das Thema (weiter unten, ab Posting 9) diskutiert wird http://groups.google.ch/groups?hl=delr=threadm=9qd9ot0e1b4cpboupq7p78ch9o4ub6vcb1%404ax.com inklusive Beschimpfungen, aber leider auch nicht erschpfend :) Fr letztendlichen Durchblick ist wohl das Verstndnis von /usr/share/i18n/locales/iso14651_t1 ntig ... -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
On Tue, Mar 22, 2005 at 01:28:20AM +0100, Michelle Konzack wrote: Fehlt nur noch das Problem, warum $HOME/devel/bash/[A-Z]*.tmp in der BASH funktioniert, während in Scripten alle Dateien gemischt werden, also [A-Z] einfach ignoriert wird. Das liegt daran, dass die bash imho kaputt ist. Siehe http://www.linuxhaters.de/Shell D.h sie verhaelt sich nur den Umgebungsvariablen entsprechend, wenn die Umgebungsvariablen beim Start der Bash schon gesetzt sind. /GM -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Eigenatiges BASH problem...
On Tue, 2005-03-22 at 02:05 +0100, Gerhard Meier wrote: D.h sie verhaelt sich nur den Umgebungsvariablen entsprechend, wenn die Umgebungsvariablen beim Start der Bash schon gesetzt sind. Kann ich nicht besttigen: [EMAIL PROTECTED]:~/tmp$ ls -l total 0 -rw-r--r-- 1 bhertz bhertz 0 2005-03-22 02:40 a -rw-r--r-- 1 bhertz bhertz 0 2005-03-22 02:40 A -rw-r--r-- 1 bhertz bhertz 0 2005-03-22 02:40 z -rw-r--r-- 1 bhertz bhertz 0 2005-03-22 02:40 Z [EMAIL PROTECTED]:~/tmp$ locale | grep COLLATE LC_COLLATE=en_US [EMAIL PROTECTED]:~/tmp$ ls [A-Z] A z Z [EMAIL PROTECTED]:~/tmp$ ls [a-z] a A z [EMAIL PROTECTED]:~/tmp$ export LC_COLLATE=C [EMAIL PROTECTED]:~/tmp$ ls [A-Z] A Z [EMAIL PROTECTED]:~/tmp$ ls [a-z] a z -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
