PSScriptRoot Sonderzeichen

[NotNerdNotDau]

Es ist schwierig für Außenstehende, die Abläufe aus der Ferne exakt nachzustellen und die enthaltenen Fehler nachzuvollziehen. Meine Vorschläge sollten auch nur als Anhaltspunkte herhalten und die Code-Schnipsel eigenen sich nicht für eine 1:1-Übernahme in ein Skript.

Sollte $PSScriptRoot tatsächlich das Problem sein, dann böte sich alternativ folgendes an:

If($MyInvocation.MyCommand.CommandType -Eq "ExternalScript")
{$ScriptPath = Split-Path -Parent -Path $MyInvocation.MyCommand.Definition}
Else{$ScriptPath = Split-Path -Parent -Path ([Environment]::GetCommandLineArgs()[0])
If(-Not$ScriptPath){$ScriptPath = "."}}

Das verwende ich in meinen Skripts, setze das ganz an den Anfang und verwende im weiteren Verlauf die Variable "$ScriptPath" als Grundlage für die Pfadangabe.

 

[tollertyp]

$PSScriptRoot ist der Bug, vermute ich doch mal.

Was soll das Script denn machen? Und wenn nicht schon geschehen, bitte kundig machen, exakt was $PSScriptRoot ist und was es nicht ist und im Vergleich $PWD dazu oder einfach nur eine relative Pfadangabe im Script selber.

Warum vermuten, wenn man sowohl lesen als auch testen kann. Aber man kann auch auf beides verzichten und bereits widerlegte Vermutungen äußern.

Leute, $PSScriptRoot ist nicht das Problem, der Explorer ist das Problem. Lesen hilft und bildet, und wenn man etwas nicht glaub (finde ich gut! Kritisches Denken ist sinnvoll), dann kann man es doch einfach selbst testen. Alles in Beitrag #8 erklärt. Aber ich weiß, Diskussionen mit Argumenten und Belegen sind seit über 2 Jahren so ungewohnt.

 

[RalphS]

Warum vermuten, wenn man sowohl llesne als auch testen kann. Aber man kann auch auf beides verzichten und bereits widerlegte Vermutungen äußern

… danke der Nachfrage, gut.

Explorer hat nix mit PS zu tun und glaube mir, ich bin ausreichend vertrau mit ps und Windows und deren Eigenheiten.

Aber wie auch immer, ich mein wenn man den einen Baum anbellt, dan fällt vielleicht ein Hund aus einem anderen.

Protip wäre, sich anzuschauen wie die Komponenten von Windows interagieren … aber irgendwie habe ich da keine Lust mehr drauf.
Nächstes mal ohne Windows also, da kann es keine Probleme mit dem Explorer geben. 🤷‍♀️

 

[tollertyp]

Pro-Tipp: Posting #14 nochmals aufmerksam durchlesen und etwas lernen.

Explorer hat dann etwas mit PowerShell zu tun, wenn der Nutzer versucht, ein PowerShell-Script via Explorer zu starten. Die Begründung steht alles in dem Beitrag. Und ja, du bist so vertraut, dass du gar nicht selbst testen musst... ist klar. Naja, man sagt ja nicht grundlos: Vertrauen ist gut, Kontrolle ist besser.

Und du musst gar nicht schauen, "wie die Komponenten von Windows interagieren" - habe ich alles schon gemacht da.

Edit: Wie habe ich denn da "lesen" geschrieben oO Habe es korrigiert.

 

[NotNerdNotDau]

Ich habe das aus #Beitrag 14 bei mir mal nachvollzogen und keine Probleme festgestellt.

Wäre das mit dem Ausführen über den Explorer ein Bug, der schon länger besteht und zu Fehlern bei der Ausführung führen würde, dann wäre das, nicht nur mir, sondern auch vielen anderen sicher schon längst aufgefallen.

Ich muss allerdings dazu anmerken, dass ich Windows 10 verwende und das Szenario in Beitrag #14, wenn ich mich nicht irre, unter Windows 11 durchgeführt wurde. Deshalb ist es, wahrscheinlich, ein spezifisches Problem unter Windows 11. Das ist aber nur eine Vermutung meinerseits, weil ich Windows 11 nicht verwende und ich es dort nicht nachvollziehen kann.

Man könnte natürlich auch den einfachen Weg gehen und Skripte nicht über den Kontext im Explorer ausführen.
Da gibt es alternativ zum Beispiel die Möglichkeit, über einen Registry-Eintrag es so zu gestalten, dass man PS-Skripte per Doppelklick starten kann.

Über Probleme mit $PSScriptRoot liest man hin und wieder im Netz. Ob da was dran ist, oder ob die Problem nur unter bestimmten Umständen auftreten, kann ich nicht beurteilen. Weil ich diese Variable nicht verwende.

 

[tollertyp]

Bitte Screenshots, die das belegen...

Okay, der Unterschied bei Windows 10 ist, dass in der Registry der "kaputte" Wert an einer anderen Stelle steht:
HKEY_CLASSES_ROOT\SystemFileAssociations\.ps1\Shell\0\Command

Das Verhalten ist aber exakt dasselbe.

Wenn ich diese Datei so ("Mit PowerShell ausführen") starten will, kann sie nicht ausgeführt werden:

Wie hieß das Verzeichnis, das du versucht hast? Wie hast du die Datei ausgeführt? Wie heißt der Befehl, mit dem das Script ausgeführt wird (siehe Registry)?

Und Doppelklick oder Rechtsklick, beides macht der Explorer... der Explorer ist die komplette Shell. Wichtig ist nur, dass man eben nicht diese Befehlszeile verwendet:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & '%1'"

sondern diese z.B.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-File" "%1"

Edit:
Okay, es gibt eine weitere Lösung: Nicht mehr die Windows-PowerShell benutzen sondern die "neue" PowerShell: https://docs.microsoft.com/de-de/po...ing-powershell-on-windows?view=powershell-7.2

Da bei der Installation halt angeben, dass die Ausführung von Scripten ins Kontextmenü hinzugefügt wird. Damit geht es dann:

Und die Ausführung:

 

[NotNerdNotDau]

Bitte Screenshots, die das belegen...

Abgelehnt.
Mir ist die Sache nicht wichtig genug, um einen solchen Aufwand zu betreiben.
Glaube meiner Ausführung, oder lass es bleiben.

Das steht bei mir auch so in der Registry, aber wie bereits erwähnt, verursacht das bei mir keine Probleme.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & '%1'"

 

[tollertyp]

Du kannst nicht mal den Ordnernamen nennen und sagen, wie du es gestartet hast. Krass. Ich glaube dir ehrlich gesagt gar nichts.

 

[NotNerdNotDau]

Ordnername: Siehe Beitrag #16
Ausführung: Über den Kontext "Mit Powershell ausführen"

Ich glaube dir ehrlich gesagt gar nichts.

Was du mir aber ungeprüft glauben kannst: Es ist mir völlig Latte, was du mir glaubst oder nicht glaubst.

 

[tollertyp]

So langsam bin ich auch komplett verwirrt, warum manche Ordnernamen mit Apostroph gehen, andere nicht.
Deiner geht bei mir unter Windows 10 nicht, weder bei der Windows-PowerShell, und die Registry-Anpassung funktioniert auch nicht zuverlässig da bei mir.

Nichtsdestotrotz bin ich mir ziemlich sicher, dass beim TE das Script gar nicht ausgeführt wurde.
Darf ich dich mal fragen, woran du fest machst, dass das Script erfolgreich war? Das Fenster schließt sich ja gleich wieder.

 

[NotNerdNotDau]

Start-Sleep 5 am Ende.

 

[tollertyp]

Über einen Screenshot wäre ich dir da dennoch dankbar - bei mir verhält es sich wie gesagt komplett merkwürdig gerade unter Windows 10 - dass ich da alles auf C:\[...] mache, dürfte ja nicht wirklich das Problem sein.

Beispiele bei mir gerade:
"C:\Fred's best of" -> geht nicht
"C:\Frederik's best of" -> geht

Edit: Fürs Protokoll, so sieht übrigens die Befehlszeile der PowerShell 7 bei mir aus:

C:\Program Files\PowerShell\7\pwsh.exe -Command "$host.UI.RawUI.WindowTitle = 'PowerShell 7 (x64)'; if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & '%1'"

Also grundsätzlich dasselbe Risiko.

Nach Anpassung für die PS7 funktioniert es:

 

[NotNerdNotDau]

Wie gesagt, Screenshot ist nicht.

Mir ist da eben aber noch eine Idee gekommen.
Wie sieht es mit der Kodierung des Skripts aus?

Bei mir ist UTF-8-Bom eingestellt. Vielleicht spielt das ja auch eine Rolle.

Ich verwende nicht das Systemlaufwerk dafür, sondern das zweite Laufwerk D:\.
Ob das auch eine Rolle spielt, weiß ich nicht, aber ich möchte es nur sehr ungern auf dem Systemlaufwerk testen.

 

[tollertyp]

Dadurch dass ja bereits die Ausführung selbst scheitert (abhängig vom Ordner-Namen), spielt die Codierung ja keine Rolle.
Und denke nicht, dass die Partiton eine Rolle spielt, habe es nur der Vollständigkeit halber gesagt.