Ma solution consiste simplement à appeler l'interprète directement.
Ainsi, par exemple, au lieu d'appeler quelque chose comme :
./foo.sh
Je l'appelle plutôt avec :
bash ./foo.sh
La première forme (appeler './foo.sh') utilise l'interpréteur défini dans la ligne shebang, ce qui vous donne (sans le vouloir) bash 3.x sur OSX (au moins à partir d'OSX Big Sur). Cependant, la seconde forme ignore la ligne shebang, appelant la version de bash que vous avez dans votre PATH. Si votre PATH contient '/usr/local/bin' (ou l'endroit où vous l'avez installé avec brew) avant '/bin', vous exécuterez votre script avec la version de bash désirée sans tenir compte de ce qui se trouve sur la ligne shebang. Ainsi, vous pouvez exécuter votre script avec des fonctionnalités nécessitant bash 4.x+ (comme les tableaux associatifs).
Cela permet de ne pas avoir à changer le script du tout, tout en continuant à exécuter avec la version de bash que vous voulez. A ce jour, vous pouvez obtenir bash 5.x avec brew, alors qu'OSX 11.2 "Big Sur" est toujours livré avec /bin/bash v3.x.
Cette méthodologie est la plus adaptée lorsque vous développez pour plates-formes où '/bin/bash' est une version fiable que vous voulez, mais où vous développez des systèmes de gestion de l'information. sur OSX où '/bin/bash' est 3.x. De cette façon, vous pouvez développer et tester avec la version cible prévue de bash sans modifier la ligne shebang du script d'une manière qui le rendrait moins fiable sur les plates-formes cibles. Pour bash en particulier, je préfère également ne pas utiliser l'astuce #!/usr/bin/env, car cela ajoute de la complexité pour les utilisateurs et peut ajouter de la complexité au support.
Je comprends le point soulevé à propos de la source par rapport au déploiement, et qu'il n'y a pas d'exigence absolue de ne pas autoriser les changements de déploiement aux scripts. Cependant, le fait d'être "autorisé" à modifier les lignes de "shebang" dans le contrôle de version et d'avoir ainsi des changements nécessaires dans les processus de déploiement peut être une grosse affaire, et peut ne pas être quelque chose sur lequel vous avez un quelconque contrôle. Avoir des scripts qui nécessitent un processus de déploiement qui modifie la somme de contrôle du code original réduit l'un des principaux avantages de la "simplicité" de l'utilisation des scripts de l'interpréteur de commandes bash. Si les scripts sont déployés dans le cadre d'un produit plus vaste capable de garantir que les étapes d'installation complexes sont gérées de manière fiable, je n'y verrais pas d'objection. Mais si les scripts sont le produit, il y a beaucoup d'avantages à limiter la complexité du déploiement à "untar à partir d'une archive" (avec une commande prescrite qui gère le chmod +x et l'emplacement de placement/déploiement).
