zsh, shell par défaut de macOS : ce qui ne fonctionne plus dans un script écrit pour bash

Ce que c'est

La documentation d'assistance d'Apple indique qu'à partir de macOS 10.15, zsh est le shell de connexion et le shell interactif par défaut des comptes nouvellement créés ; les comptes repris depuis la version 10.14 ou antérieure peuvent encore avoir bash comme shell de connexion (vérification avec dscl . -read ~ UserShell). Un agent qui ouvre une session de type Terminal sur un Mac se trouve donc généralement dans zsh, même si /bin/bash reste disponible pour les scripts qui le désignent dans leur shebang. Ce /bin/bash est figé en version 3.2.57, la dernière publiée sous GPLv2 ; bash 4.0 et les versions suivantes sont sous GPLv3, et Apple ne les livre pas.

Pourquoi c'est important

Les options par défaut de zsh diffèrent de celles de bash et de POSIX sh, au point de modifier le résultat d'un code qui semble pourtant identique :

• Découpage en mots : l'option SH_WORD_SPLIT de zsh, qui selon le manuel zsh entraîne un « field splitting to be performed on unquoted parameter expansions » (découpage en champs des expansions de paramètres non entre guillemets), est désactivée par défaut. Une variable $var non entre guillemets contenant des espaces reste un seul mot dans zsh (en interactif comme en script), alors que bash la découpe ; la sortie d'un $(...) non entre guillemets est en revanche toujours découpée. Du code porté depuis bash qui repose sur ce découpage (un idiome bash/sh de longue date) n'a silencieusement aucun effet dans un zsh standard.
• Tableaux indexés à partir de 1 : par défaut, zsh numérote les éléments d'un tableau à partir de 1 ; l'option KSH_ARRAYS adopte la convention de bash/ksh, que le manuel décrit comme rendant les « array elements... numbered from zero » (éléments numérotés à partir de zéro). Un code qui suppose que arr[0] est le premier élément lit, avec la configuration par défaut de zsh, le mauvais élément ou un élément vide.
• Erreur de glob au lieu d'une chaîne littérale : avec les options par défaut de zsh, un motif qui ne correspond à rien déclenche le comportement NOMATCH, documenté comme affichant « an error, instead of » (une erreur, au lieu de) laisser le motif inchangé ; bash, lui, transmet le motif littéral non développé à la commande, sauf si nullglob/failglob sont activés. Un script qui compte sur le comportement par défaut de bash peut s'interrompre sous zsh pour un simple glob sans correspondance.

Comment l'appliquer

• Placer un shebang explicite (#!/bin/bash ou #!/bin/zsh) dans chaque script au lieu de dépendre du shell de connexion, et exécuter les scripts avec bash script.sh plutôt que de les sourcer dans une session zsh interactive lorsque la sémantique de bash est nécessaire.
• Si un script doit fonctionner correctement sous les deux shells, mettre chaque expansion de paramètre entre guillemets ("$var") afin que les différences de découpage en mots n'aient jamais d'incidence, et éviter toute hypothèse d'indexation à partir de 0, ou bien tester avec les deux interpréteurs.
• Considérer /bin/bash sur macOS comme une version 3.2 héritée : elle est antérieure aux tableaux associatifs, à mapfile et aux autres fonctionnalités de bash 4+ ; si ces fonctionnalités sont nécessaires, installer un bash récent via un gestionnaire de paquets et l'appeler par son chemin complet, car /bin/bash ne sera pas mis à jour.

Pièges

• Partir du principe qu'« un Mac, c'est en gros du Linux avec bash » et coller un script propre à bash, sans shebang, dans le shell par défaut d'un agent sous macOS.
• Tester uniquement dans un zsh interactif personnalisé (avec un .zshrc qui active KSH_ARRAYS ou SH_WORD_SPLIT) et livrer un script qui échoue avec un profil par défaut vierge.
• Oublier que /bin/sh sur macOS est par défaut bash 3.2 en mode POSIX (depuis la version 10.15, il passe par /private/var/select/sh, qui peut être relié à dash ou à zsh), avec des options par défaut différentes à la fois de celles de zsh interactif et de celles de bash en mode normal.