Sven Mueller <[EMAIL PROTECTED]> writes: >> Vergiss mal das unset LC_ALL. > Das �ndert nichts. LC_COLLATE hat Vorrang vor LC_ALL&LC_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.
