VB Script Problem bei den Elevation Tools
Thomas Steinbach
ich habe hier ein VBS Script aus den Elevation Tools [1], bei
dem ich _vor_ der Ausfuehrung von einer Batchdatei in das Verzeichnis
wechseln mag (d.h eigentlich verbleiben will, denn es ist ja bereits das
aktive Verzeichnis), aus welchem elevate.vbs mit der Batchdatei aufgerufen
wird. btw: elevate.cmd/vbs liegt im Suchpfad.
Ich befinde mich z.B. in "C:\Program Files\My Prog" und
rufe eine svctest.bat liegt (noch) im gleichen Verzeichnis auf
svctest.bat
---snip---
net start | findstr /C:%~1 >nul
if ERRORLEVEL 1 goto END
if ERRORLEVEL 0 goto SVCACTION
:SVCACTION
elevate mybatch.bat "%~f1"
:END
---snap---
Dann aber ist es so dass ich mich unter C:\Windows\System32
befinde, wenn meine Batchdatei mybatch.bat ueber die elevate.vbs
zur Ausfuehrung kommt.
Ich benoetige es nun so dass ich eben in dem Verzeichnis verbleibe
bzw. zurueckkehre, aus dem meine Batch gestartet wird und brauche
es so, dass ich nicht innerhalb der aufgerufenen Batchdatei mybatch.bat
wechseln muss.
Wie kann man das umsetzen, bzw. wie muss ich elevate.vbs
anpassen, damit es so funktioniert wie ich es nun benoetige.
Bisher hatte ich probiert in elevate.cmd eine zusaetzliche Variable
in der Batch einzufueheren und mit
set ELEVATE_PATH=%CD%"
kann ich dann auch in der elevate.vbs ueber
strAppPath = objWshProcessEnv("ELEVATE_PATH")
das Verzeichnis ermitteln bzw. uebergeben. Allerdings hat ein folgendes:
objWshShell.CurrentDirectory = strAppPath
vor der Ausfuehrung von
objShell.ShellExecute strApplication, strArguments, "", "runas"
zeigt keinerlei Wirkung und auch eine Angabe des Pfades im
dritten Parameter:
objShell.ShellExecute strApplication, strArguments, strAppPath, "runas"
wechselt dennoch nach System32, bzw. zeigt mir eine aufgerufene
Batchdatei ueber %CD% noch das C:\Windows\System32 Verzeichnis an.
Das ist fuer mein Script aber unguenstig, da ich in meiner Batch
genau in dem Verzeichnis Operationen ausfuehren will, die dieses
betreffen, bzw. aus dem ich meine Batch aufrufe.
Hat hier jemand eine Idee wie es gehen koennte?
Thomas
[1] http://technet.microsoft.com/en-us/magazine/2008.06.elevation.aspx
(DE) http://technet.microsoft.com/de-de/magazine/2008.06.elevation.aspx
Uwe Kausch
warum �bergibst das aktuelle Verzeichnis (der Batch-Datei) nicht als Argument an das VBScript? Das k�nnte so aussehen ...
cscript mein.vbs %CD%
Im VBScript holst Du Dir das Argument mit "Wscript.Arguments.Item(0)". Mit "0" wird das erste Argument zur�ckgegeben. Hier das Script zum pr�fen ...
========= mein.vbs =============
option explicit
msgbox Wscript.Arguments.Item(0)
================================
Deine L�sung mit der Umgebungsvariablen funktioniert nicht weil Du mit "set" nur eine "tempor�re Umgebungsvariable" erstellst und diese nur in der Laufzeit innerhalb der aktuellen CMD-Session zur Verf�gung stehen (musste ich auch erst nachlesen). Du k�nntest folglich in einer Eingabeaufforderung mit "set" ein Variable setzen und diese in einer zweiten Eingabeaufforderung NICHT abrufen k�nnen.
Gr��e,
Uwe
Wolfgang Badura
Du hast in Deinem Posting in der NG Microsoft.public.de.vb gefragt
schipp
btw: gibt es eine IDE/Editor das sowas wie CodeCompletition
kennt. Also die Eingabe von WScript und einem Punkt zeigt
automatisch die moeglichen Methoden, Variablen, etc. an? Mit
der VB Express 2k8 oder der VS 2k8 Prof. geht es leider nicht.
schnapp
Ein wenig schon in
VBSEdit
unter http://www.vbsedit.com
Wolfgang
Thomas Steinbach
endlich habe ich etwas Luft, denn das Problem ist IMHO und
fuer mich nicht so trivial wie es auf den ersten Blick ausschaut.
"Uwe Kausch" <UweKaus...@web.de> wrote in message
news:%23%238J3uHk...@TK2MSFTNGP06.phx.gbl...
> Hallo Thomas,
>
> warum übergibst das aktuelle Verzeichnis (der Batch-Datei) nicht als
> Argument
> an das VBScript? Das könnte so aussehen ...
> cscript mein.vbs %CD%
>
> Im VBScript holst Du Dir das Argument mit "Wscript.Arguments.Item(0)".
> Mit "0" wird das erste Argument zurückgegeben. Hier das Script zum prüfen
> ...
> ========= mein.vbs =============
> option explicit
> msgbox Wscript.Arguments.Item(0)
> ================================
ja, so geht es sicher auch. Aber hier gar nicht so wichtig.
Denn es geht mir um das Wechseln nach System32, bzw. das
Verbleiben in dem Verzeichnis, aus dem heruaus die elevate.vbs
aufgerufen wird.
> Deine Lösung mit der Umgebungsvariablen funktioniert nicht weil Du mit
> "set" nur
> eine "temporäre Umgebungsvariable" erstellst und diese nur in der Laufzeit
> innerhalb
> der aktuellen CMD-Session zur Verfügung stehen (musste ich auch erst
> nachlesen).
> Du könntest folglich in einer Eingabeaufforderung mit "set" ein Variable
> setzen und
> diese in einer zweiten Eingabeaufforderung NICHT abrufen können.
Doch, das funktioniert schon so. Im VBS Script hole ich mir
ja die Umgebunsvariablen ueber VBS wieder. Das machen die
Elevation Tools genau so: Zitat aus dem OP:
---snip---
set ELEVATE_PATH=%CD%"
kann ich dann auch in der elevate.vbs ueber
strAppPath = objWshProcessEnv("ELEVATE_PATH")
das Verzeichnis ermitteln bzw. uebergeben. Allerdings hat ein folgendes:
---snap---
Wscript, welches aus der CMD aufgerufen wird, erbt nun diese
Umgebungsvariablane. Auch setze hier kein "setlocal" und somit
bleiben die Environmentvariabln auch bestehen. Habe das aber
mit dem Setzen von setlocal noch nicht probiert, muesste aber
auch gehen, da ja wscript aus dem batchscript heraus aufgerufen
wird und somit die Umgebung erben duerfte.
Aber das ist wie gesagt gar nicht so der grosse Punkt.
Vielmehr interessiert mich in diesem Zusammenhang wie ich das
Wechseln vor/waehrend des Ausfuehrens von elevate.vbs
in das "C:\Windows\System32" verhindere und somit im
Verzeichnes des Aufrufens verbleibe?
Thomas