Comment fonctionne L'interpréteur de commandes Windows (CMD.EXE) analyser les scripts?

j'ai réalisé de nombreuses expériences pour étudier la grammaire des scripts de traitement par lots. J'ai aussi étudié les différences entre le mode par lots et le mode en ligne de commande.

Analyseur De Ligne De Lots:

le traitement d'une ligne de code dans un fichier de lot comporte plusieurs phases.

voici un bref aperçu des différentes phases:

Phase 0) Lire La Ligne:

Phase 1) Pourcentage D'Expansion:

Phase 1.5) Supprimer <CR> : supprimer tous les caractères de retour de chariot (0x0D)

Phase 2) traiter les caractères spéciaux, tokenize, et construire un bloc de commande en cache: c'est un processus complexe qui est affecté par des choses telles que les citations, les caractères spéciaux, les délimiteurs de jeton, et les échappées de caret.

Phase 3) faire écho à la(AUX) Commande (s) parsée (s) seulement si le bloc de commande n'a pas commencé par @ , et que L'écho était activé au début de l'étape précédente.

Phase 4) pour %X expansion variable: seulement si A for command est actif et que les commandes après DO sont en cours de traitement.

Phase 5) Expansion retardée: seulement si l'expansion retardée est activé

Phase 5.3) traitement des conduites: seulement si les commandes sont de chaque côté d'une conduite

Phase 5.5) Execute Redirection:

Phase 6) Traitement des appels/doublage Caret: seulement si le token de commande est appel

Phase 7) Exécuter: la commande est exécutée

---

et voici les détails pour chaque phase:

noter que les phases décrites ci-dessous ne sont qu'un modèle du fonctionnement de l'analyseur par lots. La réelle cmd.exe internes peuvent ne pas tenir compte de ces phases. Mais ce modèle est efficace pour prédire le comportement des scripts batch.

Phase 0) lire la ligne: Lire la ligne d'entrée.

• en lisant une ligne à être analysée comme une commande, <Ctrl-Z> (0x1A) est lu comme <LF> (LineFeed 0x0A)
• quand GOTO ou appel lit des lignes lors de la recherche d'un: étiquette, <Ctrl-Z> , est traité comme lui - même-il est pas converti en <LF>

Phase 1) Pourcentage D'Expansion:

• A le double %% est remplacé par un simple %
• l'Expansion de l'argument variables ( %1 , %2 , etc.)
• Expansion de %var% , si var n'existe pas le remplacer par rien
• pour une explication complète, lisez la première moitié de ceci de dbenham même fil: pourcentage de Phase

Phase 1.5) Supprimer <CR> : supprimer tous les retours de chariot (0x0D) de la ligne

Phase 2) traiter les caractères spéciaux, tokenize, et construire un bloc de commande en cache: c'est un processus complexe qui est affecté par des choses telles que les citations, les caractères spéciaux, les délimiteurs de jeton, et les échappées de caret. Ce qui suit est une approximation de ce processus.

il y a certains concepts qui sont important tout au long de cette phase.

• Un jeton est simplement une chaîne de caractères qui est traité comme une unité.
Les Tokens
• sont séparés par des délimiteurs de tokens. Les délimiteurs de token standard sont: <space> <tab> ; , = <0x0B> <0x0C> et <0xFF>
  
  Consécutives jeton délimiteurs sont traités comme un seul - il n'y a aucun vide jetons entre jeton délimiteurs
• il n'y a pas de délimiteur de token dans une chaîne Citée. La chaîne Citée entière est toujours traitée comme une partie d'un seul token. Un jeton peut être composé d'une combinaison de chaînes de caractères citées et de caractères non cités.

les caractères suivants peuvent avoir une signification particulière dans cette phase, selon le contexte: ^ ( @ & | < > <LF> <space> <tab> ; , = <0x0B> <0x0C> <0xFF>

regardez chaque caractère de gauche à droite:

• S'il s'agit d'un caret ( ^ ), le caractère suivant est échappé, et le caret échappant est enlevé. Les caractères échappés perdent toute signification spéciale (sauf <LF> ).
• Si c'est une citation ( " ), bascule le drapeau de citation. Si le drapeau de citation est actif, alors seulement " et <LF> sont spéciaux. Tous les autres caractères perdent leur signification particulière jusqu'à ce que la citation suivante bascule le drapeau de citation. Il n'est pas possible d'échapper à la citation de clôture. Tous ces personnages sont toujours dans le même jeton.
• <LF> éteint toujours le drapeau de citation. Les autres comportements varient selon le contexte, mais les citations ne modifient jamais le comportement de <LF> .
  • échappé <LF>
    • <LF> est dépouillé
    • le personnage suivant s'est échappé. Si à la fin du tampon de ligne, la ligne suivante est lue et ajoutée à la ligne courante avant d'échapper au caractère suivant. Si le caractère suivant est <LF> , il est traité comme un caractère littéral, ce qui signifie que ce processus n'est pas récursif.
  • sans escapade <LF> non compris parenthèse
    • <LF> est dépouillé et l'analyse de la ligne courante est terminée.
    • tous les caractères restants dans le tampon de ligne sont simplement ignorés.
  • sans échappement <LF> dans une DANS les parenthèses bloc
    • <LF> est converti en un <space>
    • si à la fin du tampon de ligne, alors la ligne suivante est lire et annexé à la présente.
  • sans échappement <LF> à l'intérieur d'un bloc de commandes entre parenthèses
    • <LF> est converti en <LF><space> , et le <space> est traité comme faisant partie de la ligne suivante du bloc de commande.
    • si à la fin du tampon de ligne, alors la ligne suivante est lue et ajoutée à l'espace.
• si c'est l'un des caractères spéciaux & | < ou > , séparez la ligne à ce point afin de manipuler les pipes, commande la concaténation, et la redirection.
  • dans le cas d'un tuyau ( | ), chaque côté est une commande séparée (ou bloc de commande) qui obtient un traitement spécial dans la phase 5.3
  • dans le cas de & , && , ou || commande concaténation, chaque côté de la concaténation est traité comme une commande séparée.
  • dans le cas de < , << , > , ou >> redirection, la clause de redirection est analysée, temporairement supprimée, puis ajoutée à la fin de la commande courante. Une clause de redirection se compose d'un chiffre optionnel de gestion de fichier, de l'opérateur de redirection et du jeton de destination de redirection.
    • Si le jeton qui précède l'opérateur de redirection est un seul chiffre, puis le chiffre spécifie le gestionnaire de fichier à rediriger. Si le jeton de la poignée n'est pas trouvé, alors la redirection de sortie par défaut est 1 (stdout), et la redirection d'entrée par défaut est 0 (stdin).
• si le tout premier token pour cette commande (avant de déplacer la redirection vers la fin) commence par @ , alors le @ a un sens particulier. ( @ n'est pas dans aucun autre contexte)
  • La spéciale @ est supprimé.
  • si ECHO est activé, alors cette commande, ainsi que toute commande concaténée suivante sur cette ligne, sont exclues de l'écho de phase 3. Si le @ est avant une ouverture ( , alors le bloc entier entre parenthèses est exclu de l'écho de phase 3.
• instructions sur plusieurs lignes):
  • si l'analyseur ne cherche pas un jeton de commande, alors ( n'est pas spécial.
  • si l'analyseur cherche un jeton de commande et trouve ( , alors démarrez une nouvelle instruction composée et incrémentez le compteur de parenthèses
  • si le compteur de parenthèses est > 0 alors ) termine l'énoncé composé et décrète le compteur de parenthèses.
  • si la fin de ligne est atteinte et que le compteur de parenthèses est > 0, alors la ligne suivante sera ajoutée à la déclaration composée (recommence avec la phase 0)
  • si le compteur de parenthèses est 0 et que l'analyseur cherche une commande, alors ) fonctionne de la même façon qu'une instruction REM pourvu qu'elle soit immédiatement suivie d'un délimiteur de token, d'un caractère spécial, d'une nouvelle ligne ou d'une fin de fichier
    • tous les caractères spéciaux perdent leur sens sauf ^ (la concaténation de ligne est possible)
    • une fois la fin de la ligne logique atteinte, toute la "commande" est écartée.
• chaque commande est divisée en une série de jetons. Le premier token est toujours traité comme un token de commande (après que le spécial @ a été enlevé et que la redirection a été déplacée à la fin).
  • à la tête de les délimiteurs de token avant la commande token sont dépouillés
  • lors de l'analyse du token de commande, ( fonctionne comme un délimiteur de token de commande, en plus des délimiteurs de token standard
  • la manipulation des jetons suivants dépend de la commande.
• la plupart des commandes concatèrent simplement tous les arguments après la commande token en un seul token argument. Tous les délimiteurs de token d'arguments sont conservés. Les options d'Argument ne sont généralement pas analysées avant la phase 7.
• trois commandes reçoivent un traitement spécial-si, pour, et REM
  • s'il est divisé en deux ou trois parties distinctes qui sont traitées indépendamment. Une erreur de syntaxe dans la construction du SI résultera en une erreur de syntaxe fatale.
    • l'opération de comparaison est la commande réelle qui s'écoule tout au long de la phase 7
      • tous Si les options sont entièrement analysées dans la phase 2.
      • les délimiteurs de jeton consécutifs s'effondrent dans un seul espace.
      • selon l'opérateur de comparaison, il y aura un ou deux jetons de valeur qui seront identifiés.
    • le vrai bloc de commande est l'ensemble des commandes après la condition, et est divisé comme tout autre bloc de commande. Si ELSE doit être utilisé, alors le bloc vrai doit être mis entre parenthèses.
    • le bloc de fausses commandes optionnel est l'ensemble des commandes après ELSE. Encore une fois, ce bloc de commande est analysé normalement.
    • les blocs True et False ne s'écoulent pas automatiquement dans les phases suivantes. Leur traitement ultérieur est contrôlé par la phase 7.
  • pour est divisé en deux après le DO. Une erreur de syntaxe dans la construction entraînera une fatale erreur de syntaxe.
    • Le passage à travers N'est la POUR l'itération de commande que les flux tout au long de la phase 7
      • toutes les options sont entièrement analysées dans la phase 2.
      • la clause entre parenthèses traite <LF> comme <space> . Après la clause est analysée, tous les jetons sont concaténées pour former un seul jeton.
      • les délimiteurs de jeton consécutifs, Non escapades/non cotées, s'effondrent en un seul espace tout au long de la commande pour DO.
    • la partie après DO est un bloc de commande qui est divisé normalement. Le traitement ultérieur du bloc de commande DO est contrôlé par l'itération de la phase 7.
  Le REM
  • détecté en phase 2 est traité de façon radicalement différente de toutes les autres commandes.
    • un seul argument est parsé-l'analyseur ignore caractères après le premier jeton argument.
    • S'il n'y a qu'un seul jeton d'argument qui se termine par un ^ non enregistré qui termine la ligne, alors le jeton d'argument est jeté, et la ligne suivante est analysée et ajoutée au REM. Cela se répète jusqu'à ce qu'il y ait plus d'un jeton, ou le dernier caractère n'est pas ^ .
    • la commande REM peut apparaître en sortie de phase 3, mais la commande n'est jamais exécutée, et l'original le texte de l'argument est repris - les caractères échappés ne sont pas supprimés.
• si la commande token commence par : , et qu'il s'agit du premier tour de la phase 2 (pas de redémarrage en raison de L'appel de la phase 6) alors
  • le jeton est normalement traité comme une étiquette non coupée .
    • le reste de La ligne est analysée, cependant ) , < , > , & et | n'ont plus de signification particulière. L'ensemble du reste de la ligne est considéré comme faisant partie de l'étiquette de "commande".
    • le ^ continue d'être spécial, ce qui signifie que la continuation de la ligne peut être utilisée pour ajouter la ligne suivante à l'étiquette.
    • An Unexécuted Label dans un bloc entre parenthèses résultera en une erreur de syntaxe fatale à moins qu'elle ne soit immédiatement suivi d'une commande ou étiquette exécutée sur la ligne suivante.
      • notez que ( n'a plus de signification particulière pour la première commande qui suit le étiquette Inexécutée dans ce contexte.
    • la commande est annulée après l'analyse des étiquettes. Les phases suivantes n'ont pas lieu pour le label
  • il y a trois exceptions qui peuvent faire en sorte qu'une étiquette trouvée dans la phase 2 soit traitée comme une étiquette exécutée qui continue de passer par la phase 7.
    • il y a une redirection qui précède le jeton d'étiquette, et il y a une | pipe ou & , && , ou || concaténation de commande sur la ligne.
    • il y a une redirection qui précède le token d'étiquette, et le la commande est dans un bloc entre parenthèses.
    • le jeton d'étiquette est la toute première commande sur une ligne à l'intérieur d'un bloc entre parenthèses, et la ligne ci-dessus s'est terminée par un étiquette Inexécutée .
  • ce qui suit se produit lorsqu'un étiquette exécutée est découvert dans la phase 2
    • l'étiquette, ses arguments et sa redirection sont tous exclus de toute sortie echo en phase 3
    • toutes les commandes subséquentes concaténées sur la ligne sont entièrement parsées et exécutées.
  • pour plus d'informations sur Etiquettes exécutées vs. Etiquettes non éditées , voir https://www.dostips.com/forum/viewtopic.php?f=3&t=3803&p=55405#p55405

Phase 3) faire écho à la(AUX) Commande (s) parsée (s) seulement si le bloc de commande n'a pas commencé par @ , et que L'écho était activé au début de l'étape précédente.

Phase 4) pour %X expansion variable: seulement si A for command est actif et que les commandes après DO sont en cours de traitement.

• à ce stade, la phase 1 du traitement par lots aura déjà converti un Pour variable comme %%X en %X . La ligne de commande a des règles de pourcentage d'expansion différentes pour la phase 1. C'est la raison pour laquelle les lignes de commande utilisent %X alors que les fichiers par lots utilisent %%X pour les variables FOR.
• pour les noms de variables sont sensibles à la casse, mais ~modifiers ne sont pas sensibles à la casse.
• ~modifiers ont priorité sur les noms variables. Si un caractère suivant ~ est à la fois un modificateur et un valide pour le nom de la variable, et il existe un caractère subséquent qui est actif pour le nom de la variable, alors le caractère est interprété comme un modificateur.
• POUR les noms de variables sont globales, mais seulement dans le contexte d'une clause. Si une routine est appelée à l'intérieur d'une clause FOR DO, alors les variables FOR ne sont pas développées à l'intérieur de la routine appelée. Mais si la routine a son propre pour commander, alors tous " actuellement défini pour les variables sont accessibles aux commandes DO internes.
• pour les noms de variables peut être réutilisé dans les FORs imbriqués. La valeur de FOR intérieure a priorité, mais une fois que la valeur de FOR intérieure se ferme, la valeur de FOR extérieure est restaurée.
• si ECHO était activé au début de cette phase, alors la phase 3) est répétée pour montrer les commandes parsed DO après que les variables FOR ont été étendues.

- - - - à partir de ce point, chaque commande identifiée dans la phase 2 est traitée séparément.

---- Les Phases 5 à 7 sont terminées pour une commande avant de passer à la suivante.

Phase 5) Expansion retardée: seulement si l'expansion retardée est en marche

• si la commande se trouve à l'intérieur d'un bloc entre parenthèses de chaque côté d'un tuyau, alors sauter cette étape.
• chaque token pour une commande est analysé pour une expansion retardée indépendamment.
  • la plupart des commandes analysent deux tokens ou plus - le token de commande, le token d'arguments et chaque token de destination de redirection.
  • la commande FOR utilise le jeton in clause uniquement.
  • la commande IF analyse les valeurs de comparaison seulement - soit une ou deux, selon l'opérateur de comparaison.
• pour chaque jeton parsé, Vérifiez d'abord s'il contient un ! . Si ce n'est pas le cas, le jeton n'est pas analysé - important pour les caractères ^ . Si le jeton contient ! , scannez chaque caractère de gauche à droite:
  • si c'est un caret ( ^ ) le caractère suivant n'a pas de signification particulière, le caret lui-même est enlevé
  • s'il s'agit d'un point d'exclamation, prochain point d'exclamation (les carets ne sont plus observés), passez à la valeur de la variable.
    • ouverture consécutive ! sont réunis en un seul !
    • Tout ce qui reste ! qui ne peut pas être apparié est enlevé
  • Important: à cette phase, les guillemets et autres caractères spéciaux sont ignorés
  • L'expansion de vars à ce stade est "safe", car les caractères spéciaux ne sont plus détectés (même <CR> ou <LF> )
  • pour une explication plus complète, lisez la 2ème moitié de ceci de dbenham même thread - Point d'Exclamation Phase
  • il y a des cas extrêmes où ces règles semblent échouer:
    
    Voir l'expansion retardée échoue dans certains cas

Phase 5.3) traitement des tubes: seulement si les commandes sont de chaque côté d'un tube

Chaque côté du tube est traité indépendamment.

• s'il s'agit d'un bloc de commande entre parenthèses, alors tous les <LF> avec une commande avant et après sont convertis en <space>& . Les autres <LF> sont dénudés.
• la commande (ou bloc de commande) est exécutée asynchrone dans un nouveau cmd.exe fil via
  
  %comspec% /S /D /c" commandBlock" . Cela signifie que le bloc de commande obtient un redémarrage de phase, mais cette fois en mode ligne de commande.
• c'est la fin du traitement pour les commandes pipe.
• pour plus d'information sur la façon dont les pipes sont analysées et traitées, regardez cette question et les réponses: pourquoi l'expansion retardée échoue-t-elle lorsque à l'intérieur d'un les canalisations de bloc de code?

Phase 5.5) exécution Redirection: toute redirection découverte dans la phase 2 est maintenant exécutée.

• les résultats des phases 4 et 5 peuvent affecter la redirection qui a été découverte dans la phase 2.
• si la redirection échoue, alors le reste de la commande est avorté. notez que la redirection ratée ne mettre ERRORLEVEL à 1 sauf si || est utilisé .

Phase 6) Traitement des appels/doublage Caret: seulement si le token de commande est appel, ou si le texte avant le premier délimiteur de token standard existant est appel. Si L'appel est analysé à partir d'un token de commande plus grand, alors la portion inutilisée est préprogrammée sur le token des arguments avant de continuer.

• Analyse les arguments jeton pour un sans la mention /? . S'il se trouve n'importe où dans les jetons, alors abandonnez la phase 6 et passez à la Phase 7, où L'aide pour L'appel sera imprimée.
• supprimer le premier CALL , de sorte que les appels multiples peuvent être empilés
• Double tous les soins
• redémarrez les phases 1, 1.5, et 2, mais ne continuez pas à la phase 3
  • tout Double caret est ramené à un seul tant qu'il n'est pas cité. Mais malheureusement, les carets Cités restent doublés.
  • le bloc de commande en cache a déjà été préparé lors du premier tour de la phase 2. Tant de tâches de la phase 2 sont modifiées
    • toute nouvelle redirection non cotée et non enregistrée qui n'a pas été détectée dans le premier tour de la phase 2 est détectée, mais elle est supprimée (y compris le nom du fichier) sans effectuer réellement la redirection
    • toute nouvelle caret non fractionné et non escamoté à l'extrémité de la ligne est enlevé sans effectuer la continuation de la ligne
    • l'appel est interrompu sans erreur si l'un des éléments suivants est détecté
      • ou |
      "
      • le jeton de commande qui en résulte commence par ( 15192480920"
      • le tout premier jeton après L'appel enlevé a commencé avec @
    • si la commande résultante est apparemment valide si OU POUR, alors l'exécution échouera avec une erreur indiquant que IF ou FOR n'est pas reconnu comme une commande interne ou externe.
    • bien sûr, l'appel n'est pas annulé dans ce 2e tour de phase 2 si le jeton de commande qui en résulte est une étiquette commençant par : .
  • il y a des cas extrêmes où ces règles échouent:
    
    Voir examen des doublures avec appel "15192700920
• si le jeton de commande qui en résulte est un appel, redémarrez alors la Phase 6 (répète jusqu'à ce qu'il N'y ait plus d'appel)
• si la commande token résultante est un script de lot ou un :label, alors l'exécution de l'appel est entièrement gérée par le reste de la Phase 6.
  • appuyez sur la position courante du fichier de script de lot sur la pile d'appels pour que l'exécution puisse reprendre à partir de la position correcte lorsque l'appel est terminé.
  • installer le %0, %1, %2, ...% N et % * jetons d'argument pour L'appel, en utilisant tous les jetons résultants
  • si la commande token est une étiquette qui commence par : , alors
    • Redémarrer La Phase 5. Cela peut avoir un impact sur ce que :label est appelé. Mais puisque le %0 etc. jeton ont déjà été mis en place, il ne modifiera pas les arguments qui sont passés à la routine appelée.
    • exécute Goto label pour positionner le pointeur de fichier au début du sous-programme (ignore tous les autres tokens qui peuvent suivre l'étiquette:) voir la Phase 7 pour les règles sur le fonctionnement de GOTO.
      • si le token :label est manquant, ou si le label :n'est pas trouvé, alors la pile d'appels est immédiatement activée pour restaurer la position du fichier sauvegardé, et l'appel est interrompu.
      • Si l'étiquette contient des /?, puis GOTO help est imprimé au lieu de chercher l'étiquette:. Le pointeur de fichier ne bouge pas, de sorte que le code après L'appel est exécuté deux fois, une fois dans le contexte de l'appel, puis de nouveau après le retour de l'appel. Voir pourquoi CALL imprime le message D'aide GOTO dans ce script?Et pourquoi les ordres après ça sont exécutés deux fois? pour plus d'info.
  • transférer le contrôle au script de lot spécifié.
  • L'exécution du Call :label ou du script continue jusqu'à ce que EXIT /B ou end-of-file soit atteint, à ce moment la pile D'appels est activée et l'exécution reprend à partir de la position du fichier sauvegardé.
    
    La Phase 7 n'est pas exécutée pour les scripts appelés ou les étiquettes:.
• autrement le résultat de la phase 6 tombe dans dans phase 7 pour l'exécution.

Phase 7) Exécuter: la commande est exécutée

• 7.1 - exécuter la commande interne - si la commande token est citée, sauter cette étape. Sinon, tentez d'analyser une commande interne et exécutez.
  • les tests suivants sont effectués pour déterminer si un jeton de commande non coté représente un jeton interne commande:
    • si la commande token correspond exactement à une commande interne, exécutez-la.
    • autrement briser le jeton de commande avant la première occurrence de + / [ ] <space> <tab> , ; ou =
      
      Si le texte précédent est une commande interne, alors rappelez-vous cette commande
      • si vous avez le commandement mode ligne, ou si la commande est à partir d'un bloc entre parenthèses, si le bloc de commande vrai ou faux, pour le bloc de commande DO, ou impliqué dans la concaténation de commande, alors exécuter la commande interne
      • autrement (doit être une commande autonome en mode discontinu) balayer le dossier courant et le chemin pour un .COM,.EXE. ,Chauve-souris, ou .Fichier CMD dont le nom de base correspond au jeton de commande original
        • Si le premier fichier correspondant est un .BAT or .CMD, puis passez à 7.3.exec et exécutez ce script
        • Else (match pas trouvé ou le premier match .EXE or .COM) exécuter la commande interne rappelée
    • autrement briser le jeton de commande avant la première occurrence de . \ ou :
      
      Si le texte précédent n'est pas une commande interne, passez à 7.2
      
      Le reste du texte précédent peut une commande interne. Souvenez-vous de cette commande.
    • briser le jeton de commande avant la première occurrence de + / [ ] <space> <tab> , ; ou =
      
      Si le texte précédent est un chemin vers un fichier existant, allez à 7.2
      
      Sinon, exécutez la commande interne mémorisée.
  • si une commande interne est analysée à partir d'un token de commande plus grand, alors la partie inutilisée du token de commande est incluse dans la liste d'arguments
  • ce n'est pas parce qu'un token de commande est interprété comme une commande interne qu'il s'exécutera avec succès. Chaque commande interne a ses propres règles quant à la façon dont les arguments et les options sont analysés, et quelle syntaxe est permise.
  • toutes les commandes internes imprimeront de l'aide au lieu de remplir leur fonction si /? est détecté. La plupart reconnaissent /? si elle apparaît n'importe où dans les arguments. Mais quelques commandes comme ECHO et SET n'impriment de l'aide que si le premier jeton d'argument commence par /? .
  • SET a une sémantique intéressante:
    • si une commande SET a une citation avant le nom de la variable
      
      set "name=content" ignored --> valeur= content
      
      ensuite, le texte entre le premier signe égal et la dernière citation est utilisé comme contenu (premier signe égal et dernière citation exclue). Texte après la dernière citation est ignoré. S'il n'y a pas de citation après le signe égal, le reste de la ligne est utilisé comme contenu.
    • si une commande SET n'a pas de citation avant le nom
      
      set name="content" not ignored --> valeur= "content" not ignored
      
      ensuite, le reste de la ligne après l'equal est utilisé comme contenu, y compris toutes les citations qui peuvent être présentes.
  • si la comparaison est évaluée, et selon que l'état est vrai ou faux, le bloc de commande dépendant approprié déjà analysé est traité, en commençant par la phase 5.
  • la clause IN DE A FOR command est itérée de façon appropriée.
    • S'il s'agit d'une FOR /F qui itère la sortie d'un bloc de commandes, puis:
      • la clause IN est exécutée dans un nouveau cmd.processus exe via CMD / C.
      • le bloc de commande doit passer par l'ensemble du processus d'analyse une deuxième fois, mais cette fois dans un contexte de ligne de commande
      • ECHO démarre, et l'extension retardée démarre généralement désactivé (dépendant du réglage du registre)
      • tous les changements d'environnement fabriqué par le bloc de commande In clause sera perdu une fois l'enfant cmd.fin du processus exe
    • pour chaque itération:
      • les valeurs variables pour sont définies
      • le bloc de commande DO déjà analysé est alors traité, en commençant par la phase 4.
  • GOTO utilise la logique suivante pour localiser l'étiquette:
    • l'étiquette est analysée à partir du premier jeton d'argument
    • le script est scanné pour la prochaine occurrence de l'étiquette
      • l'analyse commence à partir de la position du fichier actuel
      • si la fin du fichier est atteinte, alors la boucle de balayage de retour au début du fichier et continue au point de départ original.
    • le scan s'arrête au première occurrence de l'étiquette qu'il trouve, et le pointeur de fichier est réglé sur la ligne qui suit immédiatement l'étiquette. L'exécution du script reprend à partir de ce point. Notez qu'un vrai GOTO réussi annulera immédiatement tout bloc de code analysé, y compris pour les boucles.
    • si l'étiquette n'est pas trouvée, ou si le jeton d'étiquette est manquant, alors le GOTO échoue, un message d'erreur est imprimé, et la pile d'appels est activée. Cela fonctionne effectivement comme une sortie / B, sauf les commandes parsées dans le bloc de commande courant qui suivent le GOTO sont encore exécutées, mais dans le contexte de L'appelant (le contexte qui existe après EXIT /B)
    • Voir https://www.dostips.com/forum/viewtopic.php?f=3&t=3803 pour une description plus précise des règles utilisées pour l'analyse des étiquettes.
  • renommer et copier accepte les jokers pour les chemins source et cible. Mais Microsoft le fait. un travail terrible documentant comment les jokers fonctionnent, surtout pour le chemin de la cible. Un jeu utile de règles de Joker peut être trouvé à comment la commande Windows renommer interprète-t-elle les jokers?
• 7.2-exécuter le changement de volume - autrement si la commande token ne commence pas par une citation, est exactement deux caractères de long, et le 2ème caractère est deux points, puis changer le volume
  • tous les tokens d'argument sont ignorés
  • si le volume spécifié par le premier caractère ne peut pas être trouvé, alors avorter avec une erreur
  • un token de commande de :: entraînera toujours une erreur à moins que SUBST ne soit utilisé pour définir un volume pour ::
    
    Si SUBST est utilisé pour définir un volume pour :: , alors le volume sera changé, il ne sera pas traité comme une étiquette.
• 7.3 - Exécuter la commande externe - d'Autre essayer de traiter la commande comme une commande externe.
  • si le 2e caractère du jeton de commande est deux points, alors vérifier le volume spécifié par le 1er caractère peut être trouvé.
    
    Si le volume ne peut pas être trouvé, alors abandonner avec une erreur.
  • si en mode discontinu et que la commande token commence par : , puis passez à 7.4
    
    Notez que si le jeton d'étiquette commence par :: , alors cela ne sera pas atteint parce que l'étape précédente aura avorté avec une erreur à moins que SUBST ne soit utilisé pour définir un volume pour :: .
  • identifiez la commande externe à exécuter.
    • il s'agit d'un processus complexe qui peut impliquer le volume courant, le répertoire courant, la variable chemin, la variable PATHEXT et les associations de fichiers ou.
    • si une commande externe valide ne peut pas être identifiée, alors annuler avec une erreur.
  • si en mode ligne de commande et que le jeton de commande commence par : , alors passez à 7.4
    
    Notez que ceci est rarement atteint parce que l'étape précédente aura avorté avec une erreur à moins que la commande token commence par :: , et que SUBST soit utilisé pour définir un volume pour :: , et la commande token entière est un chemin valide vers une commande externe.
  • 7.3.exec - exécutez la commande externe.
• 7.4 - ignorer une étiquette - ignorer la commande et tous ses arguments si la commande token commence par : .
  
  Les règles énoncées aux articles 7.2 et 7.3 peuvent empêcher une étiquette d'atteindre ce point.

---

Parser En Ligne De Commande:

fonctionne comme le BatchLine-Parser, sauf:

Phase 1) Pourcentage D'Expansion:

• %var% est toujours remplacé par le contenu de var, mais si var n'est pas défini, alors l'expression sera inchangé.
• pas de manipulation spéciale de %% . Si var=contenu, alors %%var%% extension à %content% .

Phase 3) l'Écho de la analysée de commande(s)

• ceci n'est pas effectué après la phase 2. Il n'est effectué qu'après la phase 4 pour le bloc de commande FOR DO.

Phase 5) Expansion retardée: seulement si L'extension retardée est activée

• !var! est encore remplacé par le contenu de var, mais si var n'est pas défini, alors l'expression sera inchangé.

Phase 7) Exécuter La Commande

• les tentatives d'appeler ou de passer à A :label entraînent une erreur.
• même si les étiquettes ne peuvent pas être appelées, une ligne valide peut toujours contenir une étiquette. Comme déjà documenté dans la phase 7, une étiquette exécutée peut entraîner une erreur sous différents scénario.
  • les étiquettes exécutées par lots ne peuvent causer d'erreur que si elles commencent par ::
  • les étiquettes exécutées en ligne de commande entraînent presque toujours une erreur

---

Parsing des valeurs entières

il existe de nombreux contextes dans lesquels le cmd.exe analyse des valeurs entières de chaînes, et les règles sont incompatibles:

• SET /A
• IF
• %var:~n,m% (expansion à substrat variable)
• FOR /F "TOKENS=n"
• FOR /F "SKIP=n"
• FOR /L %%A in (n1 n2 n3)
• EXIT [/B] n

pour plus de détails sur ces règles, voir règles sur la façon de CMD.EXE parses numéros

---

pour quiconque souhaite améliorer ces règles, il y a un sujet de discussion sur le forum DosTips où les questions peuvent être rapportées et des suggestions faites.

j'Espère que ça aide

Jan Erik ( jeb) - auteur Original et découvreur des différentes phases

Dave Benham ( dbenham) - beaucoup plus de contenu et d'édition