9.2. Bash (Bourne-Again Shell)
- Bash-4.0 et ses versions plus récentes autorisent maintenant les constructions de substitution de processus à être passés en restant inchangées à travers l'expansion d'accolades. Ainsi, toute expansion de contenu devra être spécifiée séparément, et chaque substitution de processus devra être saisie séparément.
- Bash-4.0 et ses versions plus récentes autorisent maintenant les interruptions de l'attente intégrée par SIGCHLD, comme Posix le spécifie, ainsi l'interruption SIGCHLD n'est plus invoquée une fois par enfant sortant si vous utilisez `wait' pour attendre tous les enfants.
- Puisque Bash-4.0 et ses versions plus récentes suivent maintenant les règles Posix pour trouver les délimiteurs de fin d'une substitution de commande $(), il ne se comportera pas comme ses anciennes versions le faisaient, mais il trouvera davantage d'erreurs de syntaxe et d'analyse avant de générer un subshell pour évaluer la substitution de commande.
- Le code de fin programmable utilise le même ensemble de caractères délimitant que readline lorsqu'il décompose la ligne de commande en mots plutôt que l'ensemble des métacaractères shells ; ainsi, la fin programmable et readline sont plus consistants.
- Lorsque le délai d'attente de la lecture intégrée expire, il tente d'assigner n'importe quelle entrée de lecture aux variables spécifiées, ce qui cause aux variables d'être paramétrées sur une chaîne vide s'il n'y a pas eu assez d'entrée. Les versions précédentes annulaient la lecture des caractères.
- Dans Bash-4.0 et ses versions plus récentes, lorsque l'une des commandes dans un pipeline est supprimé (killed) par un SIGINT lors de l'exécution d'une liste de commandes, le shell agit comme s'il avait reçu l'interruption.
- Bash-4.0 et ses versions plus récentes modifient la gestion de l'option
set -e
de manière à ce que le shell se ferme si un pipeline échoue (et non pas seulement si la dernière commande dans le pipeline échouant est une simple commande). Ceci est contraire à ce qui est spécifié par Posix. Des traveaux sont en cours de réalisation pour mettre à jour cette portion du standard ; Le comportement de Bash-4.0 tente de capturer le consensus au moment de la publication. - Bash-4.0 et ses versions plus récentes corrige un bogue de mode Posix qui faisait que
. (source)
cherchait l'argument du nom de fichier dans le répertoire actuel, même si"."
ne se trouve pas dans le PATH (chemin) du système. Dans ce cas, Posix dira que le shell ne devrait pas rechercher dans la variable PWD. - Bash-4.1 utilise la locale actuelle lors de la comparaison de chaînes utilisant des opérateurs sur la commande
[[
. Ceci peut être remplacé par le comportement précédent en paramétrant l'une des options shoptcompatNN
.
En plus des points qui ont déjà été répertoriés, citer l'argument de schéma sur l'expression régulière correspondant à l'opérateur conditionnel =~ peut causer à la correspondance regexp d'arrêter de fonctionner. Ceci se produit sur toutes les architectures. Dans les versions de bash antérieures à 3.2, les effets résultant de la citation de l'argument d'expression régulière sur l'opérateur =~ de la commande[[ n'était pas spécifié. L'effet pratique était qu'une double citation de l'argument du schéma nécessitait des barres obliques inverses pour citer les caractères de schémas spéciaux, qui interféraient avec les processus de barres obliques inverses effectués par l'expansion de mots à double citation et qui étaient inconsistants avec la manière dont l'opérateur de correspondance de schémas shell == traitait les caractères cités.