Sujet : scripting
-
Gestion des erreurs PowerShell dans les scripts d'administration : erreurs terminales, $ErrorActionPreference et $LASTEXITCODE
PowerShell distingue deux classes d'erreurs aux comportements différents dans un script : les erreurs terminales, que try/catch permet d'intercepter, et les erreurs non terminales, que seuls $ErrorActionPreference ou -ErrorAction peuvent transformer en arrêt. Une troisième classe, les échecs des exécutables natifs, ne suit aucune de ces deux voies, sauf si $PSNativeCommandUseErrorActionPreference est activée (PowerShell 7.4+, expérimentale en 7.3).
-
Écrire un script POSIX sh portable entre Linux, BSD, macOS et AIX
Un script censé s'exécuter sans modification avec dash sous Debian, bash utilisé comme sh sous Linux, FreeBSD, macOS et AIX doit rester dans le cadre du Shell Command Language POSIX et éviter les options d'outils propres à GNU ; checkbashisms et une courte liste de différences entre commandes GNU et BSD permettent de repérer l'essentiel des problèmes.
-
Journalisation depuis les scripts d'administration : logger et systemd-cat sous Linux, Write-EventLog/New-WinEvent et Start-Transcript sous Windows
Chaque plateforme permet d'envoyer la sortie d'un script d'administration à un emplacement où une personne ou un autre outil la retrouvera plus tard, ce qui est distinct d'une simple écriture sur stdout : logger(1) ou systemd-cat vers le journal système sous Linux, le journal d'événements Windows via Write-EventLog (Windows PowerShell 5.1 uniquement) ou New-WinEvent, et Start-Transcript pour une capture brute de session. Aucun de ces mécanismes ne doit jamais recevoir de secret.
-
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.
-
Exécuter une commande sous un autre utilisateur depuis un script : sudo -u, runuser, su -c et -Credential de PowerShell
sudo -u, runuser et su -c exécutent une commande avec un autre identifiant d'utilisateur et de groupe, mais diffèrent selon qu'ils exigent ou non le mot de passe de la cible, qu'ils chargent ou non un environnement de connexion, et selon les personnes autorisées à les appeler ; Start-Process et les cmdlets de remoting de PowerShell utilisent un objet -Credential, et aucun de ces outils ne doit recevoir de mot de passe par un tube ou un argument de ligne de commande.
-
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.
-
Utiliser SMIT comme générateur de commandes plutôt que comme système de menus
Les menus smit/smitty exécutent au final des commandes AIX ordinaires, et l'outil permet de voir lesquelles : la fenêtre de sortie affiche la commande construite, et smit.log/smit.script enregistrent chaque commande avec ses options exactes et un horodatage. Lire smit.script après une tâche réalisée par les menus est un moyen rapide de découvrir la commande non interactive équivalente.
-
Pièges de cmd.exe et des scripts batch : moment d'évaluation de %ERRORLEVEL%, expansion différée et échappement avec le caret
Les fichiers batch subsistent dans des installateurs, des tâches planifiées héritées et des outils de fournisseurs. %ERRORLEVEL% est développé à l'analyse de la ligne et peut donc renvoyer une valeur périmée, l'expansion différée change ce comportement, et le caret est le caractère d'échappement que la plupart du code batch généré par des agents gère mal du premier coup.
-
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.
Lisible par machine : JSON