9
Powershell mit batch aufrufen
Hallo an alle,
beim Aufruf aus PoserShell ISE funktioniert folgender Code fehlerfrei:
Beim Aufruf mittels batch mit dem Befehl powershell.exe -ExecutionPolicy Bypass -Command "& 'C:\Program Files\Folder\Folder Server\Data\Documents\pdfPrint.ps1'"
kommt trotz korrektem Pfad die Fehlermeldung:
This command cannot be run due to the error: The system cannot find the file specified.
Was ist hier falsch?
Vielen Dank für eure Hilfe
Manrique
beim Aufruf aus PoserShell ISE funktioniert folgender Code fehlerfrei:
# create printable PDF
# Drucker definieren
$printer = 'PDFCreator'
gci "C:\Users\xyz\Documents\Test.pdf" | %{
# starte PDF-Druck via Shell-Verb 'printto'
$pdfApp = (start-process $_ -Verb "printto" -PassThru -ArgumentList "$printer").ProcessName
#$pdfApp = (start-process $_ -Verb "print" -PassThru).ProcessName
# initialer sleep
sleep(3)
# loope solange bis Datei freigegeben wurde und lösche sie dann - erledige ich zu einem späteren Zeitpunkt: PDF wird vorher noch transferiert
#while($true){del $_ -Force -EV err -EA SilentlyContinue; If($err){sleep(1)}else{break}}
}
# PDF Applikation beenden
get-process $pdfApp -ErrorAction SilentlyContinue | Stop-Process
sleep(3)
Stop-Process -Name architect -ErrorAction SilentlyContinueBeim Aufruf mittels batch mit dem Befehl powershell.exe -ExecutionPolicy Bypass -Command "& 'C:\Program Files\Folder\Folder Server\Data\Documents\pdfPrint.ps1'"
kommt trotz korrektem Pfad die Fehlermeldung:
This command cannot be run due to the error: The system cannot find the file specified.
Was ist hier falsch?
Vielen Dank für eure Hilfe
Manrique
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 627110
Url: https://administrator.de/contentid/627110
Printed on: April 24, 2024 at 15:04 o'clock
9 Comments
Latest comment
C:\Program Files\Folder\Folder Server\Data\Documents\pdfPrint.ps1
Das ist der Ordner für 64bit Programme, wenn die Powershell selbst nicht in ihrer 64Bit-Variante aus der Cmd aufgerufen wird sieht der Prozess die dort hinterlegte Datei durch die Filesystem Redirection nicht, der 32Bit PS Prozess sieht dann stattdessen den Inhalt von c:\Program Files(x86) und dort findet er das PS-Skript natürlich nicht, ergo Fehlermeldung.
Von extern verwendest du besser:
powershell.exe -ExecutionPolicy Bypass -file "C:\Program Files\Folder\Folder Server\Data\Documents\pdfPrint.ps1"
powershell.exe -ExecutionPolicy Bypass -file "C:\Program Files\Folder\Folder Server\Data\Documents\pdfPrint.ps1"
Zitat von @mayho33:
Von extern verwendest du besser:
powershell.exe -ExecutionPolicy Bypass -file "C:\Program Files\Folder\Folder Server\Data\Documents\pdfPrint.ps1"
Und was soll daran jetzt "besser" sein außer das es etwas kürzer ist? Macht genau das gleiche und Ergebnis ist es auch.Von extern verwendest du besser:
powershell.exe -ExecutionPolicy Bypass -file "C:\Program Files\Folder\Folder Server\Data\Documents\pdfPrint.ps1"
Noch was: Die PS Version 2.0 hatte damals sogar einen Bug mit dem -File Parameter dort waren damals keine Pfade mit Leerzeichen möglich und man musste sogar zwingend auf die Variante des TO ausweichen
. Wenn da also noch ein altes Windows 7 ohne PS Update werkeln würde hätte das auch seine Berechtigung.Zitat von @146707:
Zitat von @mayho33:
Von extern verwendest du besser:
powershell.exe -ExecutionPolicy Bypass -file "C:\Program Files\Folder\Folder Server\Data\Documents\pdfPrint.ps1"
Und was soll daran jetzt "besser" sein außer das es etwas kürzer ist? Macht genau das gleiche und Ergebnis ist es auch.Von extern verwendest du besser:
powershell.exe -ExecutionPolicy Bypass -file "C:\Program Files\Folder\Folder Server\Data\Documents\pdfPrint.ps1"
Das bessere daran ist, dass der File-parameter genau dafür da ist.
Noch was: Die PS Version 2.0 hatte damals sogar einen Bug mit dem -File Parameter dort waren damals keine Pfade mit Leerzeichen möglich und man musste sogar zwingend auf die Variante des TO ausweichen . Wenn da also noch ein altes Windows 7 ohne PS Update werkeln würde hätte das auch seine Berechtigung.
. Wenn da also noch ein altes Windows 7 ohne PS Update werkeln würde hätte das auch seine Berechtigung.Pfade mit Leerzeichen waren immer möglich! Man musste den String einfach nur zwischen Anführungszeichen stellen. Dann kannte sich das cmdlet auch aus. Das gibts auch bei PS7 noch. Pfade mit Leerzeichen von extern werden nicht erkannt.
Fehler:
powershell -file C:\program files\irgendwas.ps1Geht:
powershell -file "C:\program files\irgendwas.ps1" Selbst W7-Rechner haben keine PS v2. mehr, wenn halbwegs Updates gemacht wurden.
Zitat von @mayho33:
Pfade mit Leerzeichen waren immer möglich! Man musste den String einfach nur zwischen Anführungszeichen stellen.
Nein, das der Pfad in Anführungszeichen stand ist klar das war er natürlich auch, so blöd bin ich natürlich nicht!Pfade mit Leerzeichen waren immer möglich! Man musste den String einfach nur zwischen Anführungszeichen stellen.
Fehler:
Geht:
Schon klar! Das war damals aber nicht der Fehler , der Fehler lag damals in der PS selbst! Der Parameter -File konnte bei einem Build definitiv nicht mit Leerzeichen auch in korrekt mir Anführungszeichen versehenen Pfaden umgehen. Deswegen war das obige ein temporärer Workaround dafür .> powershell -file C:\program files\irgendwas.ps1
> Geht:
> powershell -file "C:\program files\irgendwas.ps1"
> Selbst W7-Rechner haben keine PS v2. mehr, wenn halbwegs Updates gemacht wurden
Klar, aber darum ging es mir nicht, obige Anwendung war einfach eine nur eine gleichwertige Alternative zum Parameter -File nicht mehr und nicht weniger.Zitat von @146707:
C:\Program Files\Folder\Folder Server\Data\Documents\pdfPrint.ps1
Das ist der Ordner für 64bit Programme, wenn die Powershell selbst nicht in ihrer 64Bit-Variante aus der Cmd aufgerufen wird sieht der Prozess die dort hinterlegte Datei durch die Filesystem Redirection nicht, der 32Bit PS Prozess sieht dann stattdessen den Inhalt von c:\Program Files(x86) und dort findet er das PS-Skript natürlich nicht, ergo Fehlermeldung.Da muss ich dir widersprechen. Wenn du aus einem 32-Bit-Process heraus die Junktion nutzt um einen anderen Prozess aufzuführen, wird immer der "Architektur-naheste" Prozess gewählt.
Zitat von @146707:
Klar, aber darum ging es mir nicht, obige Anwendung war einfach eine nur eine gleichwertige Alternative zum Parameter -File nicht mehr und nicht weniger.
Klar, aber darum ging es mir nicht, obige Anwendung war einfach eine nur eine gleichwertige Alternative zum Parameter -File nicht mehr und nicht weniger.
ja, OK! gleichwertig schon. die CMD, also %comspec% kann aber einfach nicht gut mit Apostroph, Hochkomma umgehen. Darum der "-File"-Parameter.
in Bash z.B. verwendet man deshalb ja auch den BackTick " ` ", wenn man ein Hochkomma braucht. Da steicgt die CMD aka Comspec aber total aus.
Zitat von @mayho33:
ja, OK! gleichwertig schon. die CMD, also %comspec% kann aber einfach nicht gut mit Apostroph, Hochkomma umgehen. Darum der "-File"-Parameter.
Noch nie Probleme damit gehabt, macht der CMD gar nüscht.ja, OK! gleichwertig schon. die CMD, also %comspec% kann aber einfach nicht gut mit Apostroph, Hochkomma umgehen. Darum der "-File"-Parameter.
in Bash z.B. verwendet man deshalb ja auch den BackTick " ` ", wenn man ein Hochkomma braucht. Da steicgt die CMD aka Comspec aber total aus.
Nö, in der Bash braucht es kein Backtick für Hochkommas wenn dann einen Backslash, ein Backtick leitet dort eine Subshell ein für ein Kommando ein. Da hast du wohl vollkommen die Umgebung verwechselt .Zitat von @146707:
.
Zitat von @mayho33:
ja, OK! gleichwertig schon. die CMD, also %comspec% kann aber einfach nicht gut mit Apostroph, Hochkomma umgehen. Darum der "-File"-Parameter.
Noch nie Probleme damit gehabt.ja, OK! gleichwertig schon. die CMD, also %comspec% kann aber einfach nicht gut mit Apostroph, Hochkomma umgehen. Darum der "-File"-Parameter.
in Bash z.B. verwendet man deshalb ja auch den BackTick " ` ", wenn man ein Hochkomma braucht. Da steicgt die CMD aka Comspec aber total aus.
Nö In der Bash braucht es kein Backtick für Hochkommas, ein Backtick leitet dort eine Subshell ein für ein Kommando ein. Da hast du wohl die Umgebung verwechselt .So unterschiedlich sind die Erfahrungen. Was solls! Der TO braucht ne Lösung :P
