Tales from the Script
September 2004
Alle auf Deutsch verfügbaren "Tales from the Script"-Kolumnen finden Sie hier.
Auf dieser Seite
Bugs schleichen sich ein – aber wie wird man sie wieder los?
Also, wir haben wohl alle gehört, wie intelligent Delfine sind – und auch dass Schimpansen in der Lage sind, Zeichensprache zu verwenden. Wir haben sogar von Vögeln in Neukaledonien gelesen, die in der Lage sind, Werkzeuge zu nutzen (auch wenn sie – bei aller Fairness – gerade einmal einen Stock im Schnabel halten können, um damit Käfer aus Rissen und Spalten in Bäumen zu pulen. Sie verwenden ja nun nicht gerade eine Tischkreissägen oder eine Bohrmaschine).
Wir sind sehr stolz auf unsere Freunde aus dem Tierreich (weiter so Jungs), und an Zeichensprache und Werkzeugen gibt es auch wirklich nichts auszusetzen … aber es gibt mindestens einen Bereich, in dem es keine anderes Geschöpf mit uns Menschen aufnehmen kann: Dem Ausrotten von Arten.
Menschen gegen Alpenfledermaus? Keine Herausforderung. Menschen gegen Schweinsfuß-Nasenbeutler? Hasta la vista, Baby. Neukaledonische Krähen mögen in der Lage sein, Werkzeuge zu verwenden, aber wer hat wohl die afrikanische Blauantilope ausgelöscht? Na? Ein kleiner Tipp: Es waren ganz sicher nicht die neukaledonischen Krähen.
Klarstellung: Wir machen natürlich nur Spaß. Natürlich finden wir keinen Gefallen an der Ausrottung anderer Arten. Tatsächlich möchten wir nicht, dass irgendeinem lebenden Wesen etwas Böses angetan wird. Gut, vielleicht mit Ausnahme des ständig bellenden Nachbarshundes. Und der gruseligen Katze von gegenüber, die immer dieses blaue Halstuch trägt. Das war's aber auch schon. |
Auch wenn Menschen Profis im Auslöschen und Ausrotten sind, gibt es doch mindestens eine Kreatur, die seinen Anstrengungen bisher widerstanden hat: der Computer-Bug. Er wurde das erste Mal im Jahr 1947 entdeckt, und er wurde keineswegs ausgerottet – tatsächlich ist er eine heimtückische Plage, die jeden Tag größer wird. Außerdem scheinen die Auswirkungen von Bugs immer schlimmer zu werden. Nach vorsichtigen Schätzungen hat der berüchtigte Jahr-2000-Bug zum Beispiel weltweit mehr als 300 Milliarden Dollar an Kosten verursacht.
Historische Fußnote: Nach einer Legende war der erste Computer-Bug (Bug=Käfer, Wanze) genau das – ein Insekt. 1947 kam es zu Problemen mit dem Mark II (einem der ersten Computer der Welt). Nach intensiver Suche stellten die Programmierer fest, dass eine Motte in ein Relay eingeklemmt war. Dies hatte zum Ausfall des Rechners geführt (nebenbei: die Motte hatte auch einen ziemlich miesen Tag). Die Motte wurde entfernt und in das Logbuch des Mark II eingeklebt. Daneben schrieb jemand "First actual case of bug being found". Ob Sie es glauben oder nicht, diese Motte wird im Smithsonian Institute aufbewahrt (anscheinend gehen den Museen die Ausstellungsstücke aus – zumindest solange Michelangelo und Leonardo da Vinci noch tot sind.) |
Wir wissen, dass Bugs (oder genauer gesagt – Fehler im Programmcode, die zu Problemen bei den entsprechenden Scripten führen) etwas sind, um das sich Systemadministratoren nicht wirklich kümmern möchten. Nach der letzten Scripting-Webcast-Serie haben wir jedoch eine Unmenge von Fragen wie diese erhalten:
“Gibt es irgendwelche Tools, mit denen ich meinen Code debuggen kann?”
“Kennt Ihr irgendwelche Software, die das Debuggen von Code oder die Fehlersuche in Scripten vereinfacht?"
“Kann ich irgendwo den Script-Debugger herunterladen?"
Es gibt tatsächlich eine Stelle, an der Sie den Script-Debugger herunterladen können – und zwar gleich hier bei Microsoft. Anscheinend wissen es nur die Wenigsten, aber Microsoft bietet einen kostenlosen Script-Debugger an. Trotz seiner leicht sonderbaren Benutzeroberfläche stellt er viele Funktionen ausgewachsener Entwicklungsumgebungen wie beispielsweise Visual Studio zur Verfügung. Wenn Sie ein Tool zum Debuggen Ihrer Scripte suchen, dann ist der Microsoft Script Debugger ein ganz guter Anfang.
Anmerkung: Wenn Microsoft also einen Script-Debugger anbietet, warum haben wir Ihnen das dann nicht längst deutlich gesagt? Höchstwahrscheinlich liegt das daran, dass Microsoft-Code fast keine Bugs enthält. Wir haben also nie über Sachen wie Debugger nachdenken müssen. |
Hey, wir sagten höchstwahrscheinlich …
Wenn Sie Windows 2000 verwenden, dann haben Sie den Script-Debugger im Übrigen schon. Er ist auf der Windows-CD als Installationsoption enthalten. Unter Windows XP und Windows Server 2003 steht er zwar nicht über die CD zur Verfügung, aber Sie können eine Version für diese Betriebssysteme herunterladen. Das gleiche gilt für Windows 98, Windows Me und Windows NT 4.0.
Wenn Sie nach der Download-Seite suchen, dann versuchen Sie es doch mal hier:
| • | Microsoft Windows Script Debugger für Windows NT 4.0, 2000 und XP (englischsprachig) |
| • |
Den Script-Debugger starten
Der Microsoft Script-Debugger ist ein bescheidenes, kleines Tool – und er ist, wie gesagt, etwas exzentrisch. Nachdem Sie ihn heruntergeladen und installiert haben, werden Sie ihn wahrscheinlich als nächstes starten und ein Script in den Debugger laden wollen. Bemühen Sie sich nicht – es wird nicht funktionieren. Oh sicher, der Debugger startet, und Sie können ein Script laden. Aber ab da bekommen Sie ein kleines Problem: Sie werden feststellen, dass alle Debugging-Befehle deaktiviert sind. Sie können also überhaupt nichts machen.
Nein, bitte jetzt keine Witze darüber, wie viel besser die Welt wäre, wenn das andere Microsoft-Produkte auch so machen würden. Und keine Sorge, der Script-Debugger funktioniert sehr wohl – nur nicht auf diese Weise. Stattdessen müssen Sie über die Kommandozeile ein Script mit dem Parameter //x starten. Um zum Beispiel das Script my_script.vbs in den Script-Debugger zu laden, verwenden Sie diesen Befehl:
cscript my_script.vbs //x
Anmerkung: Wieso der Script-Debugger so funktioniert? Keine Ahnung. Vielleicht fragen Sie mal einen Delfin – die sollen ja ziemlich schlau sein … Tatsächlich hat die Antwort wohl etwas damit zu tun, dass der Script-Debugger ursprünglich für das Debuggen von ASP- und HTML-Seiten entwickelt wurde. Das Debuggen von eigenständigen VBScript- und Jscript-Dateien ist nur so etwas wie ein kleiner Bonus. |
Es klingt zwar zugegebenermaßen ein wenig verrückt, aber es funktioniert. Starten Sie ein Script mit dem Parameter //x, und Sie werden feststellen, dass die Debugging-Funktionen nun zur Verfügung stehen.
Wichtig: Bevor wir weiter machen, sollten wir darauf hinweisen, dass der Script-Debugger Ihnen eine erhebliche Kontrolle über die Ausführung des Scriptes gibt. Das bedeutet aber nicht, dass es auf irgendeine magische Weise vom gesamten Rest des Systems isoliert ist. Stattdessen wird das Script während des Debuggens normal ausgeführt. Wenn Sie also ein Script debuggen, das alle Active Directory-Benutzerkonten löscht, dann sollten Sie nicht davon ausgehen, dass es sich um einen Probelauf handelt. Am Ende des Scripts haben Sie in diesem Fall alle Benutzerkonten gelöscht. Der Debugger ist ein Tool zur Fehlersuche – er ist keine Sandbox oder irgendeine virtuelle Umgebung. |
Was machen Sie also, nachdem Sie das Script in den Debugger geladen haben? Auch wenn Ihnen einige Möglichkeiten offen stehen, wollen wir uns auf die folgenden Aufgaben konzentrieren:
| • | Code schrittweise ausführen |
| • | Setzen und Entfernen von Breakpoints |
| • | Arbeiten mit Variablen |
| • | Scriptbefehle ausführen |
Schrittweises Ausführen von Code
Microsoft Word ist ein Beispiel für eine ereignisgesteuerte Anwendung. Wenn Sie Word starten, macht es gar nichts. Es sitzt nur rum und wartet darauf, dass ein Ereignis eintritt – zum Beispiel, dass Sie mit der Maus klicken, eine Taste drücken oder irgendetwas machen (natürlich sitzt es manchmal auch dann nur einfach herum, wenn Sie etwas gemacht haben … aber das ist eine andere Geschichte).
Scripte sind im Gegensatz dazu prozedurgesteuert. Nachdem Sie gestartet wurden, warten sie gewöhnlich nicht auf ein Ereignis – sie werden stattdessen einfach Zeile für Zeile ausgeführt. Wenn die letzte Zeile ausgeführt wurde, wird das Script automatisch beendet.
Solange alles korrekt funktioniert, ist das auch ganz prima. Es macht jedoch dann Probleme, wenn die Dinge nicht genau wie geplant laufen. Stellen Sie sich zum Beispiel vor, Ihr Script macht folgendes:
| • | Erstellen einer Textdatei auf dem lokalen Computer |
| • | Abfragen von Hardwareinformationen auf mehreren Servern |
| • | Schreiben der Informationen in die Textdatei |
| • | Kopieren der Textdatei auf eine Remotemaschine |
| • | Löschen der Textdatei vom lokalen Computer |
Sie starten das Script, und nach nur einem Augenaufschlag ist das Script fertig. Das kommt Ihnen komisch vor. Sie suchen also nach der lokalen Textdatei, aber die ist nicht da. Das ist so weit OK – das Script sollte die lokale Datei ja löschen. Jetzt suchen Sie auf dem Remotecomputer nach der Textdatei – diese ist jedoch auch nicht da. Oh, oh … da ist offensichtlich was schief gelaufen. Aber was? Und wo? Obwohl das Script relativ simpel ist, gibt es eine Menge Stellen, an denen es fehlschlagen kann. Wie finden Sie also heraus, wo das Problem aufgetreten ist?
Anmerkung: Wir gehen davon aus, dass Sie den Befehl On Error Resume Next im Script verwenden (um das Script vor Abstürzen zu schützen). Außerdem würde auch ohne On Error Resume Next nicht unbedingt klar sein, wo der Fehler aufgetreten ist. Sehen Sie sich zum Beispiel dieses Script an:
intMyNumber = 2 Wenn Sie das Script ausführen, erhalten Sie in Zeile 4 einen Fehler (Sie versuchen eine Division durch Null). Zeile 4 ist allerdings nicht das wirkliche Problem. Tatsächlich liegt dies nämlich in Zeile 2, in der Sie die Variable A auf den Wert Null statt auf zwei setzten. Aufgrund eines Tippfehlers weisen Sie A Hier den Wert der Variable intNumbr statt den der Variable intNumber zu. Da intNumbr keine Wert hat, hat A logischerweise statt dem erwarteten Wert 2 den Wert 0. Zugegeben – dieser Fehler ist leicht zu finden. Es sollte Ihnen aber trotzdem klar sein, dass Fehlermeldungen Ihnen nur mitteilen, in welcher Zeile der Fehler sichtbar wird (wo er also tatsächlich ein Problem verursacht). Der Grund für den Fehler (zum Beispiel das Setzen einer Variable auf 0) kann schon hunderte Zeilen weiter oben aufgetreten sein. |
Ein Weg, um solche Probleme zu beheben, besteht darin, den Code mit dem Script-Debugger schrittweise auszuführen. "Schrittweise" bedeutet, dass Sie den Code einfach Zeile für Zeile ausführen. Abhängig von der Größe des Scriptes kann dieses Verfahren allerdings recht mühsam sein (wir zeigen Ihnen gleich eine Möglichkeit, dies zu vereinfachen). Andererseits haben Sie bei der schrittweisen Ausführung die Möglichkeit, jederzeit anzuhalten und die korrekte Arbeitsweise jedes einzelnen Schrittes des Scripts zu überprüfen.
Unser hypothetisches Script von vorhin soll zum Bespiel damit beginnen, eine Textdatei auf dem lokalen Computer zu erstellen. Wenn wir das Script normal ausführen, dann können wir nicht feststellen, ob das Script die Textdatei erstellt. Wenn wir aber den Code schrittweise ausführen, dann ist dies ganz leicht. Wir führen die Zeile aus, in der die Textdatei erstellt werden soll, und halten dann an. Danach schauen wir mit dem Windows-Explorer nach, ob die Textdatei vorhanden ist. Wenn das der Fall ist, dann führen wir die restlichen Schritte des Scriptes aus. Wenn nicht, dann haben wir mindestens eine Fehlerquelle im Script gefunden.
Also, wie gehen Sie nun den Code schrittweise im Debugger durch? Das ist wirklich ganz einfach: Laden Sie das Script in den Debugger und drücken Sie F8. Jedes Mal, wenn Sie F8 drücken, führt der Debugger eine Codezeile aus, springt zur nächsten Zeile und wartet auf das nächste Drücken auf F8 (wenn Sie keine Tastaturbefehle mögen, können Sie übrigens auch im Menü Debug auf Step Into klicken). Drücken Sie einfach F8, bis das Ende des Scriptes erreicht ist. Alternativ können Sie das Script auch ab der aktuellen Zeile am Stück ausführen. Hierzu drücken Sie F5 oder klicken im Menü Debug auf Run.
Vorsicht: Lassen Sie uns einmal annehmen, Sie debuggen ein Script, das Ereignisse aus dem Ereignisprotokoll über eine For/Each-Schleife abruft. Lassen Sie uns weiter annehmen, dass sich 5.000 Ereignisse im Ereignisprotokoll befinden. Wenn Sie den Code schrittweise ausführen, wird die Schleife in diesem Fall logischerweise nicht einmal, sondern 5.000-mal durchlaufen – einmal für jedes Element der Collection. In so einer Situation kann es sinnvoller sein, die Schleife nur 1- oder 2-mal schrittweise zu durchlaufen (um zu überprüfen, ob sie korrekt funktioniert) und dann den Rest der Schleifendurchläufe und des Scriptes mit F5 komplett abzuarbeiten. Alternativ können Sie auch Breakpoints verwenden – darüber werden wir aber gleich erst sprechen. |
Eins und weg
Eine letzte Eigenart des Debuggers sollten Sie noch kennen lernen. Sie haben das Script durchlaufen, und alles scheint in Ordnung zu sein. Trotzdem sagen Sie sich, "besser sicher gehen". Sie möchten das Script also noch einmal durch den Debugger jagen – nur um sicher zu sein. Das ist zwar grundsätzlich kein Problem – jedoch müssen Sie den Debugger schließen und das Script neu in den Debugger laden. Aus irgendeinem Grund haben Sie im Script-Debugger leider nur jeweils einen Versuch. Sobald das Script beendet ist, müssen Sie den Debugger beenden und mit der ganzen Prozedur von vorn anfangen.
Schon klar, Sie brauchen nichts zu sagen. Und wenn es Ihnen ein Trost ist – wir finden das auch nicht sonderlich praktisch. Sie wurden aber wenigstens gewarnt - der Schweinsfuß-Nasenbeutler hat es hingegen nicht einmal kommen sehen.
Setzen und Entfernen von Breakpoints
Sagen wir, Sie haben ein Script mit 1.000 Zeilen und möchten dies Zeile für Zeile durchgehen. Alles läuft prima, bis Sie in Zeile 933 ankommen – hier finden Sie einen Fehler. Sie halten den Debugger an und korrigieren das Script. Jetzt müssen Sie das Script erneut in den Debugger laden und es wieder ausführen. Natürlich haben Sie keine Lust, die ersten 932 Zeilen durchzugehen. Sie haben ja schon festgestellt, dass diese korrekt sind. Was können Sie also machen?
Als neukaledonische Krähe hätten Sie jetzt wahrscheinlich keine Wahl, aber als Mensch sind Sie clever genug, einen Breakpoint in Zeile 933 zu setzten. Was ein Breakpoint ist, wollen Sie wissen? Im Grunde ist ein Breakpoint nichts anderes als ein Stoppschild, das Sie in Ihren Code einfügen. Wenn Sie das Script im Script-Debugger ausführen (mit F5 oder über Run im Menü Debug), dann wird das Script nur bis zum nächsten Breakpoint ausgeführt – dort hält es an. Jetzt können Sie die weiteren Zeilen Schritt für Schritt mit F8 (oder mit Run) durchgehen.
Sie erkennen die Breakpoints im Script Debugger ganz einfach. Sie sehen so aus:
Anmerkung: Sowohl die rot unterlegte Zeile als auch das Stoppschild markieren den Breakpoint. |
Wie setzten Sie nun einen Breakpoint? Bewegen Sie den Cursor einfach in die entsprechende Zeile und drücken Sie F9 (oder klicken Sie im Menü Debug auf Toggle Breakpoint). Um den Breakpoint zu entfernen, drücken Sie einfach erneut F9 (mit Strg-Hochstell-F9 können Sie alle Breakpoints im Script auf einen Schlag löschen).
Wie Sie vielleicht bereits bemerkt haben, sind Breakpoint eine schöne Alternative dazu, den Code Zeile für Zeile durchzugehen. Sie sind überzeugt, dass die ersten 932 Scriptzeilen korrekt sind? Kein Problem: Setzten Sie einfach einen Breakpoint in Zeile 933 und starten Sie das Script.
Arbeiten mit Variablen
Wie wir bereits angemerkt haben, sind Variablen mit falschen oder unerwarteten Werten Probleme, die immer wieder in Scripten auftauchen. Was diese Sache so mühsam macht, ist, dass solche Fehler sehr schwer zu finden sein können – besonders dann, wenn das Script lang ist und sich der Wert der Variablen mehrmals ändert. Wie können Sie also den aktuellen Wert einer Variablen zur Laufzeit des Scriptes verfolgen?
Eine Möglichkeit ist es, das Script Schritt für Schritt im Debugger durchzugehen und den Wert der Variable regelmäßig im Debugger abzufragen.
Lassen Sie uns das mit einem einfachen Script probieren. Das folgende Script weist Variable A den Wert 2 und Variable B den Wert 3 zu. Dann führt es einige Berechnungen durch und weist Variable C das Ergebnis der Berechnungen zu.
A = 2
B = 3
C = A + B
C = C * A
C = C^B
Wscript.Echo C
Wenn Sie das Script ausführen, sollte es den Wert 1.000 ausgeben. Super… oder nicht? Ist 1.000 wirklich das Ergebnis, das Sie erwartet haben? Wer weiß? Noch schlimmer: Wie sollen Sie überhaupt feststellen, ob 1.000 die richtige Ausgabe ist?
Eine Maßnahme wäre es, das Script in den Debugger zu laden, es Schritt für Schritt durchzugehen, und dann regelmäßig den Wert aller Variablen abzufragen. Machen Sie das doch einfach mal: Laden Sie das Script in den Debugger und gehen Sie die ersten drei Zeilen durch. Jetzt sollte die Zeile C = C * A markiert sein. Der Debugger sollte so wie in der folgenden Abbildung aussehen:
Funktioniert unser Script also so weit? Wir können das überprüfen. Immerhin wissen wir, dass A den Wert 2 und B den Wert 3 hat. Außerdem haben wir gerade die Zuweisung C = A + B ausgeführt (mit anderen Worten C = 2 + 3 – was bedeutet, dass C den Wert 5 haben sollte). Wir wissen das. Aber weiß unser Script das auch?
Fragen wir es einfach. Klicken Sie im Menü View auf Command Window. Jetzt sollte dieses Fenster angezeigt werden:
Über das Command Window können wir mit dem Script interagieren – wie wir zum Beispiel gleich sehen werden, können wir Fragen stellen oder Befehle an das Script senden. Fragen wir also als erstes nach dem aktuellen Wert von Variable C. Hierzu verwenden wir den folgenden Befehl:
? C
Geben Sie im Command Window also ? C ein und drücken Sie die EINGABETASTE; Sie sollten den aktuellen Wert der Variable C erhalten:
Ist das cool oder was? Jetzt drücken Sie F8, um die nächste Scriptzeile abzuarbeiten (C = C * A). Wir wissen, dass C den Wert 5 und A den Wert 2 haben. Konsequenterweise sollte C nach der Codezeile den Wert 10 haben (5 * 2). Lassen Sie uns das also überprüfen:
Wow! – das könnten wir den ganzen Tag tun, oder? Führen Sie die nächste Codezeile aus (C = C^B). Nun sollte C den Wert 1.000 haben: 10 (der aktuelle Wert von C) hoch 3 (B hat schließlich den Wert 3) ist 1.000. Und? Raten Sie mal:
Kann es noch etwas Besseres geben?
Ausführen von Scriptbefehlen
Also, kann es etwas Besseres geben, als ein Script während dessen Ausführung abfragen zu können? Nein, natürlich nicht … es sei denn, Sie könnten einen Befehl an das Script übergeben.
Sehen wir uns ein weiteres einfaches Script an. Es gibt Informationen zu Internet Explorer-Add-On-Komponenten zurück:
strComputer = "atl-ws-01"
Set objWMIService = GetObject("winmgmts:\\" & strComputer _
& "\root\cimv2\Applications\MicrosoftIE")
Set colIESettings = objWMIService.ExecQuery _
("Select * from MicrosoftIE_Object")
For Each strIESetting in colIESettings
Wscript.Echo "Code base: " & strIESetting.CodeBase
Wscript.Echo "Program file: " & strIESetting.ProgramFile
Wscript.Echo "Status: " & strIESetting.Status
Next
Das Script verbindet sich mit einem Remotecomputer (atl-ws-01) und fragt Informationen über die Klasse MicrosoftIE_Object class ab. So weit so klar? Wir wollen das Script nun testen und laden es daher in den Debugger. Dann drücken wir F8 und führen die erste Codezeile aus. Diese setzt die Variable strComputer auf den Wert atl-ws-01.
Genau zu diesem Zeitpunkt fällt uns etwas ein – der Computer atl-ws-01 ist offline. Da keine Verbindung zu dem Computer aufgebaut werden kann, muss das Script also fehlschlagen. Müssen wir den Script-Debugger also beenden, das Script ändern und das Script neu in den Debugger laden?
Nein. Wo liegt das Problem bei unserem Script? Wir wollen eine Verbindung zu dem Computer aufbauen, dessen Name in Variable strComputer gespeichert ist. Dieser ist jedoch offline. Wir müssen also nur den Computernamen in strComputer ändern – und zwar bevor wir die Codezeile ausführen, in der die Verbindung zum Remotecomputer aufgebaut wird. Wir könnten den Wert von strComputer zum Beispiel auf "." ändern (was für die lokale Maschine stehen würde).
Wahrscheinlich haben Sie es sich schon gedacht: Wir können das über das Command Window erledigen:
Geben Sie einfach den entsprechenden Befehl im Command Window ein und drücken Sie die EINGABETASTE. Der Wert von Variable strComputer in Ihrem Script wird sofort auf "." geändert.
Natürlich können Sie auch komplexere Befehle eingeben. Sehen Sie sich beispielsweise das folgende Script an. Es soll die Namen aller auf dem lokalen Computer installierten Dienste zurückgeben:
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer _
& "\root\cimv2")
For Each objItem in colItems
Wscript.Echo "Name: " & objItem.Name
Next
Ziemlich simpel, oder? Eine Sache stimmt leider nicht: Es fehlt eine Codezeile, mit der die Informationen über die Klasse Win32_Service abgerufen werden. Das Script sollte so aussehen:
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer _
& "\root\cimv2")
Set colItems = objWMIService.ExecQuery _
("Select * From Win32_Service")
For Each objItem in colItems
Wscript.Echo "Name: " & objItem.Name
Next
Aber kein Problem. Laden Sie das Script einfach in den Debugger und führen Sie die ersten zwei Zeilen aus. Wenn Sie bei der fehlenden dritten Zeile angelangt sind, geben Sie diese einfach im Command Window ein und drücken Sie die EINGABETASTE:
Jetzt führen Sie den Code einfach weiter aus, und das Script gibt alle Dienstnamen korrekt aus.
Das Sahnehäubchen
Jetzt gibt es noch etwas wirklich cooles. Das Command Window wurde so entwickelt, dass immer nur eine Codezeile ausgeführt wird. Was machen wir also, wenn drei Codezeilen vergessen wurden (zum Beispiel eine For/Each-Schleife)? "Kein Thema", denken Sie? Sie geben einfach die drei fehlenden Zeilen nacheinander ein? In einigen Fällen klappt das sicher, aber in diesem Fall nicht. Wenn Sie die erste Zeile einer For/Each-Schleife eingeben und die EINGABETASTE drücken, dann passiert dies:
Warum? Sie haben ganz einfach eine For/Each-Schleife ohne Next erstellt (Sie hatten nicht wirklich eine Chance, das Next einzugeben – im Command Window ist ja immer nur eine Codezeile möglich). Also Pech gehabt?
Nein (schon wieder). Es zeigt sich, dass Sie mit VBScript mehrere Codezeilen zu einer einzelnen Zeile zusammenfassen können. Und zwar indem Sie die einzelnen Zeilen durch einen Doppelpunkt (:) trennen. Wir können die gesamte For/Each-Schleife zum Beispiel in eine Zeile schreiben:
For Each objItem in colItems:Wscript.Echo "Name: " & objItem.Name:Next
Und jetzt geben Sie diese Zeile einfach in das Command Window ein und drücken die EINGABETASTE:
Müssen Sie das alles wissen? Brauchen Sie das alles? Vielleicht nicht – aber vor einigen Monaten haben Sie vielleicht auch noch geglaubt, dass Sie diesen ganzen Scripting-Kram niemals brauchen.
Ein letztes Wort
Als Mitglieder der menschlichen Rasse hassen wir es, das zugeben zu müssen, aber möglicherweise werden wir Bugs niemals ganz ausrotten können. Den peruanischen Kondor? Klar – den kriegen wir klein. Aber Computer-Bugs? Nicht sehr wahrscheinlich – es gibt einfach zu viele von ihnen.
Andererseits heißt das nicht, dass wir nicht einzelne Bugs erledigen können. Zum Beispiel die, die in unseren Scripten lauern. Und wenn wir Tools wie den Microsoft Script-Debugger dazu nutzen müssen, dann ist das keine Schande. Wenn es eine Möglichkeit für die Computer-Bugs gäbe ein solches Tool gegen uns einzusetzen …
Geben Sie den Script-Debugger also eine Chance, und lassen Sie uns wissen, was Sie davon halten.
Haben Sie Fragen oder Bemerkungen zu dieser Kolumne? Schicken Sie sie an scripter@microsoft.com (bitte in Englisch). Aufgrund der Mail-Flut, die wir jeden Tag erhalten, fällt es uns schwer, auf jede einzelne Anfrage zu antworten – aber wir lesen wirklich jede eingehende E-Mail.
Zusätzliche Informationen
| • |