[Gelöst] cmd/bat wird von c:\windows\system32 ausgeführt

Humbug

Herzlich willkommen!
Hallo erstmal,

hab mir kürzlich den FreeeCommander als Portable version besorgt und muss sagen, der gefällt mir von allen bisher getesteten doch am Besten. Leider hab ich ein Problem:

ich schreibe immer wieder mal einige Batch-Scripte, iunter anderem damit diverse Programme "wirklich" portabel laufen. Z.B. setze ich das AppData-Verzeichnis in das Verzeichnis, aus dem ich die *.cmd/*.bat starte. Als bestes Beispiel hab ich hier den UniformServer, den ich per Batch starte, bei dem ich eine Variable setze, damit ich php/html-Seiten immer vom korrekten Ort aus ausführen kann (Variable wird in der Apache-Config für den Pfad hergenommen).

Nun zum eigentlichne Problem: wenn ich das CMD-File aus dem FC starte, ruft er die cmd.exe direkt aus derem Satmmverzeichnis auf, also "C:\Windows\System32\cmd.exe". Dann bekomm ich ne Fehlermeldung, dass die zu startende EXE nicht gefunden werden kann. Na logisch...habe meine Sourcen ja auch nicht unter "C:\Windows\System32" :ROFLMAO: Kann man dem FC irgendwie beibringen, dass er das Batch-File wirklich mit dem Pfad des Aufrufs verarbeitet? Also dass es wirklich von da ausgehend mit seiner Arbeit beginnt, von wo es aus gestartet wurde? Wenn ich das Script aus dem "normalen" Windows-Explorer starte, gibts keine Probleme.

Danke schon mal für die Antworten
 
Wenn ich das Script aus dem "normalen" Windows-Explorer starte, gibts keine Probleme.
Weil der Explorer das Verzeichnis vom Batch als workingdir annimmt. FC startet den Batch wohl via cmd und dafür nimmt es das winsysdir.
Entweder bekommst du FC das eingetrichtert, dass aktuelles Verzeichnis workingdir ist oder der FC hat nen Fehler (bug) und Marek muss nachbessern.

PS set ist auch nur temporär, sollte aber helfen (km Batch einpflegen). Dauerhaft hilft nur die PATH-Einstellung in der Systemsteuerung > System und die um den Pfad des Batches erweitert (macht auch nur Sinn, wenn der Batch immer darin ausgeführt wird).
 
Danke für die Antworten

Ja das mit dem SET habe ich mir auch schon überlegt, müsste man dann eben von Umgebung zu Umgebung (in Verbindung mit FC) anpassen, was ich ja eigentlich umgehen wollte. Bzw. ne Abfrage einbauen, welcher Pfad gerade "aktuell" ist, und wenns nichit der system32-Ordner ist, dann verwende den aktuellen Pfad, ansonsten den manuell eingetragenen. Muss ich mich nochmal hinsetzen... :)
 
%~dp0 statt %cd% wars

Meine Güte, auf das hätte ich auch kommen können. Danke schön, klappt wunderbar :ROFLMAO:
 
ich schreibe immer wieder mal einige Batch-Scripte, iunter anderem damit diverse Programme "wirklich" portabel laufen.
Solltest du besser drauf verzichten, dafür ist Batch einfach zu begrenzt und schlecht. Wenn du das Programm bei portableapps finden solltest, dann nutze es von dort. Ansonsten kann ich dir nur ernsthaft NSIS (damit arbeitet auch papps) oder AutoIt nahelegen. IMO hat Batch auch Einschränkungen zgl 32/64bit, so eine Unterscheidung will auch erkannt und programmiert werden. Ist mit NSIS/Autoit ein Kinderspiel. Ich weiss, wovon ich rede, ich arbeite mit beiden ;)

Ach ja, falls dir mal der Gedanke gekommen sein sollte, Batch mit einen Compiler zu EXE umzuwandeln, vergiss es besser gleich wieder, die Teile werden zu 99% als Malware erkannt, liegt einfach am Konzept: EXE->Batch->Ausführung.
 
Solltest du besser drauf verzichten, dafür ist Batch einfach zu begrenzt und schlecht. Wenn du das Programm bei portableapps finden solltest, dann nutze es von dort. Ansonsten kann ich dir nur ernsthaft NSIS (damit arbeitet auch papps) oder AutoIt nahelegen. IMO hat Batch auch Einschränkungen zgl 32/64bit, so eine Unterscheidung will auch erkannt und programmiert werden. Ist mit NSIS/Autoit ein Kinderspiel. Ich weiss, wovon ich rede, ich arbeite mit beiden ;)

Ach ja, falls dir mal der Gedanke gekommen sein sollte, Batch mit einen Compiler zu EXE umzuwandeln, vergiss es besser gleich wieder, die Teile werden zu 99% als Malware erkannt, liegt einfach am Konzept: EXE->Batch->Ausführung.

Ich benutz sowieso, soweit vorhanden, die meisten Programme von PortableApps.com. Aber es gibt eben auch Programme wie den angesprochenen UniformServer, der auch als Portable läuft. Auch von überall ausführbar ist. Mein "Problem" dahinter war aber, dass der Server an sich ja portable ist, aber sobald ich eigene Webapplikationen (Joomla, Wordpress, ...) lokal laufen hab lassen, musste vor allem in den Apache-Configs immer der absoluten Pfad angegeben, wo sich die HTML/PHP-Files befinden. Da ich das Teil aber in der Firma auch Kollegen zu deren Testzwecken zur Verfügung stellen wollte (und die sich eben nicht so sehr mit der Materie beschäftigen und ich auch nicht zu jedem einzelnen hinlatschen und bei denen den Pfad anpassen wollte), dachte ich mir, dass es ja ne Möglichkeit geben muss, den Pfad eben immer korrekt rauszubekommen. Und zwar bis zum Ursprung der zu startenden BAT/CMD-Datei, von da an gehts dann sowieso mit absoluten Pfaden zu den einzelnen Ordnern. Mit %CD% gings bzw gehts ja e immer noch, nur eben aus dem FC heraus nicht, somit eben, dank Razorblade (y), mit dern anderen Variante, die sowohl ohne als auch mit FC klappt.
Bei MobaXTerm z.B. unterbinde ich so, dass es die Daten ins AppData-Verzeichnis schreibt, bei Minecraft dasselbe.

Bezüglich NSIS: da hab ich mich erst vor kurzemn damit begonnen zu beschäftigen. Da habe ich das Teil auch schon als Installer fertig, leider wird das Ausführen gleich komplett unterbunden in der Firma. Was schade ist, da ich NSIS doch recht ansprechende finde, vor allem den Teil mit den Sections und somit abwählbaren Komponenten. Auch das eingeschränkte aber doch mögliche Theming find ich nicht so schlecht. Mit AutoIt hatte ich nich gar nix am Hut :angel

Andererseits: die kompilierten EXE-Files der genannten Programe klappen aber ohne Probleme, auch in der Firma :eek:

Und jap, batch ist dahingehend ziemlich begrenzt, aber meine derzeitigen Verwendungszwecke sind eben nur jene, dass die Pfade immer korrekt ausgelesen werden und für kleine Scripte z.B. für PSQL zum Erstellen/Löschen von Datenbanken, ohne sich jedesmal manuell drauf verbinden zu müssen.

Wie dem auch sei, nun hauts hin und ich bin glücklich :)
 
Da habe ich das Teil auch schon als Installer fertig, leider wird das Ausführen gleich komplett unterbunden in der Firma.
Dazu müsstest du das Protokoll vorliegen haben, was im Paket erkannt wurde, ob das die Daten sind oder von nsis selbst eine Bibliothek (dll). Letzteres lässt sich immer ersetzen, oder durch Aufrufe von Windows-Funktionen (nicht Batch). Beispiel Mutex
System::Call 'kernel32::CreateMutexA(i 0, i 0, t "${MUTEX}") i .r1 ?e'
 
Oben