Czerwiec minął, a nowego PowerShella nie ma

Środowiska PowerShell nie trzeba reklamować żadnemu administratorowi systemów Windows. Potęga i elastyczność tej powłoki czynią zarządzanie systemami Windows Server i domenami Active Directory znacznie łatwiejszymi, niż z użyciem narzędzi Resource Kit i makabrycznych skryptów Visual Basic Script. PowerShell eliminuje również konieczność posiadania pulpitu na systemach serwerowych, zamiast tego oferując zarządzanie z wykorzystaniem standardu typu SOAP o nazwie WS-Management (zaimplementowanego jako WinRM, dostarczający zresztą problemów nie mniejszych, niż Zdalny Pulpit).

Interpreter poleceń PowerShella jest stworzony w .NET i pozwala na stosunkowo łatwe wołanie klas dostępnych w ramach .NET Framework. Możliwości są więc nieograniczone i odbywa się to znacznie taniej, niż w przypadku VBS: języka wyraźnie bardziej męczącego, niezgodnego w zasadzie ani z językiem Visual Basic 6.0, ani (tym bardziej!) z wersją VB.NET. To coś, co jest w Windowsach bardzo potrzebne, by w pewnych kwestiach mogły konkurować z systemami o uniksowej filozofii zarządzania. Zaawansowana znajomość PowerShella pozwala poznać rzeczywisty potencjał narzędzi serwerowych Microsoftu. Z pewnej perspektywy (acz jest to lekkie nadużycie), można patrzeć na graficzne narzędzia Windows jak na nakładki na powershellowe cmdlety.

Wraz z przejściem rozwoju .NET na wersję Core, PowerShell otrzymał wersję Core, również wieloplatformową. Wydanie o numerze 6.0 miało więc również swoją wersję linuksową. Jak okazało się po kilku latach, skala popularyzacji powłoki pwsh (interpretera PowerShell Core) na systemach linuksowych jest znikoma. Inaczej sprawa ma się na systemach Windows, gdzie mimo pewnych braków, wersja 6.0 znalazła setki tysięcy użytkowników.

Linuksowy PowerShell nie był tylko eksperymentem dla dziwaków. Docelowo miał być środowiskiem umożliwiającym komunikację i zarządzanie szeregiem produktów bez konieczności instalowania pełnego Windowsa. Za przykłady niech służą takie produkty, jak Hyper-V, VmWare vCenter PowerCLI i Microsoft SQL Server. Każde z nich zawiera moduły PowerShella służące do zarządzania. Początkowo, każde z nich wymagało PowerShella 5.1 i systemu Windows 7 (z aktualizacjami) lub nowszego.

Okazuje się jednak, że wiele zależności pozostaje nierozwiązanych i narzędzia po prostu potrzebują pełnego Windowsa, bo tylko w nim (i w starym PowerShellu!) znajdują się potrzebne API. Innymi słowy, wersja Core nie była w stanie zastąpić pełnej, zupełnie tak, jak „lepszy” .NET Core nie potrafił wygrać ze starym i skostniałym .NET Frameowrk. Nikt też nie zdecydował się najwyraźniej na szersze wykorzystanie PowerShella jako alternatywy dla powłoki bash...

Filozofia pracy z powłoką PowerShell to w sumie najlepsza metoda ukazania różnic między systemem Windows a systemami uniksowymi. Bardzo wielu użytkowników systemów z Linuksem w środku podaje dość marginalne lub estetyczne argumenty kreślące odmienności między dwoma owymi systemami. Fundamentalne różnice sprowadzają się jednak do dwóch podstawowych kwestii:

• Uɴɪx jest systemem, w którym wiele małych narzędzi składa się w ciągi czynności: intensywne wykorzystanie strumieni wejścia i wyjścia, wraz ze zbiorem małych programów, pozwala im pracować razem, niskim kosztem tworząc kolejne programy. Windows dostarcza duże, samozawarte narzędzia, które komunikują się ze sobą za pomocą opcjonalnych, wyższych warstw, jak OLE i DCOM.
• Windows jest systemem wykorzystującym API oraz obiekty. Uɴɪx jest systemem opartym o strumienie bajtów.

PowerShell intensywnie wykorzystuje punkt drugi. Powłoka PowerShella jest obiektowa i wszystkie elementy, o ile nie zostaną jawnie rozłożone na łańcuchy, mają być docelowo obiektami. Różnicę widać na przykład w ramach iterowania po plikach. W przypadku powłoki bash, aby iterować po plikach w bieżącym katalogu, należy wypisać ich nazwy bez żadnych dodatkowych ornamentów (jak data i rozmiar), zadbać o typ separatora (IFS), a następnie korzystać z założenia, że każda kolejna linia jest kolejną iteracją. Oburzonych niniejszą pętlą, w tym autorów pogróżek i wulgaryzmów w komentarzach informuję, że backtick zamiast $() oraz brak testu i escape'ów są tutaj celowe, a wyjaśnienie znajduje się niżej:

Z kolei w języku PowerShell, lista plików otrzymywana wskutek wypisania zawartości katalogu jest zbiorem obiektów. Aby po nich przeiterować, należy skorzystać z mechanizmu pipe i zasilić wyjściem cmdlet Foreach-Object. Łączenie programów w ciągi jest taką samą koncepcją, jak w uniksach, różnicą jest co przesyłamy przez tak utworzony pipe. Będą to bowiem obiekty. Celem wypisania np. nazwy każdego z nich, należy wybrać z obiektu własność 'Name'.

Odpada konieczność przejmowania się końcami linii, zanieczyszczenia wyjścia przez niestandardowe symbole i tak dalej. Pod tym względem PowerShell jest znacznie bardziej zaawansowany, niż Bash i często w Bashu tej cechy brakuje. Zwłaszcza, gdy obiektami nie są pliki, jak w powyższym przykładzie, ale np. bazy danych, maszyny wirtualne lub komputery w domenie. Traktowanie ich jako obiekty jest banalne w PowerShellu i horrendalnie skomplikowane w Bashu, dlatego do tego celu wykorzystuje się np. Pythona.

Niemniej, obecnie PowerShell na Linuksie umie znacznie mniej, niż Python na Windowsie. Raczej nikt nie migruje swoich skryptów na linuksowego PowerShella, pozostawiając workflow na Windowsach, a celem uniknięcia problemów z API, trzyma się w dodatku wersji 5.1... Wydanie 7.0 ma rozwiązać te problemy. Co takiego oferuje w tym momencie? Przede wszystkim migrację na platformę .NET Core 3.0 i bardzo dużo porządków pod spodem, ale da się znaleźć kilka ciekawych szczegółów:

• Bezpieczne(https://github.com/PowerShell/PowerShell/pull/7993) parsowanie binarne
• Obsługa katalogów z plikami OneDrive
• Breakpoint debugerski(https://github.com/PowerShell/PowerShell/pull/8923) jako obiekt (!)
• Type SecureString obsługiwany poza Windows (choćby ten deta ułatwi migrację z 5.1)

Wśród kwestii, które nadchodzą, znajdują się między innymi:

• Równoległe iterowanie(https://github.com/PowerShell/PowerShell-RFC/pull/194) w ramach pętli Foreach-Object. Z algorytmicznego punktu widzenia, podstawowa różnica między For i Foreach jest taka, że For jest sekwencyjne, a Foreach nie musi. Dotychczas Foreach-Object nie mogło takie być, obecnie oferuje przełącznik -Parallel
• Skrócone operatory warunkowe (pytajnik-dwukropek)
• Ułatwione sprawdzanie null-typów(https://github.com/PowerShell/PowerShell/issues/3240) oraz łatwiejsze przeglądanie zawartości zmiennej błędu ($error)

Nowy PowerShell obiecuje bardzo wiele. Być może jednak migracji na najnowsze wersje pomoże dopiero zintegrowanie go z systemem. W jednym z ogłoszeń, Microsoft poinformował o rozpoczęciu negocjacji, mających na celu opracowanie metody wciągania PowerShella do najnowszych wersji Windows, gdy będzie możliwe bezbolesne zastąpienie silnika wersji 5.1.

Opóźnienia w wydaniu Preview 2 nie muszą wynikać z samego przejścia na (nieukończony wszak) .NET Core 3.0. Powodem będzie raczej konieczność zmierzenia się z odkładanymi dotychczas problemami, leżącymi u podstaw różnic między wersją Core a wydaniem klasycznym. Moment ten musiał jednak nadejść. Możliwe, że Preview 2 czai się tuż za rogiem. Gdy zostanie wydany, przetestujemy go w redakcji, dzieląc się opiniami.

Czy używacie PowerShella? Jeżeli tak, to w jaki sposób? Zbadamy, czy najczęstsze scenariusze są wykonalne w wersji 7.0.