manrique
Goto Top

Powershell mit batch aufrufen

Hallo an alle,

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 SilentlyContinue

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

Content-ID: 627110

Url: https://administrator.de/forum/powershell-mit-batch-aufrufen-627110.html

Ausgedruckt am: 25.12.2024 um 08:12 Uhr

146707
146707 30.11.2020 aktualisiert um 23:43:21 Uhr
Goto Top
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.
mayho33
mayho33 01.12.2020 um 02:10:26 Uhr
Goto Top
Von extern verwendest du besser:

powershell.exe -ExecutionPolicy Bypass -file "C:\Program Files\Folder\Folder Server\Data\Documents\pdfPrint.ps1"
146707
146707 01.12.2020 aktualisiert um 10:14:40 Uhr
Goto Top
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.

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 face-wink. Wenn da also noch ein altes Windows 7 ohne PS Update werkeln würde hätte das auch seine Berechtigung.
mayho33
mayho33 02.12.2020 um 11:01:37 Uhr
Goto Top
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.


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 face-wink. 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.ps1

Geht:
powershell -file "C:\program files\irgendwas.ps1"  

Selbst W7-Rechner haben keine PS v2. mehr, wenn halbwegs Updates gemacht wurden. face-wink
146707
146707 02.12.2020 aktualisiert um 11:13:50 Uhr
Goto Top
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!
Fehler:
> powershell -file C:\program files\irgendwas.ps1
> 

Geht:
> powershell -file "C:\program files\irgendwas.ps1"  
> 
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 .

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.
mayho33
mayho33 02.12.2020 aktualisiert um 11:21:31 Uhr
Goto Top
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.

junction
mayho33
mayho33 02.12.2020 aktualisiert um 11:29:20 Uhr
Goto Top
Zitat von @146707:

Zitat von @mayho33:
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.

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. face-wink
146707
146707 02.12.2020 aktualisiert um 11:32:49 Uhr
Goto Top
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.
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. face-wink
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 face-wink.
mayho33
mayho33 02.12.2020 um 11:32:36 Uhr
Goto Top
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.
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. face-wink
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 face-wink.


So unterschiedlich sind die Erfahrungen. Was solls! Der TO braucht ne Lösung :P