Batchdateinen Ende Abwarten / Ausgabe bewerten

Man könnte die Tochter-Batches Dateien erstellen lassen.

1

start batch1.bat

2

loop:

3

if not exist ready1.txt goto loop

4

del ready1.txt

5

echo habe fertig !

busy loop schrieb:
> der zweite durch
> den Virenscanner

Das ist dann aber was für Anfänger! Wir haben auf Arbeit McAffee, wenn 
der Freitags 14 Uhr von der IT losgelassen wird, legt der alle 
vorhandenen Cores lahm, vor allem wenn man einen Rechner mit HDD hat.

Peter II schrieb:
> Christian R. schrieb:
>> wenn
>> der Freitags 14 Uhr von der IT losgelassen wird, legt der alle
>> vorhandenen Cores lahm, vor allem wenn man einen Rechner mit HDD hat.
>
> Wenn es nur eine HDD ist, dann sind die cores weniger belastet als bei
> einer SSD.

Nee, bei uns eben nicht, das ist das zweite wunderliche dran. Bei den 
SSD Rechnern kann man nebenbei noch arbeiten, bei den HDD Rechnern kann 
man sofort nach Hause gehen.
Ich denk dann immer an John McAffee und seine Vollmeise, da muss man 
sich auch über die Software nicht mehr wundern.

Dann ist das Ding aber trotzdem bekloppt programmiert, denn die CPU Last 
geht auf allen Kernen auf 100% wenn der startet.

Amateur schrieb:
> Gibt es nicht mehr den Befehl: pause

...und dann muss der Benutzer entscheiden wann es weiter gehen soll oder 
wie?

in der bash gibt's dafür wait, ich glaube in batch gibt's da nichts 
passende.
Imo entkoppelt start ja auch komplett, oder?

Peter II schrieb:
> Dirk D. schrieb:
>> in der bash gibt's dafür wait, ich glaube in batch gibt's da nichts
>> passende.
>
> es gibt viele unix Tools auch für Windows. Im netzt findet sich auch
> eine sleep.exe, damit kann man ohne CPU-zeit warten.
>
> Aber meist es schneller, es gleich in einer "richtigen" Sprache zu
> machen.

wait und sleep sind völlig unterschiedliche dinge.
sleep wartet eine vorgegebene zeit.
wait wartet bis Hintergrund-Prozesse beendet sind.

Wait gibt es bestimmt auch für windows, es wird aber wahrscheinlich nur 
in einer passenden umgebung, z.B. cygwin, laufen.

Ich bin ja der Meinung das es oft schneller geht wenn man die 
vorhandenen Tools nutzt statt ständig das Rad neu zu erfinden.

Peter II schrieb:
> Dirk D. schrieb:
>> Ich bin ja der Meinung das es oft schneller geht wenn man die
>> vorhandenen Tools nutzt statt ständig das Rad neu zu erfinden.
>
> aber oft passt ein 26" Rad nicht in einen 26" Rahmen.
> wenn es alles schon fertig geben würde, könnte man alle
> Programmiersprachen abschaffen.

Dann erzähl mal, wie du in einer Batchdatei ein eigenes wait 
implementieren willst.
Oder, um wieder die Analogie mit dem Rad zu bemühen: Wenn du gar keinen 
Rahmen hast, bringt dir das Rad auch nix.

Ich würde nen Python-Interpreter (oder wahlweise irgend ne andere 
komfortable Scriptsprache der eigenen Vorliebe entsprechend) 
installieren.

Das mache ich persönlich auf allen Rechnern auf denen mal so eine 
Notwendigkeit erwächst ohne auch nur eine Sekunde lang zu zögern, denn 
das frisst kein Brot und man kann damit bei Bedarf alles mögliche 
scripten. Das ist ungefähr so wie bei Muttern im Haus irgendwo ne kleine 
Werkzeugkiste zu deponieren, wenn man irgendwann später "mal schnell" ne 
Zange braucht oder nen Kreuzschlitz hat man sofort das Nötigste zur Hand 
ohne umständlich mit ungeeigneten Tools (Küchenmesser, cmd.exe, 
Tesafilm, Geflügelschere, etc.) improvisieren zu müssen 
(Verletzungsgefahr!).

Also wenn es nur um das Feststellen des Endes der Batches geht, dann 
kann man mit tasklist feststellen, ob die Batchfenster alle noch da 
sind, bzw. wann alle beendet sind.
Beispiel:

rem Starten eines neuen Fensters, welches den pause-Befehl ausführt,
rem und den Titel "mein-CMD - pause" trägt
start "mein-CMD" pause

rem dann mit tasklist (in einer Schleife) abfragen
tasklist /FI "windowtitle eq mein-CMD - pause"|find "cmd.exe"

Das Find ist am Ende nötig, da tasklist selbst keinen auswertbaren 
Errorlevel zurückliefert (immer 0), während find eine 1 liefert, wenn 
nichts gefunden (sonst 0).
Das funktioniert dann auch mit einem ganzen Bündel an gleichzeitig 
gestarteten Batches bzw. Kommandos.

Und was die Untersuchung auf Fehler angeht: die meisten Kommandos geben 
einen RC zurück, welcher ja via %errorlevel% abfragbar ist. damit kann 
man ja den Fehlerstatus jedes einzelnen Kommandos im Batch abfragen, und 
entsprechend darauf reagieren. Z.B. eine Ausgabe in ein Logfile machen, 
z.B 0 im Erfolgsfalle, 1 im Fehlerfalle, oder bestimmte Strings, welche 
man dann zusätzlich noch im Haupt-Batch auswerten lassen könnte.
Wenn man aber Details über einen Fehler haben will, ist es natürlich 
immer günstig, den Output in ein File umzuleiten, damit man auch eine 
Fehleranalyse machen kann.