• Programme starten bzw. fern steuern
  - Befehlsinterpreter (DOS-Eingabeaufforderung)
  - WSHShell.Run-Methode
  - WSHShell.Exec-Methode

• 'SendTo' an ein Skript
• Argumente aus Batch-Aufrufen
• Datei(en) auf Skript ziehen und fallen lassen (Argumente)
• Leerzeichen im Dateinamen und Anführungszeichen in Zeichenketten

• WSH/VBS im Vergleich zu anderen Skriptsprachen - welche ist besser?


Zu einigen Skripten sind Funktionsbeschreibungen verfügbar:
Datei-Verzeichnis-Liste.vbs
deltree.vbs
CDdurchsuchen.vbs
CD-Menu.vbs
scriptinfo.vbs von md-doc.de
 
↑ Zum Seitenanfang ↑

Programme starten bzw. fernsteuern

Nicht für alle Aufgaben, die man mit einem Skript lösen will, gibt es die erforderlichen Objekte und Methoden. Da die 'Windows Script - Technologien' Erweiterungen des Betriebssystems sind, lassen sich viele zum Betriebssystem gehörenden Programme verwenden - natürlich auch viele zusätzlich installierte Programme.

So kann z.B. das notepad oder der InternetExplorer die Anzeige von Protokolldateien übernehmen. Für Netzwerkoperationen gibt es zwar einige Methoden (z.B. MapNetWorkDrive), aber längst nicht alle Funktionen, wie sie der NET-Befehl so nett bereit stellt, sind verfügbar. Darüber hinaus lassen sich auch vorhandene oder selbst geschriebene ActiveX-Komponenten, OCX'e, ADSI oder WMI nutzen.

Die folgenden Erläuterungen bauen auf die Informationen aus der 'Windows Script'-Hilfe auf und beschränken sich auf die Verwendung der 'einfachen' Varianten:
    - Befehlsinterpreter
    - WSHShell.Run-Methode
    - WSHShell.Exec-Methode

Mit der WSHShell.Run-Methode können neben Programmen (z.B. 'notepad.exe') auch Dokumente (z.B. 'c:\index.html' oder 'readme.txt') gestartet werden. Um Befehlszeilenkommandos (z.B. 'ping') aufzurufen und deren Ausgaben auszuwerten, werden diese mit der WSHShell.Run-Methode gestartet, wobei durch Aufrufparameter ('ping 127.0.0.1 > c:\dir.txt') eine Umleitung der Ausgaben in eine Text-Datei erfolgen kann. Anschließend läßt sich diese Text-Datei unter anderem einlesen und somit auswerten.

Bei der WSHShell.Exec-Methode können Programme die Ausgaben direkt an Skriptvariablen übergeben - der Umweg über eine Datei entfällt also.

Der Nachteil der WSHShell.Exec-Methode: es erscheint immer ein (leeres) schwarzes Fenster. Für die WSHShell.Run-Methode stehen Parameter zur Verfügung, mit der sich das unterbinden läßt.

Der Vorteil der WSHShell.Exec-Methode: das gestartete Programm kann gezielt abgebrochen werden (kill). Dieses gezielte Abbrechen ist nützlich, wenn eine Anwendung entweder sofort (z.B. in 3 Sekunden) ein Ergebnis liefert oder erst nach 10 Minuten (z.B. wegen fehlerhafter Netzverbindung) aufgibt - man kann die Anwendung nach 10 Sekunden abbrechen.
 
↑ Zum Seitenanfang ↑

Programme starten - Befehlsinterpreter

Jedes Betriebssystem verfügt über Befehlszeilenkommandos (copy, xcopy, find, attrib, net), die ohne grafische Oberfläche auskommen; in einem 'schwarzen' Fenster, der Eingabeaufforderung (häufig auch Dos-Box genannt). Zum Teil sind sie gerade deshalb so schnell.

Wie in DOS (DR-DOS, IBM-DOS, MS-DOS, ... ) gibt es interne und externe Befehle, d.h. einige Befehle sind im 'Lieferumfang' des Betriebssystems enthalten und werden als .exe oder .com (externe Befehle; z.B. xcopy) mitgeliefert. Andere Befehle sind als interne Befehle (z.B. copy) in dem Befehlsinterpreter command.com (Win9x/ME) bzw. cmd.exe (WinNT2k/XP) integriert.

Die Befehlszeilenkommandos setzen einen Befehlsinterpreter voraus, der betriebssystemabhängig ist: command.com für Win9x/ME und cmd.exe für WinNT/2k/XP. Die command.com bzw. cmd.exe öffnet das typisch schwarze Fenster und fordert durch den blinkenden Cursor zu einer Eingabe auf; das ist die Eingabeaufforderung bzw. der DOS-Prompt. Eingaben werden mit einem [Enter] abgeschlossen, wodurch der Befehlsinterpreter 'weiss', dass er ein Programm (oder ähnliches) abzuarbeiten hat. Zunächst muss er das Programm finden, wenn es nicht genau mit seinem Speicherort (z.B. c:\windows\scandisk) angegeben ist. Dafür durchsucht er alle Verzeichnisse, die er durch die Angaben in der Umgebungsvariablen Path erreichen kann und startet das erst beste Programm, das er findet. Path, gefolgt von einem [Enter] in der Eingabeaufforderung eingegeben, gibt die in Path hinterlegten Informationen aus. Ändern kann man diese Variable durch Path=c:\dos und erweitern durch Path=%Path%;c:\dos. (Das %Path% gibt den Inhalt der Path-Umgebungsvariablen zurück.) Die Änderungen gelten nur in der Eingabeaufforderung, in der sie vorgenommen und solange sie nicht geschlossen wurde.

Nach dem Befehlsaufruf überprüft der Befehlsinterpreter als erstes, ob es sich um einen internen Befehl handelt (Eine copy.exe hat also keine Chance.). Ist dies nicht der Fall, durchsucht der Befehlsinterpreter die Path-Pfade der Reihe nach, ob es Dateien mit den Endungen .bat, .com und .exe (und .cmd bein WinNT2k/XP) gibt, um diese zu starten. Die erste Datei, die diese Bedingung erfüllt, versucht das Betriebssystem dann auszuführen. Gibt es in einem Verzeichnis eine test.bat, eine test.cmd, eine test.com und eine test.exe, wird die test.com ausgeführt; sonst die test.exe. Beim Aufruf von test wird test.cmd nur ausgeführt, wenn es die anderen Varianten in diesem Verzeichnis nicht gibt. Die Reihenfolge ist also: interner Befehl, .com, .exe, .bat (.cmd).

Eine Besonderheit stellen die Dateien mit der Endung .bat und .cmd dar: das sind Batch- bzw. Stapelverarbeitungsdateien. Sie sind reine Text- bzw. ASCII-Dateien, in denen in jeder Zeile (Befehlszeilen-) Kommandos stehen, also .bat, .com, .cmd oder .exe oder interne Befehle.

Typisch für die meisten Befehlszeilenkommandos ist, dass sie nur dann vernünftige Arbeit leisten, wenn ihnen per Aufruf- bzw. Befehlszeilenparameter die Aufgaben beim Starten auch mitgeteilt werden. Um einer Fehlermeldung bei xcopy vorzubeugen, sollte natürlich z.B. Quell- und Zielverzeichnis an den xcopy -Befehl mit übergeben werden: xcopy c:\temp d:\temp. Welche Parameter von einem Befehl unterstützt werden, wird häufig durch Eingabe des Befehls gefolgt von ' /? ' angezeigt: z.B. xcopy /? .

Um in einem Skript zu prüfen, ob ein Befehlszeilenkommando fehlerfrei abgelaufen ist, lassen sich die Ausgaben in eine Datei umleiten (mit einem Pipe-Befehl), um die Protokolldatei per Skript nach Fehlermeldungen zu durchsuchen. Zum testen der Erreichbarkeit eines Servers mit dem Ping-Befehls, werden so die Ping-Ausgaben in einer Datei gespeichert (vergl. Programme starten - WSHShell.Run-Methode):
Durch das > verschwinden die Ausgaben (unter anderem die Zeile Antwort von 10.0.0.44: Bytes=32 Zeit>10ms TTL=128) in einer Datei test.txt. Übrigens: ein > legt immer eine neue Datei an; zwei > erweitern eine vorhandene Datei oder legen eine neue an, wenn es keine gibt.
 
↑ Zum Seitenanfang ↑

Programme starten - WSHShell.Run-Methode

Um andere Programme für WSH/VBScript arbeiten zu lassen, müssen diese gestartet (und deren Ausgaben erfasst bzw. ausgewertet) werden. Dafür stellt der 'Windows Script Host' die WSHShell.Run-Methode des WSHShell-Objekts zur Verfügung: Oder: Wichtig: Das Betriebssystem sucht beim Aufruf von notepad nach einer Datei, die notepad heißt und als Endung .bat, .com, .cmd oder .exe hat (vergl. Programme starten - Befehlsinterpreter).

Das Skript läuft nach dem Start des Programms weiter, ohne darauf zu warten, dass das Programm seine Arbeit beendet hat. Häufig benötigt man aber die Ergebnisse, die das Programm z.B. in eine Datei schreibt. Dazu kann man die .Run-Zeile mit true enden lassen (nach zwei mal Komma) und das Skript 'wartet' auf das Ende des Programms: Weitere Parameter entnehme man der 'Windows Script'-Hilfe.

Mit der WSHShell.Run-Methode lassen sich alle Arten von Programmen starten, aber auch Dokumente. Dann entscheidet das Betriebssystem an Hand der Dateiendung, welche Anwendung gestartet wird.

Durch eine *.rtf-Datei dürfte meistens MS-Word gestartet werden; nur wenn dieses Programm nicht installiert ist, wird das Betriebssystem WordPad bemühen. Alternativ läßt sich gleich Wordpad festlegen:

Man beachte aber Leerzeichen im Dateinamen und Anführungszeichen in Zeichenketten.

Für das Suchen nach Dateien werden in Skripten die (Unter-) Verzeichnisse rekursiv durchsucht. Bei der Erstellung eines Skripts, das die Länge der kompletten Dateinamen aller Dateien auf einem Server überprüfen sollte, fiel mir auf, dass der DIR-Befehl 10 mal schneller als eine Skriptvariante ist (dateinamenlangdir.vbs). Da der DIR-Befehl aber ein interner Befehl (vergl. Programme starten - Befehlsinterpreter) des Befehlsinterpreters command.com bzw. cmd.exe ist, führte
      WSHShell.Run "dir \\dieseyerSrv\d$\*.* /s /b >dir.txt"
nicht zum Ziel. Man muss den Befehlsinterpreter mit aufrufen. Damit das Skript in der Windows-Welt betriebssystemunabhängig wird, verwendet man die Umgebungsvariable Comspec, die je nach Betriebssystem auf command.com bzw. cmd.exe verweist:

 
↑ Zum Seitenanfang ↑

Programme starten - WSHShell.Exec-Methode

ACHTUNG: Die WSHShell.Exec-Methode ist erst seit Okt. 2001 mit den 'Windows Script - Technologien' Version 5.6 verfügbar.

Mit dieser WSHShell.Exec-Methode können Programme ähnlich der WSHShell.Run-Methode gestartet werden. Beim Aufruf von Befehlszeilenkommandos und -programmen gelten die unter Programme starten - Befehlsinterpreter beschriebenen Besonderhheiten.

Um in einem Netzwerk zu testen, ob ein PC oder Server erreichbar ist, wird häufig der ping-Befehl benutzt (von dem die Ausgaben in eine Datei umgeleitet werden). Mit der WSHShell.Run-Methode sieht der Code etwa so aus:

Was im Skript passiert: Mit der WSHShell.Run-Methode wird ping gestartet, wobei die Ausgaben in eine Text-Datei umgeleitet werden. Anschließend wird diese Datei geöffnet, die Zeilen einzeln gelesen und dabei geprüft, ob es in der gelesenen Zeile die Zeichenfolge 'TTL=' gibt. Sind diese Zeichen in einer der gelesenen Zeilen enthalten, wird die Variable PingTest von 'keine Antwort' auf 'Antwort erhalten' gesetzt. (Vergl. Sub-Prozeduren und Function-Prozeduren - eine Einführung.)

Verwendet man die WSHShell.Exec-Methode könnte die Function-Prozedur so aussehen:

Mit Set oExec wird sofort der Aufruf %comspec% /c Ping " & IPtst & " -n 1 -w 500" gestartet. In der nachfolgenden Do .. Loop-Schleife werden die Ausgaben des ping zeichenweise gelesen, bis der Datenstrom (AtEndOfStream) abbreisst (weil ping beendet ist). Enthält dieser Datenstrom an irgend einer Stelle TTL=, hat der Ziel-PC geantwortet.

Alternativ kann man auch auf das Ende des ping-Aufrufes warten und alle Ausgaben auf einen Ruck lesen. Im folgenden kompletten Beispiel-Skript wird die Function zweimal aufgerufen: beim ersten Mal mit einer IP-Adresse und beim zweiten Mal mit dem Namen des Computers, auf dem das Skript läuft. Dadurch, dass der zweite Aufruf einen Computernamen (und keine IP-Adresse) enthält, versucht der Ping-Befehl den Namen in eine IP-Adresse aufzulösen; er bemüht also einen Name-Services (DNS oder WINS). Antwortet der Name-Services nicht schnell genug, wird der Ping-Befehl mit oExec.Terminate abgebrochen (was zu demonstrieren war).


Wer die Beispielskripte zur WSHShell.Exec-Methode bis hier ausprobiert hat, den werden die sich öffnenden und leeren Eingabeaufforderungen (DOS-Boxen) stören. Um diese zu unterdrücken, muss man tief in die Trickkiste greifen. Im Internet habe ich dazu einen Beitrag mit zwei Beispielen gefunden: eine ein-Skript-Variante und eine zwei-Skript-Variante.

Die ein-Skript-Variante startet sich mit CScript.exe (im 'Unsichtbarmodus' und mit Parametern) selbst - bei umfangreichen Skripten muss man das entsprechend am Skriptanfang berücksichtigen. Vorteilhaft ist, dass dafür nur eine (.VBS-) Datei nötig ist.

In der zwei-Skript-Variante ruft das Skript mit CScript.exe ein zweites (universelles) Skript (im 'Unsichtbarmodus' und mit Parametern) auf. Um sicher zu gehen, dass das zweite Skript auch wirklich immer vorhanden ist, müsste man prüfen, ob es vorhanden ist und notfalls vom ersten Skript schreiben lassen. Selbst umfangreichere Skripte dürften dadurch übersichtlicher bleiben. Allerdings erfolgen jetzt wieder Schreibzugriffe auf einen Datentäger, was eigentlich durch Verwendung der WSHShell.Exec-Methode (für z.B. ping) vermieden werden sollte.

Da die zwei-Skript-Variante 'nur' den Error-Code des aufgerufenen Skripts zurück gibt, habe ich zwei Skripte geschrieben, die Ideen beider Varianten in sich vereinen:

^QuellCode> exec-hidden.vbs schreibt bei jedem Aufruf der ExecHidden-Prozedur eine neues Skript ExecHidden.VBS in das %Temp%-Verzeichnis, startes dieses (und CScript.exe die WSHShell.Exec-Methode im 'Unsichtbarmodus') und zeigt die erhaltenen Ausgaben an.

^QuellCode> exec-hidden-plus.vbs schreibt beim Aufruf der ExecHiddenPlus-Prozedur ein neues Skript ExecHiddenPlus.VBS in das %Temp%-Verzeichnis, wenn es dort nicht vorhanden ist. Was das Skript machen soll, erfährt es über die Parameter, mit denen es aufgerufen wird. Natürlich startet das Skript ExecHiddenPlus.VBS (über CScript.exe) die WSHShell.Exec-Methode im 'Unsichtbarmodus' und übergibt die erhaltenen Ausgaben an das aufrufende Skript.

^QuellCode> exec-test.vbs erstellt eine .BAT-Datei, die dann gestartet wird. Dieses Skript demonstriert, wie Ausgaben von Anwendungen ohne GUI 'abgegriffen' und wie Eingaben an diese 'gesendet' werden können.

^QuellCode> ip-adresse3.vbs Damit die IP-Adresse mit IPCONFIG ermittelt werden kann, ohne dass eine Schreiboperation auf einen Datenträger erfolgt, werden im 'unsichtbaren' Aufruf von ^QuellCode> exechiddenplus.vbs alle IPCONFIG-Ausgaben abgefangen.
 
↑ Zum Seitenanfang ↑

'SendTo' an ein Skript

Da Skripte eigentlich 'nur' den Sinn haben, wiederkehrende Aufgaben schnell und präzise (ohne Tippfehler) auszuführen, wird man früher oder später das 'Send To' bzw. 'Senden an' des Windows-Kontextmenüs benutzen wollen. Das geht ganz einfach: das entsprechende Skript muss nur in das 'SendTo'-Verzeichnis kopiert werden. Es steht als Unterverzeichnis neben dem Unterverzeichnis 'Startmenü'. Allerdings gibt es unter WinNT/2k/XP davon mehrere:
C:\Winnt\Profiles\%XXX%\Startmenü       bzw.
C:\Dokumente und Einstellungen\Profiles\%XXX%\startmenü,
wobei %XXX% der Anmeldename eines Benutzers ist, der sich bisher mindestens einmal angemeldet hat, ODER 'All Users' ODER 'Default User' ist.

Ist im 'Senden an' - Kontextmenü ein Skript zu sehen, wird alles 'gesendete' als Argumente bzw. Aufrufparameter an das Skript übergeben - und muss nur noch erfasst werden. Das wird in 'Datei(en) auf Skript ziehen und fallen lassen' erklärt.
 
↑ Zum Seitenanfang ↑

Argumente aus Batch-Aufrufen

Das Beispiel einer BAT-Datei, die als Parameter bzw. Argumente den Inhalt von Umgebungsvariablen an ein Skript übergibt:
. . . und dieses bsp.vbs zeigt die Aufruf-Parameter an:
  ↑ Zum Seitenanfang ↑

Dateien auf Skript ziehen und fallen lassen

Dies entspricht dem 'Drag & Drop', bei dem Argumente in das Ziel 'kopiert' werden. (Bei .BAT-Dateien sind die Argumente über %1..%9 erreichbar). Das (Ziel-) Skript muss also ermitteln, ob und wenn ja wie viele Argumente 'rein gekommen' sind.    
↑ Zum Seitenanfang ↑

Leerzeichen im Dateinamen und Anführungszeichen in Zeichenketten

Etwas schwierig gestaltet sich die Arbeit mit Zeichenketten, die Leerzeichen (Space) enthalten. Bei WSHShell.Run "c:\eigene Dateien\neuer test.rtf" würde MS-Word nicht erkennen, dass der alles zusammen gehört und würde versuchen drei Dateien zu öffnen: c:\eigene, Dateien\neuer und test.rtf. Zieht man mit der Maus diese Datei in das Ausführen-Fenster ([Win-R]), wird "c:\eigene Dateien\neuer test.rtf" (mit Anführungszeichen) übergeben. Nahe liegend ist: WSHShell.Run "wordpad "c:\eigene Dateien\neuer test.rtf"". Jetzt entsteht ein neues Problem: Das Anführungszeichen nach wordpad beendet die Zeichenkette, die mit dem Anführungszeichen vor wordpad begann.

Um in Zeichenketten Anführungszeichen einzufügen, sind zwei Anführungszeichen direkt neben einander zu schreiben. Richtig ist also: Damit leitet das erste Anführungszeichen eine Zeichenkette ein; die nächsten beiden Anführungszeichen fügen in die Zeichenkette ein Anführungszeichen ein; die drei letzten Anführungszeichen fügen in die Zeichenkette ein Anführungszeichen ein und beenden die Zeichenkette.

Bei Zeichenketten-Operationen verhält es sich ähnlich: In der letzten Zeile überraschen die vier aufeinander folgenden Anführungszeichen: das erste leitet eine Zeichenkette ein, die nächsten beiden fügen ein Anführungszeichen (in die Zeichenkette) ein und das letzte beendet die Zeichenkette.

Auf einen (meiner) Fehler bin ich in der MS-NG aufmerksam gemacht worden: "Die einzigen Fälle (IMHO), in welchen Pfade mit zusätzlichen Anführungszeichen umschlossen werden, sind die WshShell.Run- und WshShell.Exec-Methoden. ... Für das FSO ist das Leerzeichen aber ein ganz normales Zeichen, so wie ein Buchstabe." sagte Christoph Basedau.