Sujet : bash
-
Simulation et confirmation dans les scripts d'administration : -WhatIf/-Confirm en PowerShell et option --dry-run en shell
PowerShell fournit nativement SupportsShouldProcess, qui dote une fonction personnalisée de vrais commutateurs -WhatIf et -Confirm, reliés au même appel $PSCmdlet.ShouldProcess() que celui des cmdlets intégrées. Les scripts shell n'ont pas d'équivalent natif : une option --dry-run doit être transmise manuellement.
-
Écrire des scripts d'administration idempotents : vérifier avant de modifier, fichiers drop-in et commentaires de repère
Un script d'administration qu'un agent peut relancer après un échec partiel ou une exécution planifiée répétée doit laisser le système dans le même état, qu'il s'exécute une fois ou cinq fois. Trois pratiques le garantissent : vérifier l'état actuel avant toute modification, écrire des fichiers drop-in séparés plutôt que d'éditer des fichiers partagés, et délimiter par des repères tout bloc dont le script est propriétaire.
-
zsh, shell par défaut de macOS : ce qui ne fonctionne plus dans un script écrit pour bash
Depuis macOS 10.15, zsh est le shell de connexion et le shell interactif par défaut ; un script qui suppose le découpage en mots de bash, des tableaux indexés à partir de zéro ou un globbing permissif peut se comporter autrement, voire échouer complètement, dans la session zsh interactive d'un agent sur Mac, avant même de tenir compte de l'ancienneté de /bin/bash.
-
Empêcher l'exécution concurrente d'un script d'administration : flock, lockf et mutex nommé sous Windows
Un script d'administration planifié ou déclenché par un agent, qui peut être relancé avant la fin de l'exécution précédente, exige un verrou et non l'espoir que cela n'arrive pas. flock(1) sous Linux et lockf(1) sous FreeBSD lient un verrou consultatif du noyau à un processus en cours, de sorte qu'il ne devient pas obsolète comme un fichier PID oublié ; sous Windows, un System.Threading.Mutex nommé joue le même rôle.
-
Codes de sortie : un contrat entre les scripts et l'agent qui les appelle
Un agent qui exécute un script et décide de la suite d'après son code de sortie doit pouvoir se fier aux conventions du shell : 0 pour le succès, de petits entiers positifs pour les échecs définis par le script, 126/127 pour une commande impossible à lancer et 128+n pour une mort par signal. Il lui faut aussi pipefail ou PIPESTATUS pour obtenir le vrai code à travers un pipeline.
-
Open source sur IBM i : yum, bash comme shell par défaut et démarrage du démon SSH
La pile open source prise en charge par IBM pour IBM i (Node.js, Python, git, bash, etc.) s'installe sous forme de RPM dans /QOpenSys/pkgs via yum et fournit bash comme shell interactif recommandé. Rien n'est accessible à distance tant que le démon SSH n'a pas été démarré explicitement avec STRTCPSVR *SSHD.
-
Chemins avec espaces et caractères spéciaux dans bash, zsh, PowerShell et cmd
Un même nom de fichier contenant une espace, un caractère générique ou un tiret initial met en défaut une habitude de script différente selon l'interpréteur : expansion sans guillemets dans bash ou zsh, `-Path` interprétant les caractères génériques dans PowerShell, argument sans guillemets dans cmd. Chaque interpréteur offre sa propre option pour désigner un chemin littéral, et `find` et `xargs` doivent utiliser le séparateur nul pour échanger leurs données sans erreur.
Lisible par machine : JSON