5
Befehl in Schleife führt zu Scriptabbruch bei bestimmtem Rechner
Eine Einstellung verhindert die saubere Ausführung des Scripts.
Wenn innerhalb eine for-Schleife ein Befehl ausgeführt wird, brechen alle Scripts auf einer bestimmten Maschine sofort ab ohne eine Fehlermeldung zu produzieren.
Es handelt sich um diesen Schnipsel mit dem ich das Systemdatum je nach Bedarf umformatiere.
FOR /f "tokens=1-3 delims=. " %%a in ('DATE /T') do echo %%c_%%b_%%a
Dieser Code funktioniert auf meinem Haupt- und meinen Testrechnern prima nur nicht mehr da wo er soll. Nämlich auf einer neuinstallierten XP-Maschine auf der diverse Scripte mit diesem oder ähnlichem Code bereits über ein Jahr im Einsatz war.
Ich bin mir sicher dass es mit der Befehlserweiterung zusammenhängt, denn witzigerweise funktioniert das Script nicht, wenn es direkt gestartet wird, sondern nur noch dann,
wenn ich ein CMD-Fenster geöffnet habe, hier eintippe
cmd /a
das Ganze Abschicke und danach das Sript innerhalb dieses Fensters aufrufe.
Ich habe bereits die Registry gecheckt:
der EnableExtensions steht für die User und die Maschine auf 1.
Ausserdem habe ich noch probiert direkt im Script die Extensions für die Laufzeit mit Hilfe von
setlocal EnableExtensions
zu aktivieren. Das funktioniert leider auch nicht.
Hat mir jemand noch eine gute Idee?
Vielen Dank im Voraus
Hier noch ein paar Fakten:
- Zugriff per RDP als Mitglied der lokalen Admingruppe
- Alle aktuellen Patche sind vorhanden. Nur nicht SP3 als Ganzes.
- Der Rechner ist nicht Bestandteil eines AD.
Wenn innerhalb eine for-Schleife ein Befehl ausgeführt wird, brechen alle Scripts auf einer bestimmten Maschine sofort ab ohne eine Fehlermeldung zu produzieren.
Es handelt sich um diesen Schnipsel mit dem ich das Systemdatum je nach Bedarf umformatiere.
FOR /f "tokens=1-3 delims=. " %%a in ('DATE /T') do echo %%c_%%b_%%a
Dieser Code funktioniert auf meinem Haupt- und meinen Testrechnern prima nur nicht mehr da wo er soll. Nämlich auf einer neuinstallierten XP-Maschine auf der diverse Scripte mit diesem oder ähnlichem Code bereits über ein Jahr im Einsatz war.
Ich bin mir sicher dass es mit der Befehlserweiterung zusammenhängt, denn witzigerweise funktioniert das Script nicht, wenn es direkt gestartet wird, sondern nur noch dann,
wenn ich ein CMD-Fenster geöffnet habe, hier eintippe
cmd /a
das Ganze Abschicke und danach das Sript innerhalb dieses Fensters aufrufe.
Ich habe bereits die Registry gecheckt:
der EnableExtensions steht für die User und die Maschine auf 1.
Ausserdem habe ich noch probiert direkt im Script die Extensions für die Laufzeit mit Hilfe von
setlocal EnableExtensions
zu aktivieren. Das funktioniert leider auch nicht.
Hat mir jemand noch eine gute Idee?
Vielen Dank im Voraus
Hier noch ein paar Fakten:
- Zugriff per RDP als Mitglied der lokalen Admingruppe
- Alle aktuellen Patche sind vorhanden. Nur nicht SP3 als Ganzes.
- Der Rechner ist nicht Bestandteil eines AD.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 87594
Url: https://administrator.de/forum/befehl-in-schleife-fuehrt-zu-scriptabbruch-bei-bestimmtem-rechner-87594.html
Ausgedruckt am: 14.04.2025 um 20:04 Uhr
5 Kommentare
Neuester Kommentar
Ich bin mir sicher dass es mit der Befehlserweiterung zusammenhängt, denn witzigerweise funktioniert das Script nicht, wenn es direkt gestartet wird, sondern nur noch dann, wenn ich ein CMD-Fenster geöffnet habe, hier eintippe cmd /a das Ganze Abschicke und danach das Sript innerhalb dieses Fensters aufrufe.
Wie kommst Dud en darauf?
Der Parameter /a bedeutet:
/A Ausgabe interner Befehle in eine Pipe oder Datei im ANSI-Format
Schau mal ob in der richtung was verstellt ist.
Moin timmaeh,
dumme Frage: hast Du auch geprüft, ob denn auch die CMD.exe als Standardbefehlsprozessor angezogen wird? Und nicht vielleicht die Command.com?
Lass Dir doch mal dem Wert von %comspec% anzeigen mit "set comspec".
Grüße
Biber
dumme Frage: hast Du auch geprüft, ob denn auch die CMD.exe als Standardbefehlsprozessor angezogen wird? Und nicht vielleicht die Command.com?
Lass Dir doch mal dem Wert von %comspec% anzeigen mit "set comspec".
Grüße
Biber
Moin timmaeh,
dumme Frage: hast Du auch geprüft, ob
denn auch die CMD.exe als
Standardbefehlsprozessor angezogen wird? Und
nicht vielleicht die Command.com?
dumme Frage: hast Du auch geprüft, ob
denn auch die CMD.exe als
Standardbefehlsprozessor angezogen wird? Und
nicht vielleicht die Command.com?
Jepp, die cmd.exe ist der Standardbefehlsprozessor.
Wie kommst Du dennn darauf?
Der Parameter /a bedeutet:
> /A Ausgabe interner Befehle in
eine Pipe oder Datei im ANSI-Format
Schau mal ob in der Richtung was verstellt
ist.
Der Parameter /a bedeutet:
> /A Ausgabe interner Befehle in
eine Pipe oder Datei im ANSI-Format
Schau mal ob in der Richtung was verstellt
ist.
Irgendwie hatte ich im Hinterkopf, das cmd.exe mit Parameter a die Befehlserweiterungen aktiviert.... Ok, da scheint ein "Loch" im Hirn gewesen zu sein.... ^^
Hast du ne Idee was man da verstellen könnte? Kanns vielleicht an einem Patch liegen?
Kann ich den Parameter /a standardmäßig aktivieren?
Puh, langsam wirds echt kompliziert.
Ich habe mittlerweile noch etliche Tests durchgeführt und folgendes festgestellt.
Die Ausführung des Scripts funktioniert nur nicht in der ersten Instanz.
Wenn innerhalb einer cmd-Sitzung eine neue ausgeführt wird, dann werden die Befehle sauber ausgeführt. Es klappt auch, wenn ich die cmd aus einem anderen Script mit "start testscript.cmd" heraus starte.
Wenn allerdings innerhalb eines Batchfiles eine neue Sitzung geöffnet wird, dann endet das Script an dieser Stelle.
Ich habe mittlerweile noch etliche Tests durchgeführt und folgendes festgestellt.
Die Ausführung des Scripts funktioniert nur nicht in der ersten Instanz.
Wenn innerhalb einer cmd-Sitzung eine neue ausgeführt wird, dann werden die Befehle sauber ausgeführt. Es klappt auch, wenn ich die cmd aus einem anderen Script mit "start testscript.cmd" heraus starte.
Wenn allerdings innerhalb eines Batchfiles eine neue Sitzung geöffnet wird, dann endet das Script an dieser Stelle.
