Triki z PowerShellem #16 – Parametry

2010-08-22 14:44

Pisząc mniej lub bardziej regularnie o PowerShellu, zdołałem zaprezentować całkiem pokaźną kolekcję różnych skryptów. Część z nich do działania wymagała podania dodatkowych danych. Jeśli są one w miarę niezmienne, można je zapisać w samym kodzie jako pseudo-stałe. Jeżeli jednak każde użycie skryptu może potencjalnie potrzebować innych wartości, wtedy najlepiej pobawić się z jego parametrami.

W PowerShellu do specyfikowania argumentów służy słowo kluczowe param. Można je stosować zarówno do samych skryptów, ale także do zawartych w nich funkcji. Tak jest – może nie wspominałem o tym wcześniej, ale w PSh jak najbardziej można definiować własne funkcje na użytek lokalny skryptu:

  1. function Fib
  2. {
  3.     param ([int]$x)
  4.     if ($x -eq 0 -or $x -eq 1)  { return 1 }
  5.     return (Fib ($x - 1)) + (Fib ($x - 2))
  6. }

W obu przypadkach (skryptów i funkcji) instrukcja param powinna znaleźć się na samym początku i wystąpić co najwyżej raz.

Składnia deklaracji parametrów jest raczej prosta i wygląda następująco:

  1. param (..., [typ]$nazwa = wartośćDomyślna, ...)

Kolejne elementy oddzielamy w niej przecinkami. Dla każdego z nich wartośćDomyślna nie jest obowiązkowa, lecz niepodanie jej nie czyni wcale argumentu obowiązkowym. Zamiast tego otrzyma on wartość “neutralną” (np. $null dla obiektów), jeśli nie zostanie przypisany w wywołaniu funkcji/skryptu. Żeby uczynić argument rzeczywiście niezbędnym, należy po prostu… rzucić wyjątek, jeśli nie został on użyty:

  1. param ([string]$name = $(throw "Name required"))

Może to się wydawać dziwne, ale nie zapominajmy, że języki powłok takich jak PowerShell są interpretowane Dlatego błąd w postaci braku wymaganego parametru (który normalnie wykryty by został podczas kompilacji) może dać o sobie znać dopiero w czasie wykonania.

Każdemu parametrowi możemy też przypisać typ, którym może być klasa z .NET-owego frameworka lub któryś z typów wbudowanych. Oczywiście nie musimy tego robić. Wtedy jednak będziemy mieli do czynienia z nieokreślonym obiektem (klasy System.Object), którego rodzaj możemy ewentualnie sprawdzić później (np. metodą GetType).
Specjalnym typem parametru jest switch, czyli przełącznik. Tworzy on parametr, któremu nie podajemy wartości, a jedynie uwzględniamy w wywołaniu (albo i nie). Jest to więc flaga podobna do Recurse czy -Verbose ze standardowych komend PowerShella lub tysięcy podobnych flag w programach i poleceniach z innych shelli. Semantycznie taki przełącznik jest potem zmienną logiczną typu bool:

  1. param ([switch]$Debug)
  2. # ...
  3. if ($Debug) { "Debug mode enabled." | Out-Host }

To mniej więcej tyle, jeśli chodzi o definiowanie parametrów dla funkcji i skryptów. Jak teraz wygląda ich przekazywanie w trakcie wywołania?… No cóż, odpowiedź jest prosta: dokładnie tak samo, jak w przypadku wbudowanych komend PowerShella. Przede wszystkim możemy podawać ich nazwę poprzedzoną myślnikiem oraz wartość:

  1. Fib -x 12 | Out-Host

Nie jest to jednak zawsze konieczne. Zamiast tego możemy zdać się na ich kolejność w deklaracji param, co pozwala ominąć podawanie ich nazw w wywołaniu:

  1. Fib 12

Pamiętajmy tylko, że skrypty (rzadziej funkcje) mogą mieć nierzadko i kilkanaście parametrów. Pomijanie ich nazw na pewno nie wpłynie wtedy pozytywnie na czytelność.

Tags: ,
Author: Xion, posted under Applications, Programming »


2 comments for post “Triki z PowerShellem #16 – Parametry”.
  1. Anonymous:
    August 23rd, 2010 o 10:51

    powershell to taki visualbasic z klamerkami. Ja wole C#

  2. agent_J:
    August 28th, 2010 o 7:23

    Raczej bash (i pewnie reszta unixowego badziewia) to taka wersja PowerShella dla biednych.

Comments are disabled.
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.