Pchełki Powershell: parametry wejściowe

https://xpil.eu/csBem

Dzisiejsza pchełka będzie, jak na pchełkę przystało, króciutka, dotknie jednak bardzo ważkiego zagadnienia: parametryzowania naszego skryptu.

Założenie jest takie, że piszemy skrypt w PS, który operuje na zadanym pliku, a następnie wyniki tej operacji zapisuje w jakimś folderze. Szczegóły (a więc doprecyzowanie co owo "operuje" dokładnie oznacza) są dla dzisiejszej pchełki nieistotne - ważne jest natomiast, żeby zweryfikować na samym początku skryptu, czy podano wszystkie wymagane parametry wejściowe.

W tym celu posłużymy się poleceniem CmdletBinding(), które umożliwia wymuszenie parametrów wejściowych (z wiersza poleceń), weryfikację ich typów danych oraz automatyczne przypisanie ich do lokalnych zmiennych.

Przykład:

[CmdletBinding()] Param ( Parameter (Mandatory=True)] [string] $InputFile)

Powyższa linia, umieszczona na samym początku skryptu, daje nam następujące korzyści:

- Związuje pierwszy parametr przekazany skryptowi w wierszu poleceń ze zmienną lokalną $InputFile, typu string
- Wymusza użycie tego parametru ("Mandatory=True") - a więc jeżeli użytkownik spróbuje wykonać skrypt bez parametru, PS zwróci komunikat błędu i skrypt nie wykona się

W przypadku opisanego przeze mnie scenariusza, nasz skrypt będzie wymagał dwóch parametrów: pliku wejściowego oraz folderu, gdzie chcemy zapisać wyniki. W takim razie musimy zdefiniować obydwa te parametry:

[CmdletBinding()] Param (
Parameter (Mandatory=True)] [string] $InputFile,
Parameter (Mandatory=True)] [string] $OutputFolder
)

Jak widać na powyższym przykładzie, definicje poszczególnych parametrów należy rozdzielić przecinkami.

A co, jeżeli chcemy dać użytkownikowi możłiwość podania trzeciego, nieobowiązkowego parametru? Dajmy na to, piszemy symulator dla Działu Pozyskiwania Stolca i chcemy przekazać skryptowi parametr oznaczający ilość rolek papieru toaletowego, przy czym jeżeli parametr ten zostanie pominięty, chcemy przekazać wartość domyślną równą pięć.

Oto jak to zrobić:

[CmdletBinding()] Param (
Parameter (Mandatory=True)] [string] $InputFile,
Parameter (Mandatory=True)] [string] $OutputFolder,
Parameter ()] [int] $NoOfRolls = 5
)

W tym przykładzie dodaliśmy do listy parametrów trzeci, opcjonalny parametr o nazwie NoOfRolls, którego wartość ustalamy na pięć, o ile użytkownik nie zażyczy sobie inaczej.

Wywołanie naszego skryptu może teraz wyglądać tak:

C:\>powershell mojskrypt.ps1 'c:\pliki\wejsciowe\jakisplik.txt' c:\pliki\wynikowe'

W powyższym przypadku przekazaliśmy skryptowi plik wejściowy 'jakisplik.txt' oraz przykazaliśmy zapisać wyniki do folderu 'wynikowe', przy czym ilość rolek papieru zostanie ustalona na pięć.

Można też tak:

C:\>powershell mojskrypt.ps1 'c:\pliki\wejsciowe\jakisplik.txt' c:\pliki\wynikowe' 8

Tutaj zwiększamy ilość rolek do ośmiu.

A co, jeżeli spróbujemy dodać kolejny parametr opcjonalny, dajmy na to udźwig muszli, w kilogramach?

Proszę bardzo:

[CmdletBinding()] Param (
Parameter (Mandatory=True)] [string] $InputFile,
Parameter (Mandatory=True)] [string] $OutputFolder,
Parameter ()] [int] $NoOfRolls = 5,
Parameter ()] [int] $BowlCapacity = 150
)

Tutaj umożliwiamy użytkownikowi podanie nie tylko ilości rolek srajtaśmy, ale również maksymalnego udźwigu muszli klozetowej - przy czym pominięcie tego parametru spowoduje przyjęcie wartości domyślnej 150 kg.

No i tu zaczynają się kłopoty. A co, jeżeli użytkownik zechce podać inny udźwig muszli, ale bez podawania ilości rolek? W jaki sposób PS rozpozna, o który parametr chodzi?

Tu w sukurs przychodzi alternatywna składnia wywoływania parametrów skryptu, a mianowicie Named Parameters, czylio po naszemu Parametry Nazwane. Czyli nic innego jak jawne przekazanie nazw parametrów w wierszu poleceń, o, tak:

C:\>powershell mojskrypt.ps1 -InputFile 'c:\pliki\wejsciowe\jakisplik.txt' -OutputFolder c:\pliki\wynikowe' -BowlCapacity '250'

W powyższym wywołaniu przekazujemy do skryptu trzy parametry: dwa pierwsze obowiązkowe, bez zmian, oraz czwarty (pomijamy trzeci, który w związku z tym przybierze wartość domyślną 5).

Innym zagadnieniem jest bardziej szczegółowa weryfikacja danych wejściowych, czyli na przykład sprawdzenie, czy plik istnieje, albo czy nie podano pliku zamiast folderu i tak dalej. Ale o tym napiszę - być może - innym razem.

https://xpil.eu/csBem

3 komentarze

  1. Czy to normalne, że gdy pracujesz dla korporacji to czujesz się jak przeciągnięty przez wyżymaczkę a na dodatek masz wyrzuty sumienia, że mało pracujesz?

    1. Nie. Jeżeli tak masz, to zacznij brać pod uwagę zmianę pracy. Można tak popracować chwilę, dla papieru albo kasy, ale na dłuższą metę to zarzynanie się. Miejsce, w którym spędzasz 8 godzin życia dziennie, musi dawać chociaż minimum frajdy.

      1. sie zgadza. Tyle, że korporacje uzależniają: dobre warunki pracy, dobre CV, dobre doświadczenie. Poza tym po paru latach zaczyna ci się wydawać, że żadnej lepszej roboty nie znajdziesz. Pytanie czy to celowe działanie korporacji żeby ci to wmówić, czy faktycznie tak jest. Jak już kiedyś pisałem, dobry model to 5 lat pracy w jednej firmie i wypad. Choćby nawet było OK. Raz tak zrobiłem i co prawdca kolejna robota to była porażka, ale już kolejne następne coraz lepsze.

Leave a Comment

Komentarze mile widziane.

Jeżeli chcesz do komentarza wstawić kod, użyj składni:
[code]
tutaj wstaw swój kod
[/code]

Jeżeli zrobisz literówkę lub zmienisz zdanie, możesz edytować komentarz po jego zatwierdzeniu.