Dlaczego warto czytać pomoc?
Dziś będzie krótko – o tym dlaczego warto czytać pomoc. PowerShell oferuje ją na każdym kroku i często zanim zaczniemy krzyczeć: “Bug! Bug!” warto sprawdzić, czy aby na pewno zachowanie jest sprzeczne z tym, co “autor miał na myśli”.
Konkretna sytuacja, która świetnie to obrazuje, zdarzyła mi się dzisiaj w pracy. Kolega chciał sprawdzić listę procesów na jednym z serwerów SQL. W pierwszym odruchu sięgnął po PowerShella. Ale wynik mu się nie spodobał, “przesiadł się” więc na GUI.
Drugi kolega uznał, że tak tego zostawić nie można… Spróbował uruchomić to samo polecenie (a przynajmniej tak mu się wydawało) i uzyskał wynik pożądany. Koledzy uznali, że korzystają z różnych wersji a błędy wynikają z jakichś usterek w kodzie. I tak by się to pewnie skończyło, gdyby nie fakt, że wersja okazała się identyczna.
Zainteresowałem się, zacząłem drążyć. Wreszcie dostrzegłem subtelną różnicę. Przyjrzyjmy się. Moje podejście (i najprawdopodobniej podejście kolegi, któremu “działało”):
| Get-DbaProcess -SqlInstance naszSQL -Spid 123 |
Wersja, która dawała wynik daleki od satysfakcjonującego:
| Get-DbaProcess -SqlInstance naszSQL -Spid 123 -Hostname naszSQL |
Pełna konsternacja: owszem, kolega dołożył warunek, ale oczywiście to powinno zawęzić wyniki, prawda? A no nie do końca. Co na to pomoc?
I wszystko jasne: dodatkowy parametr wyniki rozszerzył. A brak zrozumienia przeznaczenia tego parametru zaowocował tym, że kolega dodał wszystkie procesy uruchomione bezpośrednio na serwerze SQL. Przede wszystkim – procesy systemowe, które ze wszelkich sił starał się wykluczyć. Parafrazując: Pomoc służy, Pomoc radzi, Pomoc nigdy cię nie zdradzi!
PowerShell po polsku 