• 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):
Set WSHShell = WScript.CreateObject("WScript.Shell")
WSHShell.Run "Ping dieseyerSrv > test.txt"
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:
Set WSHShell = WScript.CreateObject("WScript.Shell")
WSHShell.Run "notepad.exe"
Oder:
WScript.CreateObject("WScript.Shell").Run "notepad"
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:
WScript.CreateObject("WScript.Shell").Run "notepad", , True
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.
Set WSHShell = WScript.CreateObject("WScript.Shell")
WSHShell.Run "c:\temp\test.rtf"
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:
Set WSHShell = WScript.CreateObject("WScript.Shell")
WSHShell.Run "wordpad c:\temp\test.rtf"
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:
Set WSHShell = WScript.CreateObject("WScript.Shell")
WSHShell.Run "%comspec% /c dir c:\ /s /b > dir.txt" , , True
WSHShell.Run "dir.txt"
↑ 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:
'**************************************************************
Function PingTest ( IPtst ) ' v2.C - http://dieseyer.de
'**************************************************************
Set WSHShell = WScript.CreateObject("WScript.Shell")
Set fso = WScript.CreateObject("Scripting.FileSystemObject")
File = fso.GetBaseName( WScript.ScriptName ) & ".log"
WshShell.run ("%comspec% /c Ping " & IPtst & " -n 1 -w 500 > " & File ),0,true
' PING nur einmal ausführen => nur eine Zeile mit TTL=
Set FileIn = fso.OpenTextFile(File , 1, true)
' Datei zum Lesen öffnen
PingTest = "keine Antwort"
Do While Not (FileIn.atEndOfStream)
' wenn Datei nicht zu Ende ist, weiter machen
if InStr( CStr( FileIn.Readline ), "TTL=") > 1 then PingTest = "Antwort erhalten"
' eine Zeile lesen und auf Inhalt testen
Loop
FileIn.Close
Set FileIn = nothing
End Function ' PingTest ( IPtst ) ' v2.C - http://dieseyer.de
'**************************************************************
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:
MsgBox PingTest ( "127.0.0.1" )
'**************************************************************
Function PingTest ( IPtst ) ' v3.A - http://dieseyer.de
'**************************************************************
Dim WSHShell, oExec, input
Set WSHShell = WScript.CreateObject("WScript.Shell")
Set oExec = WshShell.Exec("%comspec% /c Ping " & IPtst & " -n 1 -w 500" )
Do While Not oExec.StdOut.AtEndOfStream
input = input & oExec.StdOut.Read(1)
Loop
PingTest = "keine Antwort"
If InStr(input, "TTL=" ) <> 0 Then
PingTest = "Antwort erhalten"
End If
End Function ' PingTest ( IPtst ) ' v3.A - http://dieseyer.de
'**************************************************************
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).
MsgBox PingTest ( "127.0.0.1" )
MsgBox PingTest ( WScript.CreateObject("WScript.Network").ComputerName )
'**************************************************************
Function PingTest ( IPtst ) ' v3.A - http://dieseyer.de
'**************************************************************
Dim oExec, i
Set oExec = WScript.CreateObject("WScript.Shell").Exec("%comspec% /c Ping " & IPtst & " -n 1" )
Do Until oExec.status
WScript.Sleep 10
i = i + 1
If i > 100 Then oExec.Terminate
Loop
PingTest = "keine Antwort"
If InStr( oExec.StdOut.ReadAll() , "TTL=" ) <> 0 Then PingTest = "Antwort erhalten"
End Function ' PingTest ( IPtst ) ' v3.A - http://dieseyer.de
'**************************************************************
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:
@echo BSP.BAT
@echo on
set stderr=txt.txt tttt
@rem - um das Gleichheitszeichen, also vor und nach dem Gleichheitszeichen,
@rem dürfen keine Leerschritte sein
@rem - in der Variable (hier STDERR) dürfen keine Leerzeichen sein, sonst werden
@rem sie im nachfolgenden Skript wie zwei übergebene Werte behandelt
@set
@pause
wscript bsp.vbs %stderr% %gibtsNicht% XxXxX %TMP% %unbeKANNt%
@rem - da %stderr% ein Leerzeichen hat, sind die beiden ersten Argumente
@rem (0) txt.txt und (1) tttt
@rem - da %gibtsNicht% leer ist, wird der Zähler nicht höher gesetzt
@rem - das dritte Argument ist (2) XxXxX
@rem - das vierte Argument ist (3) c:\temp
@rem (bzw. das, was in der Umgabungsvariable %tmp% gesetzt ist)
@rem - da %unbeKANNt% leer ist . . .
@pause
@pause
. . . und dieses bsp.vbs zeigt die Aufruf-Parameter an:
' bsp.vbs
set oArgs = Wscript.Arguments
Txt = ""
For i = 0 to oArgs.Count - 1 ' hole alle Argumente
Txt = Txt & i & " =[" & oArgs.item(i) & "]= " & vbCRLF
Next
MsgBox Txt
↑ 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.
set oArgs = Wscript.Arguments
If oArgs.Count = 0 then
MsgBox "Ohne Argumente wird's nichts!", ,WScript.ScriptName
WScript.Quit
End If
Text = "Das waren die Argumente:" & vbCRLF
For i = 0 to oArgs.Count - 1 ' hole alle Argumente
Text = Text & oArgs.item(i) & vbCRLF
Next
MsgBox Text, ,WScript.ScriptName
↑ 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:
Set WSHShell = WScript.CreateObject("WScript.Shell")
WSHShell.Run "wordpad ""c:\eigene Dateien\neuer test.rtf"""
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:
Text = "Es ist jetzt " & time
MsgBox Text
Text = "Das ist die ""HOCHZEIT"" " & time
MsgBox Text
MsgBox "Es ist ""TESTZEIT " & time & """"
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.
↑ Zum Seitenanfang ↑
