Sie sind hier: Startseite

Art der Veröffentlichung: Zeitschriftenbeitrag
Titel der Veröffentlichung: Scripting Kolumne Teil 2: WSH-Skripte unter Kontrolle - Windows Administration mit dem Windows Script Host (WSH)
Medium: Windows IT Pro (Windows 2000 Magazin)
Erscheinungsjahr: 2005
Ausgabe: 07/2005
Autor(en): Dr. Holger Schwichtenberg
Verlag: Konradin IT-Verlag
Ort des Verlages: München
Anzahl Seiten: 3
Link zu weiteren Informationen: http://www.netigator.de/netigator/live/fachartikelarchiv/ha_artikel/powerslave,id,30473775,obj,WM,np,archiv,ng,,thes,.html
Link zum Verlag: http://www.windowsitpro.de
Link zur Bestellung: n/a
Abstrakt: Skripting-Kolumne im Windows 2000 Magazin WSH-Skripte unter Kontrolle Der Windows Script Host (WSH) gehört inzwischen zum Standardinstallationsumfang der Windows-Clients. Auch Microsoft selbst liefert immer mehr administrative Werkzeuge als WSH-Skripte aus. Das Windows 2000 Magazin widmet sich in der zweiten Ausgabe der Skripting-Kolumne ganz der Frage, welche Optionen bei der Ausführung von Skripts mit dem WSH bestehen. Inzwischen bietet Microsoft bereits die dritte Version des WSH an. In Windows 98 wurde der WSH in der Version 1.0 mitgeliefert, während ME sowie Windows-2000-Clients und -Server den Kommandointerpreter als Version 2.0 mitbekamen. In Windows XP und Windows Server 2003 ist nun schließlich der WSH 5.6 enthalten. Die Versionsnummernreihenfolge 1.0, 2.0 und dann 5.6 kann man zwar nicht nachvollziehen, aber zwischen Version 1.0 und Version 2.0 hat Microsoft eine kleine, aber entscheidende Namensänderung vollzogen: Die Bezeichnung änderte sich von „Windows Scripting Host“ zu „Windows Script Host“, womit wohl eine Abgrenzung zwischen dem allgemeinen Begriff „Scripting Host“ und dem WSH vollzogen werden sollte. So sprechen die Insider die Abkürzung „WSH“ dann häufig auch als „Wish“ aus. Den WSH 5.6 kann man aber problemlos auf den Betriebssystemen Windows 95 und Windows NT 4.0 nachrüsten, die ja ursprünglich gar keinen WSH enthielten [1]. Gegenüber der ursprünglich mit Windows XP ausgelieferten Version hat Microsoft auch einige Fehler behoben [2]. Wer den WSH testen will kann dies mit einem Einzeiler tun, der gleichzeitig auch seine Versionsnummer ermittelt: Diese wird dabei von dem Attribut „Version“ aus dem eingebauten Objekt „WScript“ geliefert. Wenn man den nachfolgenden einzeiligen Code in eine Textdatei packt, der Datei die Extension „.vbs“ verleiht und dann mit einem Doppelklick startet, wird die folgenden Meldung auf dem Schirm erscheinen: WScript.Echo „Dies ist der „ & WScript.Name & „ Version „ & WScript.Version Schon dieses sehr einfache Beispiel zeigt, dass WSH-Skripte wie eine normale Windows-Anwendung gestartet werden können. Das bedeutet, dass folgende Startmöglichkeiten zur Verfügung stehen: · durch Doppelklick auf die Skriptdatei beziehungsweise auf „Öffnen“ im Kontextmenü, · durch „Drag&Drop“ beliebiger Dateien auf das Icon einer Skriptdatei (seit WSH 2.0), · über das Kontextmenü einer jeden Datei im Windows Explorer oder auf dem Desktop, · direkt auf der Windows-Kommandozeile und · automatisiert durch den Taskscheduler. Genau genommen handelt es sich beim WSH nicht nur um einen Scripting-Host, sondern er umfasst zwei eng verwandte Scripting Hosts: WScript und Cscript. Beide Scripting-Hosts sind hinsichtlich ihres Befehlsumfangs fast gleich. Die Tabelle auf der Seite 14 zeigt die Unterschiede zwischen den beiden Hosts: So unterscheiden sie sich unter anderem darin, dass die Ausgaben auf anderen Kanälen erfolgen. Zudem sind die eingebauten Objekte von CScript etwas wenig mächtiger als die von WScript. Beide Scripting-Hosts sind aber in der Lage, die gleichen COM-Objekte und die gleiche Sprachsyntax zu nutzen. Bei WScript (implementiert in WScript.exe) erfolgt die Ausführung als Windows-Anwendung, wobei alle Ausgaben in Form von Dialogboxen dargestellt werden. Handelt es sich nun um ein Skript, das sehr viele Ausgaben macht, so kann diese Verhaltensweise sehr lästig werden, da jede Dialogbox einzeln bestätigt werden muss. Zudem ist jede Dialogbox modal: Das bedeutet, dass dieses Skript anhält und auf die Bestätigung wartet. WScript eignet sich also für die unbeaufsichtigte Ausführung nur dann, wenn das Skript keine Ausgaben macht. Gut geeignet ist WScript jedoch dann, wenn der Benutzer über jeden einzelnen Schritt informiert werden und dabei die jeweils erfolgten Veränderungen überprüfen möchte (also beispielsweise beim Debugging von Skripten). Bei CScript (implementiert in CScript.exe) erfolgt die Ausführung des Skripts im Kontext eines Kommandozeilenfensters (auch: Konsole oder DOS-Box). Dabei hängt dann die Form der Ausgabe von den verwendeten Ausgabebefehlen ab: Alle Ausgaben über die Methode „Echo()“ aus dem WSH-Intrinsic-Object „WScript“ erfolgen direkt im Kommandozeilenfenster. Hingegen werden die Ausgaben, die spracheigenen Ausgabemethoden (beispielsweise „MsgBox()“ in VBScript) verwenden, auch weiterhin als modale Dialogboxen dargestellt. Ein großer Vorteil beim Einsatz von CScript besteht darin, dass es mit der Methode „WScript.StdIn.ReadLine()“ möglich ist, das Einlesen von Eingaben des Benutzers im DOS-Fenster zu unterstützen. Die Ausgaben können dabei mit dem DOS-Befehl für Umleitungen (>) in eine Textdatei oder an einen Drucker umgeleitet werden. CScript besitzt außerdem den weiteren Vorteil, dass die Skriptausführung mit (STRG)+(C) jederzeit vom Benutzer abgebrochen werden kann. Bei WScript hilft – wenn modale Dialogboxen angezeigt werden – nur das Beenden der Anwendung mit Hilfe des Windows Task-Managers. An der Kommandozeile, im Task-Scheduler und bei Verknüpfungen im Dateisystem hat der Windows-Benutzer die explizite Wahl, ob CSCRIPT.EXE oder WSCRIPT.EXE gestartet wird: cscript scriptname.extension [option...] [arguments...] wscript scriptname.extension [option...] [arguments...] Ein Skript wird aber nicht deshalb automatisch mit CScript gestartet, weil man es an der Kommandozeile startet. Da Wscript auf den Windows-Systemen als Standardeinstellung voreingestellt ist, muss CScript ausdrücklich voreingestellt werden, wenn es zum Einsatz kommen soll. Ein solcher Aufruf muss dann beispielsweise: cscript.exe lauten, da ansonsten WScript als Standard-Scripting-Host gestartet wird. Allerdings ist es recht leicht, CScript stattdessen zum Standard zu erheben. Dies geschieht einfach durch Eingabe der folgenden Zeile: C:>cscript //H:cscript Die Arbeit der WSH kann durch die Angabe von Kommandozeilenoption beeinflusst werden. Eine Auflistung dieser Optionen ist im Kasten auf dieser Seite zu finden. Dabei werden die Optionen als eine Besonderheit hier mit dem doppelten Slash (//) übergeben. Die Notwendigkeit dafür ergibt sich aus der Tatsache, dass ein einfacher Schrägstrich (/) dazu dient, Argumente direkt an das ablaufende Skript zu übergeben. Erst dadurch dass die entsprechenden Befehle mit einem Doppel-Schrägstrich übergeben werden, „weiß“ der WSH, dass die Option für ihn gilt. Wenn es um Anpassung des WSH an die eigenen Vorstellungen geht, so existieren auch in der Registry einige Konfigurationseinträge für den WSH. Diese Einträge sind leider etwas verstreut unterhalb der folgenden Schlüssel zu finden: 1. HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows Script Host 2. HKEY_LOCAL_MACHINESoftwareMicrosoftWindows Scripting Host 3. HKEY_CURRENT_USERSoftwareMicrosoftWindows Script 4. HKEY_CURRENT_USERSoftwareMicrosoftWindows Script Host Wie bereits an den Schlüsselnamen zu erkennen ist, gibt es sowohl systemweite als auch benutzerspezifische Einstellungen. So legt beispielsweise der Eintrag HKEY_LOCAL_MACHINESOFTWAREMicrosoft Windows Script HostSettingsIgnoreUserSettings fest, ob die benutzerspezifischen Einstellungen die systemweiten Einstellungen überlagern dürfen oder ob die benutzerspezifischen Einstellungen ignoriert werden. Die Tabelle im Kasten auf dieser Seite zeigt die wichtigsten Registry-Einträge für den WSH. So lässt sich beispielsweise mit dem Eintrag HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows Script HostSettingsEnabled der WSH komplett deaktivieren. Wenn dieser Eintrag auf „0“ steht, kann kein WSH-Skript mehr ausgeführt werden. Ein Aufruf von CScript.exe oder WScript.exe führt dann zu folgender Fehlermeldung: „Windows Script Host access is disabled on this machine. Contact your administrator for details.“ Die Programmiersprache eines WSH-Skripts wird meistens durch die Dateiextension festgelegt: „.vbs“ für Visual Basic Script, „.js“ für JScript und „.pls“ für die Active Scripting-Variante von Perl. Eine Ausnahme bilden dabei die „.wsf“-Dateien. Dateien dieses Typs enthalten ebenfalls Skripte für den WSH. In einer XML-Form kann eine „.wsf“-Datei aber beliebig viele Skripte in verschiedenen Programmiersprachen enthalten, die einzeln gestartet werden, sich aber auch gegenseitig aufrufen können. Schon seit WSH 1.0 existieren zusätzlich auch Dateien mit der Dateiextension „.WSH“. Dabei handelt es sich um Konfigurationsdateien für WSH-Skripte, ganz ähnlich den bekannten „.pif“-Dateien für DOS-Batch-Dateien. Man erzeugt eine „.WSH“-Datei, indem man im Explorer oder auf dem Desktop die Eigenschaften einer Skriptdatei (.wsf, .vbs, .js, .pls, und so weiter) betrachtet. Wenn dort die Einstellungen für Timeout und Logo geändert werden, wird automatisch im selben Verzeichnis eine gleichnamige Datei mit der Extension „.wsh“ erzeugt, die eine Verknüpfung zu der Skriptdatei besitzt. Diese Einstellungen sind äquivalent zu den WSH-Kommandozeilenoptionen „//T“, „//LOGO“ und „//NOLOGO“. (fms) von Dr. Holger Schwichtenberg
Verweise: n/a

Downloads zu dieser Veröffentlichung

Leider keine Dateien vorhanden.