Heading

Jak każdy język programowania, PowerShell obsługuje komentarze. W rzeczywistości, obsługuje dwa style komentarzy. Jednakże, jak zobaczysz w dalszej części tego artykułu, PowerShell może używać komentarzy na kilka ciekawych i nieoczekiwanych sposobów, które mogą być całkiem potężne.

Używanie komentarzy

Najczęściej spotykanym stylem komentarza jest linia poprzedzona symbolem #. (Pozostawiam Ci decyzję, czy chcesz to nazwać hashtagiem, symbolem funta, czy nawet starym dobrym oktothorpe!)

Jako przykład, możesz mieć blok komentarza na początku swojego programu ze szczegółami na jego temat:

Komentarze takie jak ten mogą trafić w dowolne miejsce w twoim kodzie. Alternatywnym sposobem na zrobienie tego byłoby jednak bardziej to, co nazwałbym stylem języka C lub czasami określanym jako komentarz blokowy:

Ten styl pozwala na łatwiejsze dodawanie linii komentarzy bez konieczności posiadania # przed każdym z nich. Możesz swobodnie używać obu tych stylów lub nawet obu. Pamiętaj jednak o użyteczności takich bloków komentarzy, gdy wrócisz do debugowania swojego kodu za rok od teraz. Jednakże, komentarze nie muszą znajdować się na początku linii. W rzeczywistości, osobiście uważam, że używam bloków komentarzy takich jak powyżej tylko na początku skryptu lub tuż przed szczególnie skomplikowanym blokiem kodu. O wiele częściej używam komentarzy endline, takich jak:

Zawarłem ten komentarz w niedawnym skrypcie, ponieważ | Out-Null nie było czymś, czego oczekiwałem, że będzie wymagane, i wiem, że za rok od teraz, gdybym nie miał tam tego komentarza, zastanawiałbym się, dlaczego go tam miałem. Albo gorzej, usunąłbym go, a potem zastanawiałbym się, dlaczego dostaję wiadomość o anulowaniu, która ciągle się pojawia.

Zauważ, że kiedy zaczynasz komentarz od #, wszystko do końca linii jest traktowane jako komentarz. Może to być przydatne na przykład, gdy testujesz i możesz chcieć wykomentować koniec polecenia.

To pozwala ci później usunąć komentarz i uzyskać –online wersję pomocy, ale co jeśli chcesz komentarz w środku? Ponownie, PowerShell daje ci tę moc.

Zauważ, że używając komentarza w stylu blokowym, uzyskujesz możliwość posiadania komentarza w środku polecenia i nadal wykonywać lub interpretować elementy na prawo od niego. Wreszcie, możesz się zastanawiać, „co jeśli chcę wydrukować # lub zrobić coś podobnego?”. Jeśli spróbujesz

Zauważysz, że nie wypisuje tego, co chcesz. Otrzymasz po prostu:

W tym miejscu przydaje się grave-accent `.

W ten sposób zostanie wydrukowana żądana wiadomość.

Możesz również zawinąć cały ten ciąg w cudzysłów:

To by działało, ale chciałem dać przykład, jak uciec od kwalifikatora #.

Jeśli, tak jak ja, często używasz PowerShell ISE do pisania skryptów, jest jedna ostatnia przydatna sztuczka, którą chcę się podzielić, ale mogę ją tylko opisać i dać kilka zrzutów ekranu, a nie dostarczyć skrypt do niej. Jest to skrót klawiaturowy, który nie jest specyficzny dla komentarzy, ale przydatny, jeśli masz fragment kodu, który chcesz wykomentować, np. do testów. Umieść kursor na początku linii i trzymając wciśnięty Shift-Alt użyj klawiszy strzałek, aby przesunąć go w górę lub w dół. Zauważysz, że pojawi się cienka linia (niebieska na moim ekranie). Po zaznaczeniu linii, które chcesz skomentować, po prostu wpisz # i pojawi się on na początku każdej linii.

To jest przykład kodu do komentowania:

Klikając na prawo od tekstu w linii 40 i po kilkukrotnym naciśnięciu Shift-Alt i strzałki w górę, zobaczysz niebieską linię:

Po naciśnięciu # <space> zobaczysz znaki dodane do kodu:

Jako uwaga, możesz użyć tej sztuczki w dowolnym miejscu w linii (więc jeśli chciałbyś umieścić kilka komentarzy na końcu wielu linii, mógłbyś użyć tej sztuczki, aby łatwo wstawić # dla ciebie) i oczywiście nie jest specyficzny dla komentowania, ale jest to jedno z najbardziej oczywistych zastosowań. Możesz to również zrobić używając wyrażeń regularnych. Zaznacz blok kodu, o którym mowa:

Następnie naciśnij Ctrl-H, aby wyświetlić okno dialogowe Znajdź i zamień. Upewnij się, że zaznaczone są opcje Znajdź w zaznaczeniu i Wyrażenia regularne:

Dziennik ^ jest używany do zakotwiczenia początku linii i oczywiście # (jest tam spacja) w zasadzie wstawia # i spację na końcu zaznaczonych linii. Uwaga, jeśli nie uda Ci się podświetlić bloku kodu, będzie to działać na cały skrypt.

And More

Jednakże, gdyby to było wszystko, co komentarze mogą zrobić w PowerShell, byłby to bardzo krótki i nudny artykuł (a mój edytor kręciłby głową mówiąc: „Greg, potrzebuję więcej niż 850 słów!”). Jak wiele rzeczy w PowerShell, twórcy dodali funkcje, które czynią go bardziej potężnym, niż można by się spodziewać.

Przygotowywałem się ostatnio do prezentacji, którą wygłaszałem w Hampton Roads SQL Server User Group. Podczas tej prezentacji uruchamiam w PowerShell skrypt, który uruchamia i zatrzymuje SQL Server. Aby to zrobić, muszę uruchomić go jako administrator. Oczywiście zupełnie o tym zapomniałem podczas ćwiczeń i kiedy uruchomiłem go jako ja, skończyło się na wyrzuceniu kilku brzydkich błędów. Nie było to nic nadzwyczajnego, ale nie jest to coś, czego byśmy chcieli podczas dema. To skłoniło mnie do zastanowienia się, w jaki sposób mogę zapewnić, że to się nie stanie podczas rzeczywistej rozmowy.

Moją pierwszą myślą było znalezienie jakiegoś cmdleta, który sprawdziłby, jako kto jestem zalogowany, a następnie przerwałby, jeśli nie jestem właściwym użytkownikiem. Częścią problemu z tym podejściem jest oczywiście to, że kiedy uruchamiasz program (taki jak PowerShell ISE) jako administrator, pojawiasz się jako zalogowany użytkownik. To miało być trudniejsze niż myślałem.

Po raz kolejny PowerShell mnie zaskoczył. Rozwiązanie tego problemu jest banalnie proste. Aby zobaczyć, jak rozwiązać problem, otwórz PowerShell ISE jako użytkownik (tj. NIE wybieraj opcji Uruchom jako administrator i upewnij się, że Twój użytkownik nie ma lokalnych uprawnień administratora) i wprowadź następujący kod:

Zapisz to do pliku o nazwie restart timer service example.ps1, a następnie spróbuj go uruchomić. Jeśli nie jesteś lokalnym administratorem na swojej maszynie, powinieneś otrzymać ekran błędu podobny do poniższego.

Jeśli uruchomisz to używając opcji Uruchom jako Administrator, powinno to działać bez błędu. W tym przykładzie awaria jest dość łagodna, ale być może piszesz skrypt, w którym awaria nie byłaby tak nieszkodliwa. Aby rozwiązać ten problem, po prostu umieść następujący komentarz na górze powyższego skryptu i zapisz go ponownie.

Teraz otrzymasz inny błąd:

To wciąż jest trochę brzydkie, ale o wiele lepsze niż uruchamianie skryptu i być może łamanie czegoś. Zauważ, że jeśli po prostu wytniesz i wkleisz skrypt do nowego okna, ale nie zapiszesz go, PowerShell będzie próbował uruchomić całość. Zasadniczo #requires jest ignorowany, chyba że jest to faktycznie zapisany plik. To rozwiązało mój początkowy problem, ale skłoniło mnie do przyjrzenia się innym funkcjom, których nie byłem świadomy. Dla #requires, jest cała lista:

Jak widać, dają one dużą władzę w kontrolowaniu, jak i kiedy twój skrypt jest uruchamiany. Opcja #Requires –Version jest przydatna, jeśli skrypt wymaga funkcji, które są dostępne tylko w nowszej wersji PowerShell. Zauważ, że jest to liczba minimalna. Wersja PowerShell, którą uruchamiasz, musi być zgodna z tym lub wyższa. Nie możesz użyć tego do wymagania wcześniejszej wersji PowerShell. Na przykład przydatny cmdlet, którego użyłem w niedawnym skrypcie, to compress-archive. Na szczęście ten skrypt był specyficzny dla problemu, który próbowałem rozwiązać, ale gdybym próbował napisać bardziej ogólny skrypt, mógłbym chcieć umieścić #requires –Version 5.0 na końcu mojego skryptu. Aby zademonstrować, zapisz poniższy skrypt jako wymaganą wersję example.ps1.

Jeśli uruchomisz to w istniejącej instancji PowerShell ISE, powinno to działać bez problemu, ale jeśli spróbujesz uruchomić w starszej wersji, takiej jak PowerShell 2.0, skrypt popełni błąd na linii #requires i nie wykona reszty skryptu. To jest pożądany rezultat.

Do testowania, możesz również umieścić coś takiego jak –Version 99.99 i zobaczysz komunikaty o błędach podobne do przykładów poniżej, ale chciałem pokazać, jak to będzie działać w prawdziwym świecie na istniejących systemach, a także zademonstrować zdolność linii poleceń do powrotu do poprzedniej wersji PowerShell.

Aby to przetestować, należy użyć PowerShella w wersji wiersza poleceń i uruchomić go w następujący sposób:

Potem uruchom plik, który zapisałeś powyżej requires version example.ps1. Powinieneś zobaczyć błąd taki jak:

Chociaż zalecałbym umieszczenie komentarza #Requires na samym początku pliku, tak naprawdę możesz go umieścić w dowolnym miejscu i będzie działał tak samo. Jeśli odtworzysz powyższy plik, ale przesuniesz komentarz w dół po Get-Process i zapiszesz jako wymaga wersja przykład Version 2.ps1.