9.2. Bash (Bourne-Again Shell)
Red Hat Enterprise Linux 6 beinhaltet die Version 4.1 von Bash als Standard-Shell. Dieser Abschnitt beschreibt Probleme mit der Kompatibilität, die diese Version im Vergleich zu vorherigen Versionen einführt.
- Mit Bash-4.0 und höher ist es nun möglich, Prozess-Substitutionskonstrukte unverändert durch Klammererweiterung passieren zu lassen, so dass jede Erweiterung des Inhalts separat angegeben und jede Prozess-Substitution separat eingegeben werden muss.
- Mit Bash-4.0 und aktueller ist es nun möglich, dass SIGCHILD das wait-Builtin unterbricht, so wie es Posix definiert, so dass die SIGCHILD-Trap nicht mehr immer pro Child aufgerufen wird, wenn `wait' verwendet wird, um auf alle Children-Prozesse zu warten.
- Nachdem Bash-4.0 und aktueller nun Posix-Regeln beim Finden des Closing-Delimiter einer $() Befehlssubstitution befolgt, verhält die Shell sich nicht wie frühere Versionen, sondern sammelt mehr Syntax- und Parsing-Fehler, bevor sie eine Sub-Shell zur Evaluierung der Befehlssubstitution ausführt.
- Der programmierbare Code zur Vervollständigung verwendet dasselbe Set Delimiter-Zeichen wie readline beim Aufteilen der Kommandozeile in Words, anstelle von einem Set Meta-Zeichen. Daher sollte die programmierbare Vervollständigung und readline konsistenter sein.
- Wenn das Read-Builtin zeitlich ausläuft, versucht es, jede gelesene Eingabe speziellen Variablen zuzuweisen. Dies führt auch dazu, dass Variablen auf den leeren String
- In Bash-4.0 und aktueller agiert die Shell so, als habe sie den Interrupt erhalten, wenn einer der Befehle in einer Pipeline mit einem SIGINT bei der Ausführung einer Befehlsliste gewaltsam beendet wurde.
- Mit Bash-4.0 und aktueller ändert sich das Verhalten der Option
set -e, so dass die Shell sich beendet, wenn eine Pipeline fehlschlägt (und nicht nur wenn der letzte Befehl in der scheiternden Pipeline ein einzelner Befehl ist). Dies entspricht nicht dem Posix-Standard. An einer Aktualisierung wird derzeit gearbeitet. Das Bash-4.0-Verhalten versucht, den Konsens zum Zeitpunkt des Releases wiederzugeben. - Mit Bash-4.0 und aktueller wird ein Posix Modus-Bug behoben, der das
. (source)-Builtin veranlasste, das aktuelle Verzeichnis nach dessen Dateinamenargumenten zu durchsuchen, auch wenn"."nicht Teil des System-PATH ist. Laut Posix sollte die Shell in diesem Fall in der PWD-Variable nachsehen. - Bash-4.1 verwendet beim Vergleich von Strings das aktuelle Gebietsschema und verwendet dabei Operatoren zum
[[-Befehl. Dies kann auf das frühere Verhalten zurückgesetzt werden, indem eine dercompatNNshopt-Optionen gesetzt wird.
Reguläre Ausdrücke
Wenn zu den bereits aufgeführten Punkten auch noch das Pattern-Argument zum konditionalen Operator =~ für das Regular-Expression-Matching in Anführungszeichen gesetzt wird, funktioniert das Regular-Expression-Matching ggf. nicht mehr. Dies tritt auf allen Architekturen auf. In Versionen von bash älter als 3.2 wurde der Effekt beim Setzen des Arguments der Regular-Expression in Anführungszeichen zum =~-Operator des [[-Befehls nicht spezifiziert. Der praktische Effekt war, dass das doppelte Setzen von Anführungszeichen beim Pattern-Argument Backslashes erforderte, um spezielle Pattern-Zeichen in Anführungszeichen zu setzen. Dies wirkte sich störend auf die Handhabung von Backslashes bei der in doppelte Anführungszeichen gesetzten Wort-Erweiterung aus und war inkonsistent mit der Art und Weise, wie der == Shell-Pattern Matching-Operator Zeichen in Anführungszeichen behandelte.
In bash Version 3.2 wurde die Shell so verändert, dass Zeichen in String-Argumenten mit einem und doppelten Anführungszeichen intern dem =~-Operator zugewiesen wurde. Dies setzt jedoch die spezielle Bedeutung solcher Zeichen außer Kraft, die für die Verarbeitung von Regular-Expressions (`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^', and `$') wichtig sind und erzwingt, dass diese wortgetreu abgeglichen werden. Dies ist inkonsistent mit der Art und Weise, wie der == Pattern-Matching-Operator Abschnitte seines Pattern-Arguments in Anführungszeichen behandelt.
Die Veränderung der Handhabung von String-Argumenten in Anführungszeichen führte zu diversen Problemen. Ein Hauptproblem waren Leerzeichen in Pattern-Argumenten und das unterschiedliche Behandeln von Strings in Anführungszeichen zwischen bash 3.1 und bash 3.2. Beide Probleme können behoben werden, indem eine Shell-Variable zur Speicherung des Patterns verwendet wird. Da das Aufteilen von Worten bei der Erweiterung von Shell-Variablen in allen Operanden des [[-Befehls nicht durchgeführt wird, bietet dies die Fähigkeit, Patterns nach Wunsch beim Zuweisen der Variable in Anführungszeichen zu setzen und dann die Werte in einen einzelnen String zu erweitern, der Leerzeichen enthalten kann. Das erste Problem kann durch die Verwendung von Backslashes oder jeder anderen Möglichkeit gelöst werden, Leerzeichen in Patterns mit Fluchtsymbolen zu versehen.
Bash 4.0 führt das Konzept eines Kompatibilitätslevels ein, das durch diverse Optionen für das shopt-Builtin kontrolliert wird. Falls die Option compat31 aktiviert ist, fällt Bash in Bezug auf das Setzen der rechten Seite des =~-Operators auf das Verhalten in 3.1 zurück.
