Pièges de cmd.exe et des scripts batch : moment d'évaluation de %ERRORLEVEL%, expansion différée et échappement avec le caret

Ce que c'est

Le modèle de script de cmd.exe est antérieur à PowerShell et suit ses propres règles pour les conditions, l'expansion des variables et l'échappement. Ces règles sont décrites dans la référence Windows Commands de Microsoft, aux pages if et setlocal.

Pourquoi c'est important

• %ERRORLEVEL% et if errorlevel : %ERRORLEVEL% est une expansion ordinaire, comme pour une variable d'environnement, substituée une seule fois, lorsque la ligne est analysée. Dans un bloc if/for sur plusieurs lignes (analysé comme une seule unité), elle peut donc afficher la valeur antérieure à l'exécution du bloc, et non celle qui résulte d'une commande située dans le bloc. if errorlevel N (décrit sur la même page de référence if) teste à la place "is the ERRORLEVEL variable equal to or greater than N" (la variable ERRORLEVEL est-elle supérieure ou égale à N). Ce test est évalué au moment où le if s'exécute et constitue la vérification la plus fiable pour savoir si la commande externe précédente a échoué.
• Expansion différée : setlocal EnableDelayedExpansion active la syntaxe !var!, évaluée à l'exécution effective de chaque ligne et non à l'analyse du bloc (%var% reste évaluée à l'analyse). Sans elle, une boucle qui affecte puis lit la même variable dans un seul bloc ne voit que la valeur d'avant la boucle. La page setlocal de Windows Commands documente cette option. Tant qu'elle est active, un ! littéral dans des données (mot de passe, nom de fichier) est interprété comme une syntaxe d'expansion et disparaît.
• Guillemets et caret : cmd.exe ne reconnaît pas les guillemets simples. Le caret (^) est le caractère d'échappement des caractères que cmd traite de façon spéciale (& | < > ^, ainsi que ( ) à l'intérieur des blocs). Le % s'échappe en le doublant (%%) dans un fichier batch, et non avec un caret. Entre "...", ces caractères perdent leur signification spéciale (un caret y est littéral). L'échec classique consiste à concaténer, dans une ligne sans guillemets, une URL ou un chemin contenant &.
• Appel d'outils cmd.exe ou batch depuis PowerShell : PowerShell réanalyse les arguments. Une ligne cmd.exe /c contenant des guillemets ou des &/| exige donc souvent le jeton d'arrêt d'analyse --%. about_Parsing indique qu'il modifie "the interpretation of all remaining arguments" (l'interprétation de tous les arguments restants) : PowerShell transmet le reste de la ligne tel quel, développe encore les variables d'environnement %NAME%, n'autorise aucune variable PowerShell et s'arrête au prochain saut de ligne ou caractère de pipe. Il est destiné aux commandes natives sous Windows.

Comment l'appliquer

• Privilégier if errorlevel 1 (...) ou if %ERRORLEVEL% neq 0 (...), placés immédiatement après la commande vérifiée, et non dans un bloc qui modifie aussi la valeur (dans ce cas, utiliser !ERRORLEVEL!). if errorlevel 1 signifie « 1 ou plus » et ne détecte donc pas les codes de sortie négatifs, tels que les codes de plantage ; neq 0 couvre tous les échecs.
• Utiliser setlocal EnableDelayedExpansion et !var! partout où une variable est affectée puis relue dans un même bloc entre parenthèses.
• Entourer de guillemets doubles toute valeur susceptible de contenir &, |, <, >, ^ ou des espaces ; lorsque les guillemets sont impossibles, échapper le caractère avec un caret.
• Depuis PowerShell, utiliser cmd.exe /c --% <literal command> pour les lignes de commande contenant des caractères que PowerShell réinterpréterait.

Pièges

• Vérifier %ERRORLEVEL% plus tard qu'immédiatement après la commande : un autre programme externe l'écrase, tandis que de nombreuses commandes internes, comme echo, la laissent inchangée, de sorte qu'une valeur périmée issue d'une commande antérieure peut subsister. Ne jamais faire set ERRORLEVEL=..., qui masque la valeur dynamique.
• Mélanger expansion différée et non différée pour la même variable dans un script : %var% et !var! ne s'accordent alors pas sur la valeur courante.
• Supposer que le batch gère les here-strings ou les tableaux ; une logique complexe est le signe qu'il vaut mieux passer à PowerShell plutôt que d'empiler les astuces for /f.