9.2. Bash (Bourne-Again Shell)


Red Hat Enterprise Linux 6 inclut la version 4.1 de Bash en tant que shell par défaut. Cette section décrit les problèmes de compatibilité que cette version présente par rapport aux versions précédentes.
  • 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 shopt compatNN.
Expressions régulières

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.

Dans la version 3.2 de bash, le shell a été modifié pour citer de manière interne des caractères dans des arguments de chaîne avec des guillemets simples ou doubles pour l'opérateur =~, qui supprime la signification spéciale des caractères qui pourraient être importants au traitement des expressions régulières (`.', `[', `\', `(', `), `*', `+', `?', `{', `|', `^' et `$') et les force à correspondre de manière littérale. Ceci est consistant avec la manière dont l'opérateur de correspondance de schémas == traite les portions citées de son argument de schéma.
Depuis que le traitement des arguments de citation de chaînes a été modifié, des problèmes sont apparus, le principal problème étant celui de l'espace blanc dans les arguments de schéma et la différence de traitement des chaînes citées entre bash 3.1 et bash 3.2. Ces deux problèmes peuvent être résolus à l'aide d'une variable shell pour conserver le schéma. Puisque la séparation des mots n'est pas effectuée lorsque les variables shell sont étendues à toutes les opérandes de la commande [[, cela vous permettra de citer des schémas comme vous le souhaitez lorsque vous assignez la variable, puis d'étendre les valeurs sur une chaîne unique pouvant contenir de l'espace blanc. Le premier problème peut être résolu en utilisant des barres obliques inversées ou tout autre mécanisme de citation pour éviter l'espace blanc dans les schémas.
Bash 4.0 présente le concept de niveau de compatibilité, contrôlé par plusieurs options sur le shopt intégré. Si l'option compat31 est activée, bash reviendra au comportement de la version 3.1 par rapport aux citations du côté droit de l'opérateur =~.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.