Parametr -File nie działa z dodatkowymi parametrami w PowerShell wskazuje na błędne cudzysłowowanie argumentów przekazywanych do skryptu — cały ciąg trzeba poprawnie ująć w cudzysłowy.
-File nie działa z parametrami — co oznacza ten problem
W PowerShell parametr -File służy do wskazania pliku skryptu, który ma zostać uruchomiony przez powershell.exe albo pwsh. Samo wskazanie ścieżki do pliku zwykle nie sprawia trudności, natomiast problem może pojawić się wtedy, gdy po nazwie skryptu mają zostać przekazane dodatkowe argumenty. W takiej sytuacji istotne jest rozróżnienie między parametrami programu PowerShell a parametrami należącymi już do uruchamianego skryptu.
Przykładowo polecenie powershell.exe -File C:\Skrypty\raport.ps1 -Nazwa Jan powinno przekazać do skryptu wartości związane z jego własnymi parametrami, o ile skrypt został odpowiednio zdefiniowany. Jeżeli jednak ścieżka, argument albo cały fragment polecenia zostanie zapisany z nieprawidłowymi cudzysłowami, PowerShell może potraktować część tekstu jako osobny element wywołania. W efekcie pojawia się komunikat o nierozpoznanym parametrze, braku wartości albo nieprawidłowym użyciu -File.
Najczęściej nie chodzi o błąd samego pliku .ps1, lecz o sposób zbudowania polecenia w wierszu poleceń, skrócie, zadaniu harmonogramu lub innym programie uruchamiającym PowerShell. Znaczenie ma także to, czy polecenie jest wykonywane w klasycznym cmd.exe, bezpośrednio w PowerShell, czy z poziomu aplikacji przekazującej argumenty jako osobne elementy.
Jak przekazywane są argumenty po parametrze -File
Po -File powinna znaleźć się ścieżka do skryptu, a następnie argumenty przeznaczone dla tego skryptu. Jeżeli wartość zawiera spacje, należy objąć ją cudzysłowem, na przykład:
powershell.exe -File "C:\Moje Skrypty\kopiuj.ps1" -Folder "C:\Dane użytkownika"
W tym przykładzie cudzysłowy chronią ścieżki zawierające spacje. Nie powinno się natomiast dodawać przypadkowych cudzysłowów w środku nazwy parametru ani łączyć kilku niezależnych argumentów w jeden ciąg, jeżeli skrypt oczekuje ich osobno. Błędna forma może wyglądać następująco:
powershell.exe -File "C:\Moje Skrypty\kopiuj.ps1 -Folder C:\Dane"
W takim zapisie cała zawartość między cudzysłowami może zostać potraktowana jako ścieżka pliku, a nie jako ścieżka skryptu oraz jego parametr. Cudzysłowem należy obejmować konkretną wartość, która wymaga ochrony przed podziałem na kilka argumentów, a nie cały fragment polecenia bez rozróżnienia jego elementów.
Warto również sprawdzić deklarację parametrów wewnątrz skryptu. Przykładowa konstrukcja może wyglądać tak:
param(
[string]$Nazwa,
[string]$Folder
)
Jeżeli nazwa przekazywana w poleceniu nie odpowiada nazwie zadeklarowanej w sekcji param, problem może zostać błędnie przypisany do -File. Podobnie zadziała przekazanie wartości w nieoczekiwanym formacie, użycie niewłaściwego znaku myślnika albo pominięcie wartości wymaganej przez parametr.
Typowe błędy przy uruchamianiu skryptu
Jednym z częstych powodów niepowodzenia jest pomieszanie składni używanej do uruchamiania PowerShell ze składnią wykonywaną już wewnątrz sesji PowerShell. Parametr -File jest opcją programu uruchamiającego, dlatego nie w każdym miejscu powinien być stosowany tak samo. W aktywnej sesji PowerShell często wystarczy wywołać skrypt za pomocą operatora wywołania i podać argumenty po ścieżce:
& "C:\Moje Skrypty\raport.ps1" -Nazwa "Jan"
Inny błąd polega na pominięciu operatora wywołania przy ścieżkach zawierających spacje. Sama ścieżka ujęta w cudzysłów nie zawsze oznacza wykonanie pliku, ponieważ PowerShell może potraktować ją jako zwykły tekst. W takich przypadkach użycie & jasno wskazuje, że wskazany element ma zostać uruchomiony.
Problemy mogą być także powodowane przez:
- niezamknięty cudzysłów przy ścieżce do skryptu lub wartości parametru,
- użycie cudzysłowów typograficznych zamiast zwykłych znaków
", - przekazanie parametru przeznaczonego dla PowerShell w miejscu parametru skryptu,
- brak wartości po parametrze, który jej wymaga,
- różnicę między pojedynczym i podwójnym cudzysłowem przy przekazywaniu tekstu zawierającego zmienne,
- uruchomienie niewłaściwej wersji PowerShell, gdy składnia skryptu zależy od konkretnego środowiska,
- zablokowanie skryptu przez zasady wykonywania lub zabezpieczenia systemowe,
- nieprawidłową ścieżkę, zmianę nazwy pliku albo brak dostępu do wskazanego katalogu.
Przy diagnozowaniu warto najpierw wyświetlić lub zapisać dokładną komendę przekazywaną do uruchomienia. Należy sprawdzić, gdzie zaczyna się ścieżka skryptu, gdzie kończy się jej cudzysłów oraz czy każdy argument trafia do właściwego parametru. Pomocne bywa również uproszczenie polecenia do samego uruchomienia pliku, a następnie dodawanie kolejnych argumentów pojedynczo. Pozwala to ustalić, który element powoduje błąd.
Kiedy warto oddać urządzenie do diagnozy - -File nie działa z parametrami
Do serwisu warto zgłosić się wtedy, gdy problem z -File powtarza się mimo poprawienia cudzysłowów, ścieżki i nazw parametrów albo gdy skrypt jest uruchamiany automatycznie przez harmonogram, skrót, aplikację firmową lub inne narzędzie. Szczególnej uwagi wymaga sytuacja, w której ten sam plik działa ręcznie, lecz przestaje działać po uruchomieniu z innego konta użytkownika, z zadania zaplanowanego albo po zmianie środowiska systemowego.
W ramach Warszawskiego Pogotowia Komputerowego 24/7 można zlecić sprawdzenie konfiguracji systemu, sposobu wywoływania skryptu, uprawnień, ścieżek oraz zależności między PowerShell a programem, który przekazuje polecenie. Przy analizie przydatne jest przedstawienie pełnego komunikatu błędu, przykładowej komendy i informacji, czy problem występuje wyłącznie dla jednego skryptu. W przypadku urządzenia przenośnego dostępna jest darmowa diagnoza LAPTOPA, co pozwala najpierw ustalić, czy źródłem trudności jest składnia polecenia, konfiguracja PowerShell, uprawnienia systemowe czy szerszy problem z działaniem środowiska.
