15.09.2010, aktualisiert am 21.01.2011

25246

Die Geheimnisse des Batch Zeilen Interpreters

Ich habe zu vielen Fragen viele Antworten gelesen, z.B. Wie Zeige ich ein Prozent/Ausrufezeichen/Pipe an?
z.B.

echo %%
echo ^^!
echo ^>
 

Aber da es nie eine befriedigende Antwort gab, WARUM das ganze so und nicht anders ist, habe ich halt selbst geforscht und viele Sachen probiert.

Daraus habe ich diese Theorie entwickelt, die das Verhalten recht gut vorhersagen kann.
Daher scheint das Modell schon recht nah an der Realität zu sein(Was wiederum bedeutet, dass der Entwickler unter Drogen gestanden hat als er cmd.exe programmierte)

Es gibt mehrere Bereiche die ich untersucht habe:

BatchLineParser - Der Parser der einzelne Kommandos oder Blöcke in einer Batchdatei auswertet und ausführt
CmdLineParser - Wie der BatchLineParser aber direkt auf der Kommandozeile (ja die sind unterschiedlich)
LabelParser - Wie ein Sprung Label gesucht wird
CommandBlockCaching - Wie Kommandos oder ganze Blöcke im Speicher gehalten werden
Tokenizer - Wie und wann aus einer Zeile und deren Zeichen einzelne Gruppen von Token gebildet werden.

BatchLine-Parser

Eine Zeile in einer Batchdatei wird in mehreren Phasen interpretiert (Auf der Kommandozeilen ist das Verhalten anders!)

Der Prozess startet immer mit Phase1

Caret = ^ = Zirkumflex = Auslassungszeichen
Klammern = () = Runde Klammern = paranthesis
Anführungszeichen = " = double quote

Phase0(Caret Verdoppelung): Nur wenn die Zeile wiederholt interpretiert wird (mit einem "call")

- Alle Carets werden verdoppelt, auch in Anführungszeichen
Dabei scheinen nur die in Anführungszeichen betroffen zu sein, das liegt aber daran, das die "normalen" Carets in Phase2 wieder verschwinden

Phase1(Prozent): Zeile bis zum Ende einlesen

- Ersetzen aller Prozentausdrücke %var% aber auch %1 mit dem Variabelinhalt, wenn die Variabel nicht existiert ist das Ergebnis leer
- Ein doppeltes %% wird durch ein einfaches % ersetzt
- Bei erweiterten Ausdrücken, und nicht definierter Variabel ersetzt der Teil nach dem Doppelpunkt den Variabelnausdruck "%undef:x=y%" ergibt "x=y"
- <CR> Zeichen werden ersatzlos entfernt, aber erst nach der Expansion der Variablen (Sprich %A<CR>B% sucht die Variabel A<CR>B, nicht AB), kann auch als eigene Phase1.1 betrachtet werden

Phase2(Spezialzeichen ^()"&<>|,;=<space>): Einzelzeichenbetrachtung

- Bei Anführungszeichen wird das String-Flag getoggelt, solange das String-Flag auf 1 steht, werden die anderen Spezialzeichen als normale Zeichen behandelt
- Bei Caret wird das nächste Zeichen immer als normales Zeichen behandelt, das Caret selbst wird entfernt
- Bei Caret am Zeilenende (Multiline) wird die nächste Zeile angehängt, diese durchläuft wieder Phase 1 und 2, das erste Zeichen wird unbedingt als normales Zeichen behandelt (auch <LF>)
- Bei <LF> wird das Parsen sofort abgebrochen
- Bei Klammern wird der Klammerlevel erhöht oder verringert, die Klammer selbst wird dabei entfernt, Ausnahme ein schließende Klammer bei Klammerlevel=0 bleibt bestehen
Öffnende Klammern werden nur an Stellen als Spezialzeichen erkannt, an denen nach Token1 gesucht wird.
- Bei Zeilenende und der Klammerlevel größer als eins ist, wird die nächste Zeile angehängt, diese durchläuft wieder Phase 1 und 2
- Bei Pipe "|" wird für beide Seiten der Pipe ein Phasenrestart(mit cmdLine-Parser) durchgeführt (genaueres dazu später)
- In dieser Phase wird das Kommando-Token und die Standard-Token-Liste gebildet, Token Trennzeichen sind dabei "<space>,;=&|<>(," und bei Klammerlevel größer 0 auch ")"
- Wenn das Kommando-Token (erstes) "REM", "IF", oder "FOR" ist wird direkt eine Sonderbehandlung aktiviert
- Wenn das erste Token als REM erkannt wird, wird nur bis zum zweiten Token ausgewertet, wichtig für Multiline Caret, Spezialzeichen werden jedoch nicht weiter expandiert für Phase 3

Phase3(echo): Wenn "echo on" aktiv ist, wird das Ergebnis der vorhergehenden Phasen angezeigt

- Bei call wird nur beim ersten mal ein echo ausgelöst, nicht mehr nach Phasen Neustarts
- For-Loop-Blöcke werden mehrfach angezeigt, erstmals der komplette Ausdruck mit nicht expandierten for-loop-vars, dann jeweils pro Schleifendurchlauf mit expandierten for-loop-vars
- Bei Blöcken wird nur einmal der expandierte Ausdruck angezeigt

Phase 4(for-loop-vars expansion): Expansion von %%a und so weiter

Phase5(Ausrufezeichen): Nur wenn "DelayedExpansion" aktiviert ist (durch Registry, setlocal EnableDelayedExpansion oder cmd /V:ON)

- Bei einem Ausrufezeichen wird die Variabel durch den Inhalt ersetzt, ist die Variabel undefiniert, verschwindet der Ausdruck
- Bei einem Caret wird das nächste Zeichen escaped (nur bei ! oder ^ wichtig), das Caret selbst wird entfernt, ACHTUNG hier spielen Anführungszeichen keine Rolle mehr
- Dadurch ergibt sich: echo ! zeigt "^ !" an, echo aber "^"
- Diese Phase wird unabhängig für das Kommando-Token und den Rest der Zeile ausgeführt! Zu sehen bei echo:""! "^^"

Phase6(call): Nur wenn das erste Token "call" ist, bei mehreren "call"'s wird diese Phase mehrfach durchlaufen

- Es wird ein Neustart der Phasen durchgeführt, beginnend bei Phase 0 und endet mit Phase2
- DelayedExpansion scheint generell deaktiviert zu sein, unabhängig von setlocal, cmd /V:on oder Registry Einstellungen

Phase7(Execute): Das Kommando wird ausgeführt

- Abhängig vom Kommando können weitere andere Expansionen/Escaping Funktionalitäten stattfinden
- z.B. Im Fall set "name=content" werden nicht die Standard-Token beachtet sondern als Content wird alles vom ersten Gleichzeichen bis zum letzten Anführungszeichen verwendet (bis zum Ende wenn kein Anführungszeichen vorhanden)

CmdLine-Parser

Arbeitet wie der BatchLine-Parser, außer
- Goto/call zu einem Label ist nicht erlaubt

Phase1(Prozent):

- %var% wird durch Inhalt von var ersetzt, wenn var nicht definiert ist bleibt der Ausdruck unverändert stehen
- Keine Spezialbehandlung von %%, auch das zweite Prozent dient als Anfang für eine Variabel z.B. var=Content, dann führt "%%var%%" zu "%Content%"

Phase5(Ausrufezeichen): Nur wenn "DelayedExpansion" aktiviert ist (durch Registry, setlocal EnableDelayedExpansion oder cmd /V:ON)

- Bei einem Ausrufezeichen wird die Variabel durch den Inhalt ersetzt, ist die Variabel undefiniert, bleibt der Ausdruck komplett stehen

for-loop-command-block

z.B. for /F "usebackq" %%a IN (`command block`) DO echo %%a
Der Command-Block wird zweimal geparst, der erste Lauf ist der Standard BatchLine-Parser, der zweite wird mit dem CmdLine-Parser durchgeführt
Dabei ist für DelayedExpansion nur der Registry Eintrag entscheidend, ob diese im zweiten Lauf aktiv ist
Der Aufruf entspricht cmd /c
Ein setzen von Variablen ist daher an dieser Stelle nicht beständig

PIPE

Beide Seiten einer Pipe werden zweimal geparst, der erste Lauf ist der Standard BatchLine-Parser, der zweite wird mit dem CmdLine-Parser durchgeführt
Dabei ist für DelayedExpansion nur der Registry Eintrag entscheidend, ob diese im zweiten Lauf aktiv ist
Die Aufrufe entsprechen jeweils cmd /S /D /c
Ein setzen von Variablen ist daher nicht beständig, z.B. set abc=123 | more setzt die Variable in dem cmdLine-context der nach dem Commando verschwindet

LabelParser

Bei einem goto oder call zu einem Label (Bei call die Doppelpunkt-Syntax bei goto geht es auch ohne) wird der Label gesucht (ach was?)
Es wird von der Stelle in der Datei gesucht an der sich der Sprungbefehl befindet in richtung Ende der Datei, wenn kein passender
Label gefunden wurde, beginnt die Suche am Anfang der Datei bis zum Sprungbefehl
Bei dieser Suche werden keinerlei Ersetzungen durchgeführt also keine %var% oder !var! auch kein Caret
Ein Label muss folgende Form haben:
Trennzeichen eins aus "<space>;,="
<Zeilenanfang><Ein beliebiges Zeichen><beliebig viele Trennzeichen><Doppelpunkt><beliebig viele Trennzeichen><Label><beliebiges Zeichen aus ":CR&|+<>" >
z.B.
goto :MeinLabel
";,= ,=;:;=, ,=MeinLabel| ist ein gültiger Label, der auch gefunden wird!

Aber
z.B.
set var=Eins
goto :%%var%% - Es wird nach dem Label %var% gesucht, hier läuft der normale BatchLine-Parser drüber
:%var% - Der Label heisst "%var%" nicht "eins"

TOKENIZER

Dieser Punkt ist noch in Bearbeitung und in vielen Teilen noch nicht vollständig oder korrekt.
Der Standard-Tokenizer zerlegt eine Zeile in einzelne Teile für die weitere Verarbeitung.
Er läuft normalerweise/teilweise in Phase2,4 und 5 ab (@todo vollkommen ungenau).
Einfache Trenner für Token sind <space>,;=
Automatische Trenner (durch die Funktionalität gegeben) sind <>|&
Anführungszeichen können die Trenner abschalten, so gilt "Dies ist,;=nur ein & Token"

Und demnächst in diesem Forum .... Die Erklärungen und Beispiele wie ich für den ganzen Mist überzeugende Hinweise gefunden habe.

Ich hoffe, dass ich zumindest ein kleines Licht erzeugen konnte und das ganze nicht zu langweilig war
Jan Erik

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 151127

Url: https://administrator.de/tutorial/die-geheimnisse-des-batch-zeilen-interpreters-151127.html

Ausgedruckt am: 22.12.2024 um 12:12 Uhr

9 Kommentare

Neuester Kommentar

Hallo jeb,

vielen Dank dass du meiner Bitte gefolgt bist. Umso interessanter, dass du deiner mir bereits bekannten englischen Abhandlung noch einige neue Aspekte hinzugefügt hast. Bin gespannt auf mehr ...

Grüße
rubberman

PS: Die Platzierung des Beitrags in der Rubrik "Frage" is allerdings denkbar ungünstig.

Danke rubbermann,

die Platzierung habe ich einfach nach dem System vorgenommen, "was Oben steht wird gelesen - der Rest niemals".

Und um mal anschauliche Effekte zu zeigen wozu das Ganze jetzt gut war ...

@echo off
setlocal DisableDelayedExpansion
set var1=!var2!
set var2=%%var3%%
set var3=Content
set "^=one"  
set "^^=two"  
set "SingleCaret=^"  
setlocal EnableDelayedExpansion
echo %var1%
call echo %var1%
call echo Caret test, this are %%!SingleCaret!%% carets, but you only see !SingleCaret!
call call call call call echo ^^ "^^"  

Ergebnis

%var3%
Content
Caret test, this are two carets, but you only see ^
^ "^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"  

jeb

1. Der letzte Satz unter TOKENIZER stimmt so nicht ganz. Auch klammern können "Trenner" abschalten

dir "test" | (echo a & goto:sprungmarke)

2. Es gibt noch folgende Kombination:

set a=1
if %a% equ %a% (
echo %a%
set a=2
echo %a%
call set a=3
echo %a%
)

Hallo miniversum,

entweder ich verstehe dein Beispiel nicht oder ich habe den Tokenizer schlecht beschrieben.

Bei beiden Beispielen wirken die Klammern sich doch gar nicht auf die Token aus.

Mit Token meine ich die einzelnen "Blöcke" einer Zeile oder Kommandoblocks.
Bsp.

call :meineFunc one "Two & 22" Three=,,Four  

Wird in sechs Token zerlegt
<call> <:meineFunc> <one> <"Two & 22"> <Three> <Four>

Sicherlich kann eine schliessende Klammer sich auf Token auswirken, bei Klammerlevel größer 0

z.B.

echo hallo)du da
(echo hallo)du da

Bei der zweiten Variante werden die Token wie folgt erzeugt
<echo> <hallo> <du> <da>
Spielt aber bis jetzt keine Rolle, weil ich keine Kombination finden kann, bei der man ein gültiges Token nach der Klammer erzeugen kann, welches nicht selbst ein Token-Trenner ist.

dir "test" || (echo a & goto:sprungmarke)

Das bedeutet, wenn der dir Befehl einen Fehler ergibt wird die klammer ausgeführt. Hier eben echo a UND das goto.
Würde eine Klammer das Trennzeichen nicht aufheben, sondern nur ein ", würde das goto in jeden Fall ausgeführt werden, so allerdings nur wenn der dir Befehl schief geht. Die logische Trennung ist also eine andere.

Moin jeb-the-batcher,

danke für deinen Beitrag, aber...

Zitat von @jeb-the-batcher:

die Platzierung habe ich einfach nach dem System vorgenommen, "was Oben steht wird gelesen - der Rest niemals".

... nö. das kann ich so nicht akzeptieren.

Ich stufe es mal um von "Frage" auf "Anleitung" und bewerte es entsprechend.

Grüße
Biber

Tja,

nicht so ganz, denn ...

Der Tokenizer zerlegt eine Zeile in einzelne Teilausdrücke,
damit hat das Verhalten der Klammern zum zusammenfassen logischer Kommandoblöcke nichts zu tun,
das sind zwei unterschiedliche Dinge.

Wenn man versuchen würde das in einer Therorie zusammen zu erklären wird daraus eine Spagetticode Erklärung

Daher gehören die Klammerblöcke allgemein in den Bereich Code/Anweisungsblöcke und bei Batch auch noch in den Bereich Caching.