Variable wird nicht erkannt
Hallo hier mein Problem.
Ich habe mehrere batchdateien. Die eine sieht foglendermaßen aus
Dieses Script läuft auf allen Rechner. Auch soweit ohne Probleme.
Das Problem ist auf meinem Rechner läuft es nicht und stürzt ab. Und zwar wird die shell geschlossen wenn ich eine aufmache und die Batch von Hand starte.
Führe ich pausen ein sehe ich das bereits bei der ersten For Schleife die batch abstürzt.
Führe ich die For schleife alleine aus kommt folgende fehlermeldung
Kann mir wer helfen??
Ich habe mehrere batchdateien. Die eine sieht foglendermaßen aus
echo %DATE% %TIME% %COMPUTERNAME% %SESSIONNAME% Start localLogonscript >> c:\Domainscripte.log
REM Prüfen ob der erste Domaincontroller vorhanden ist. Falls Ja wird direkt die Batch verlassen.
REM Falls der Ping erfolglos ist wird der
REM zweite Domaincontroller gesucht
FOR /F "tokens=3 delims=," %%i IN ('ping 172.xxx.xxx.xxx -w 128 -n 1') DO SET srveins=%%i
echo %DATE% %TIME% %COMPUTERNAME% %SESSIONNAME% 1 >> c:\Domainscripte.log
SET srveins=%srveins:~1%
echo %DATE% %TIME% %COMPUTERNAME% %SESSIONNAME% 2 >> c:\Domainscripte.log
FOR /F "tokens=3 delims= " %%i IN ("%srveins%") DO SET pingergebniseins=%%i
echo %DATE% %TIME% %COMPUTERNAME% %SESSIONNAME% 3 >> c:\Domainscripte.log
if not "%pingergebniseins%" =="1" GoTo normalende
echo %DATE% %TIME% %COMPUTERNAME% %SESSIONNAME% 4 >> c:\Domainscripte.log
REM Prüfen ob der zweite Domaincontroller vorhanden ist. Falls Ja wird direkt die Batch verlassen.
REM Falls der Ping erfolglos ist wird der
REM wird die Batch mit der Fehlersprungmarke verlassen.
FOR /F "tokens=3 delims=," %%i IN ('ping 172.xxx.xxx.xxx -w 128 -n 1') DO SET srvzwei=%%i
SET srvzwei=%srvzwei:~1%
FOR /F "tokens=3 delims= " %%i IN ("%srvzwei%") DO SET pingergebniszwei=%%i
if "%pingergebniszwei%" =="1" GoTo verloren
goto normalende
:verloren
echo %DATE% %TIME% %COMPUTERNAME% %SESSIONNAME% Kein Domaincontroller gefunden >> c:\Domainscripte.log
goto ende
:normalende
echo %DATE% %TIME% %COMPUTERNAME% %SESSIONNAME% Starte DomainLogonofflogScript >> c:\Domainscripte.log
CALL \\hemmelrath.kli\SysVol\hemmelrath.kli\scripts\Logonofflog.cmd -1 \\xxxxxxx\IT$\ADSLogins\
:ende
echo %DATE% %TIME% %COMPUTERNAME% %SESSIONNAME% Ende localLogonscript >> c:\Domainscripte.log
Dieses Script läuft auf allen Rechner. Auch soweit ohne Probleme.
Das Problem ist auf meinem Rechner läuft es nicht und stürzt ab. Und zwar wird die shell geschlossen wenn ich eine aufmache und die Batch von Hand starte.
Führe ich pausen ein sehe ich das bereits bei der ersten For Schleife die batch abstürzt.
Führe ich die For schleife alleine aus kommt folgende fehlermeldung
FOR /F "tokens=3 delims=," %%i IN ('ping 172.xxx.xxx.xxx -w 128 -n 1') DO SET srveins=%%i
"%%i" ist syntaktisch an dieser Stelle nicht verarbeitbar.
Kann mir wer helfen??
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 91051
Url: https://administrator.de/forum/variable-wird-nicht-erkannt-91051.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
13 Kommentare
Neuester Kommentar
Moin SvenGuenter,
beispielsweise auf wikipedia kannst Du das KISS-Prinzip nachlesen.
Frei übersetzt in etwa: "Keep it simple, Sven. "
Wenn Du über eine mehrzeilige Ping-Ausgabe, die je nach Rechner, Land, OS-Version und Ping-Ergebnis unterschiedlich sein kann, mit je 2 FOR/F-Anweisungen drüberläufst und jeweils das 3. Token der letzten Zeile (mal mit Space, mal mit Komma getrennt) rausfieselst.... das ist nun mal fehlerträchtig.
Also mein Tipp: De-Eskalation. Fehlervermeidung statt Fehlersuche.
Weniger Code=weniger Kot.
Das Ping-Utility liefert DEFINITIV in deutsch, englisch, italienisch, Oldenburger Platt und überhaupt immer eine Zeile mit dem möglichen Suchwort "TTL" zurück, wenn der angePINGte Rechner wenigstens winkt oder blinzelt.
Wenn kein Rechner antwortet, kommt (egal welche Sprache, welches OS, welcher Fehler) kein Suchwort "TTL" zurück.
Wenn Du diese ganzen mehrstufigen "FOR/F...token=.." in ('ping...') Do SET..." ein bisschen eindampfst, bleibt übrig:
Ich denke, wenn dadurch 98% der FOR/F und SET und IF ...==-Konstrukte wegfallen, könnten auch 98% der Fehlerquellen verschwunden sein.
Grüße
Biber
beispielsweise auf wikipedia kannst Du das KISS-Prinzip nachlesen.
Frei übersetzt in etwa: "Keep it simple, Sven. "
Wenn Du über eine mehrzeilige Ping-Ausgabe, die je nach Rechner, Land, OS-Version und Ping-Ergebnis unterschiedlich sein kann, mit je 2 FOR/F-Anweisungen drüberläufst und jeweils das 3. Token der letzten Zeile (mal mit Space, mal mit Komma getrennt) rausfieselst.... das ist nun mal fehlerträchtig.
Also mein Tipp: De-Eskalation. Fehlervermeidung statt Fehlersuche.
Das Ping-Utility liefert DEFINITIV in deutsch, englisch, italienisch, Oldenburger Platt und überhaupt immer eine Zeile mit dem möglichen Suchwort "TTL" zurück, wenn der angePINGte Rechner wenigstens winkt oder blinzelt.
Wenn kein Rechner antwortet, kommt (egal welche Sprache, welches OS, welcher Fehler) kein Suchwort "TTL" zurück.
Wenn Du diese ganzen mehrstufigen "FOR/F...token=.." in ('ping...') Do SET..." ein bisschen eindampfst, bleibt übrig:
...
:DCxCheck
ping 172.xxx.yyy.zzz ...|find "TTL" >nul
If errorlevel 1 goto :DCxAntwortetNicht
:: logisches ELSE
goto :DCxAntwortet_AllesPrima
....
:: entsprechend für DCy (zweiten Domaincontroller) in grün.
Ich denke, wenn dadurch 98% der FOR/F und SET und IF ...==-Konstrukte wegfallen, könnten auch 98% der Fehlerquellen verschwunden sein.
Grüße
Biber
Moin SvenGuenter,
danke fürs prompte Feedback - so stelle ich mir ein funktionierendes Forum vor.
Na ja, der Fehler würde sich schon finden lassen (wenn Du mal eine blutjunge rothaarige Praktikantin zu Seite gestellt bekommst und nicht so recht weißt, wie Du sie während der Bürozeiten ruhigstellen kannst)...
Irgendeines der aufgerufenen PINGs liefert -immer oder manchmal- eine Ausgabe zurück, bei der eben keine einzige Zeile dabei ist, die ein drittes Token enthält (wenn die Delimiter Kommas sind). So was in der Art.
Und hey - niemand hat je zugesichert, dass PING.exe immer etwas zurückliefern soll, dass 3 Spalten hat (bei Erfolg und bei Fehler). Da muss ich mal Bills Bande in Schutz nehmen.
Andererseits: der Grund, weshalb wir bei Ping.exe-Aufrufen immer den Rückgabetext und nicht den Rückgabe-Errorlevel abfragen ist ja:
Es kommt beim Ping-Utility eben nicht 0 bei AllesPrima und ungleich 0 bei InnerGrütze zurück.
Ich setze den Beitrag trotzdem mal auf "erledigt".
Grüße
Biber
danke fürs prompte Feedback - so stelle ich mir ein funktionierendes Forum vor.
Was mich aber immer noch wundert ist das die Variable %%i zum Absturz der Bash führt bzw. das die Syntax von heute auf morgen auf einmal falsch sein soll obwohl sie vorher wochenlang funktionierte.
Na ja, der Fehler würde sich schon finden lassen (wenn Du mal eine blutjunge rothaarige Praktikantin zu Seite gestellt bekommst und nicht so recht weißt, wie Du sie während der Bürozeiten ruhigstellen kannst)...
Irgendeines der aufgerufenen PINGs liefert -immer oder manchmal- eine Ausgabe zurück, bei der eben keine einzige Zeile dabei ist, die ein drittes Token enthält (wenn die Delimiter Kommas sind). So was in der Art.
Und hey - niemand hat je zugesichert, dass PING.exe immer etwas zurückliefern soll, dass 3 Spalten hat (bei Erfolg und bei Fehler). Da muss ich mal Bills Bande in Schutz nehmen.
Andererseits: der Grund, weshalb wir bei Ping.exe-Aufrufen immer den Rückgabetext und nicht den Rückgabe-Errorlevel abfragen ist ja:
Es kommt beim Ping-Utility eben nicht 0 bei AllesPrima und ungleich 0 bei InnerGrütze zurück.
Ich setze den Beitrag trotzdem mal auf "erledigt".
Grüße
Biber
Moin SvenGuenter,
ich wäre der Letzte, der Dich vom Googlen nach blutjungen rothaarigen PraktikantInnen abhalten würde, ehrlich, aber die Ursache für den Fehler an einem konkreten Rechner finden wir hier gemeinsam schneller.
Dann ändere in Deinem zuerst geposteten Schnipsel diese Zeilen ...
...zum Debuggen so um:
In den Ping-Bildschirm-Ausgaben können wir dann in Ruhe graben, was beim letzten Mal abgekachelt ist.
Grüße
Biber
ich wäre der Letzte, der Dich vom Googlen nach blutjungen rothaarigen PraktikantInnen abhalten würde, ehrlich, aber die Ursache für den Fehler an einem konkreten Rechner finden wir hier gemeinsam schneller.
Dann ändere in Deinem zuerst geposteten Schnipsel diese Zeilen ...
FOR /F "tokens=3 delims=," %%i IN ('ping 172.xxx.xxx.xxx -w 128 -n 1') DO SET srveins=%%i
ping 172.xxx.xxx.xxx -w 128 -n 1 >d:\temp\PingProtDC1.txt
FOR /F "tokens=3 delims=," %%i IN (d:\temp\PingProtDC1.txt) DO SET "srveins=%%i"
...
In den Ping-Bildschirm-Ausgaben können wir dann in Ruhe graben, was beim letzten Mal abgekachelt ist.
Grüße
Biber
Moin Sven,
gute und schlechte Nachrichten:
Ich kann den Fehler reproduzieren und auch umgehen helfen.
Verstehen allerdings kann ich es nicht.
Zum Reproduzieren unter Win XP SP2:
Am Cmd-Prompt mal eine Datei noerr.txt erzeugen:
...und die mit Deiner FOR/F-Anweisung durchflöhen.
Wie zu sehen ist, wird (unabhängig vom Delimiter ",", den ich zuerst im Verdacht hatte) die SET-Anweisung verstümmelt, wenn das SET von einem Anführungszeichen gefolgt wird. (beide SET "myvar =%i"-Versuche scheitern.).
Muss (eventuell) daran liegen, dass in der Pingausgabe ein <TAB> am Anfang der Zeile steht statt eine Anzahl Leerzeichen..*spekulier* ...*rumrate*...
Es deutet ja jedenfalls darauf hin, dass die Länge der Inputzeile und der berechnete Offset des Tokens bei M$ irgendwie durcheinanderkommen.
Oder es ist ein anderes nicht erkennbares Zeichen in der NoErr.txt.
Ich werde es mal im Auge behalten.
Grüße
Biber
[Edit 4.7.2008]
Nachtrag: Dieses Fehl-Verhalten ist wirklich beschränkt auf bzw. abhängig von der Ausgabe des Ping-Utilities.
Da wird Dreck geliefert, der nicht den normalen Erwartungen an eine Plain-Text-Ausgabe entspricht.
Folgendes sollte sich auch auf Euren Rechnern nachstellen lassen:
Bei anderen Texten/Textdateien ist dieses Verhalten nicht reproduzierbar.
Und nein, ich habe mein Ping-Utilities nicht von einem dubiosen estnischen Fileserver herunterladen und nein, es wird nicht als infiziert angezeigt, sondern ist das Original aus dem unerschöpflichen Fundus des sympathischen Weltmarktführers.
[/Edit]
gute und schlechte Nachrichten:
Ich kann den Fehler reproduzieren und auch umgehen helfen.
Verstehen allerdings kann ich es nicht.
Zum Reproduzieren unter Win XP SP2:
Am Cmd-Prompt mal eine Datei noerr.txt erzeugen:
ping localhost>noerr.txt
>for /f "tokens=3 delims==" %i in (noerr.txt) do @echo Set myvar=%i
Set myvar=128
Set myvar=128
Set myvar=128
Set myvar=128
Set myvar= 4, Verloren
Set myvar= 0ms, Mittelwert
(=22:00:43 D:\temp=)
>for /f "tokens=3 delims==" %i in (noerr.txt) do @echo Set "myvar=%i"
"et "myvar=128
"et "myvar=128
"et "myvar=128
"et "myvar=128
Set "myvar= 4, Verloren "
Set "myvar= 0ms, Mittelwert "
(=22:00:48 D:\temp=)
>for /f "tokens=3 delims=," %i in (noerr.txt) do @echo Set myvar=%i
Set myvar= Verloren = 0 (0% Verlust)
Set myvar= Mittelwert = 0ms
(=22:01:17 D:\temp=)
>for /f "tokens=3 delims=," %i in (noerr.txt) do @echo Set "myvar=%i"
Set "myvar= Verloren = 0 (0% Verlust)"
"et "myvar= Mittelwert = 0ms
Muss (eventuell) daran liegen, dass in der Pingausgabe ein <TAB> am Anfang der Zeile steht statt eine Anzahl Leerzeichen..*spekulier* ...*rumrate*...
Es deutet ja jedenfalls darauf hin, dass die Länge der Inputzeile und der berechnete Offset des Tokens bei M$ irgendwie durcheinanderkommen.
Oder es ist ein anderes nicht erkennbares Zeichen in der NoErr.txt.
Ich werde es mal im Auge behalten.
Grüße
Biber
[Edit 4.7.2008]
Nachtrag: Dieses Fehl-Verhalten ist wirklich beschränkt auf bzw. abhängig von der Ausgabe des Ping-Utilities.
Da wird Dreck geliefert, der nicht den normalen Erwartungen an eine Plain-Text-Ausgabe entspricht.
Folgendes sollte sich auch auf Euren Rechnern nachstellen lassen:
>for /f "delims=" %i in ('find "Ant" noerr.txt') do @echo test1 %i test2
test1 ---------- NOERR.TXT test2
test2Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
test2Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
test2Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
test2Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
--- bzw-
>>for /f "delims=" %i in ('ping localhost^|find "Ant"') do @echo test1 %i test2
test2Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
test2Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
test2Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
test2Antwort von 127.0.0.1: Bytes=32 Zeit<1ms TTL=128
Bei anderen Texten/Textdateien ist dieses Verhalten nicht reproduzierbar.
Und nein, ich habe mein Ping-Utilities nicht von einem dubiosen estnischen Fileserver herunterladen und nein, es wird nicht als infiziert angezeigt, sondern ist das Original aus dem unerschöpflichen Fundus des sympathischen Weltmarktführers.
[/Edit]
So,
hoffentlich letzte Ergänzung zu diesem Ping-Ausgabetext.
Bei normalem Plaintext/Textdateien unter Dos/Windows-Systemen wird jede Zeile mit den Zeichen
Der ausgegebene Bildschirm-Text des Ping-Utilities endet aber mit CR+CR+LF, was große Grütze ist.
Führt bei jeglicher Stringverkettung unter dem CMD/im Batch zu den beschriebenen Effekten. Denn dann wird der gesamte Zeileninhalt ausschließlich CRLF als Text weiterverarbeitet... und der schließt das überflüssige CR (das erste Zeichen von CR+Cr+LF) mit ein.
Dieses ist aber unter dem CMD gar kein gültiges Zeichen innerhalb eines Textes/einer Variablen.
Na ja, wie dem auch sei, die ursprüngliche Empfehlung zu ursprünglichen Frage war ja:
Mach es ohne FOR/F-Konstrukte.
Diese Empfehlung erhalte ich aufrecht.
Grüße
Biber
hoffentlich letzte Ergänzung zu diesem Ping-Ausgabetext.
Bei normalem Plaintext/Textdateien unter Dos/Windows-Systemen wird jede Zeile mit den Zeichen
- "Carriage Return" und "LineFeed",
- bekannt auch als CR/LF oder auch als
- Chr(10) und Chr(13)
Der ausgegebene Bildschirm-Text des Ping-Utilities endet aber mit CR+CR+LF, was große Grütze ist.
Führt bei jeglicher Stringverkettung unter dem CMD/im Batch zu den beschriebenen Effekten. Denn dann wird der gesamte Zeileninhalt ausschließlich CRLF als Text weiterverarbeitet... und der schließt das überflüssige CR (das erste Zeichen von CR+Cr+LF) mit ein.
Dieses ist aber unter dem CMD gar kein gültiges Zeichen innerhalb eines Textes/einer Variablen.
Na ja, wie dem auch sei, die ursprüngliche Empfehlung zu ursprünglichen Frage war ja:
Mach es ohne FOR/F-Konstrukte.
Diese Empfehlung erhalte ich aufrecht.
Grüße
Biber