Najczęściej używane skrypty PowerShell w pracy programisty

Tytuł może być dla niektórych mylny, inni mogą się z nim nie zgadzać. Muszę od razu napisać, że zestawienie nie powstało na podstawie żmudnych i dokładnych badań grupy tysiąca losowo wybranych programistów z różnych krajów, różnych płci, różnych języków i w różnym wieku. To takie moje prywatne przemyślenia. Moim celem jest również rozpoczęcie dyskusji w komentarzach, bo domyślam się, że każdy ma swoją ulubioną listę. Dla mnie też będzie to jakiś rodzaj nauki i być może przykład nowych rozwiązań, które kiedyś wykorzystam. Przejdźmy do konkretów:

Wyszukiwanie pliku w podkatalogach

Wyszukiwanie plików to czynność, którą wykonuje pewnie każdy. Programista również. Nie wiem jak inni, ale ja nigdy nie pamiętam, gdzie leży plik hosts. Jest on gdzieś w katalogu Windows, ale gdzie? Wystarczy przejść do tego katalogu i wykonać polecenie:

ls hosts -Recurse -ErrorAction SilentlyContinue | select -ExpandProperty DirectoryName

Podobny skrypt, z tej samej kategorii, pozwala wyszukać wszystkie pliki konfiguracyjne, a dokładniej katalogi, w których te skrypty się znajdują.

ls *.config -Recurse | select -ExpandProperty DirectoryName

Pozwala to odnaleźć miejsca, które są kluczowe podczas wdrożeń i zmieniane w przypadku modyfikacji środowisk.

Trzeci z serii skryptów wyszukujących jest nieco bardziej rozbudowany, ale ciekawszy. Pozwala sprawdzić, które pliki zostały zmodyfikowane na przestrzeni 3 ostatnich dni. Tworzenie aplikacji jest procesem ciągłym, cały czas dokładane są nowe pliki, stare pliki są modyfikowane. Jeden błąd i aplikacja przestaje działać. Jeżeli problem jest natury programistycznej, warto przejrzeć ostatnie zmiany. Można to sprawdzić w jakimś systemie kontroli wersji (GIT, SVN, TFS), ale można też uruchomić następujący skrypt:

ls -Recurse |
where LastWriteTime -gt ([DateTime]::Today.AddDays(-3)) |
select Name,LastWriteTime,@{n="RelativePath";e={Resolve-Path -Path $_.FullName -Relative}}

Usunięcie zbędnych plików projektów Visual Studio

Visual Studio w trakcie swojej pracy tworzy różne pliki i katalogi. Przede wszystkim tworzy katalog z plikami binarnymi: bibliotekami lub plikami wykonywalnymi. Jest to naturalne, bo takie jego zadanie. Tworzy też inne pliki, których przeznaczenie nie jest tak jasne. Użytkownicy Visual Studio do wersji 2012 włącznie mogą się natknąć na plik *.suo (plik jest ukryty). Po co jest plik *.suo i co w nim siedzi? Plik swoje rozszerzenie przejął od pierwszych liter angielskiego Solution User Options, co dosłownie oznacza opcje użytkownika dla rozwiązania. Rozwiązanie (ang. solution) skupia w jednym miejscu projekty. W Visual Studio 2015 ustawienia użytkownika zostały przeniesione do katalogu .vs, również ukrytego. No i teraz potrzeba, która stała się matką skryptu. Programy po napisaniu trzeba czasami skompresować i wysłać do innego pracownika, zapisać na płycie, przenieść na jakimś urządzeniu USB. Nie ma potrzeby przenosić wszystkiego. To co zwykle zajmuje najwięcej miejsca to skompilowane biblioteki, które możemy odtworzyć dysponując kodem źródłowym. Biblioteki domyślnie znajdują się w katalogu bin i obj. Można je spokojnie usunąć razem z plikami użytkownika:

ls -Include bin,obj,*.suo,.vs -Recurse -Force | rm -Recurse -Force

Można się jeszcze pokusić o usuwanie katalogu rozszerzeń NuGet. Visual Studio może sobie ten katalog odtworzyć na podstawie zapisanej konfiguracji.

Sprawdzenie połączeń sieciowych

Rozbudowana infrastruktura sieciowa w dużej firmie może doprowadzić do nieprzyjemnych sytuacji. Wyobraźmy sobie, że korzystamy z poczty umieszczonej na jednym serwerze, korzystamy z systemu kontroli wersji SVN umieszczonego na drugim serwerze, korzystamy z Internetu, potrzebujemy połączenia z serwerem testowym, potrzebne nam połączenie z bazą danych, firma ma wewnętrzną stronę do zarządzania zadaniami. I wyobraźmy sobie w końcu, że coś nie działa i otrzymujemy komunikat o braku dostępności. Co robi administrator takiej sieci? Wykonuje polecenie ping. Robi to najczęściej w sposób mało zautomatyzowany pomimo dużej prostoty takiego rozwiązania:

"localhost","www.google.com","svn","mail.firma.pl" |
select @{n="ComputerName";e={$_}}, @{n="IsAvailable";e={Test-Connection -ComputerName $_ -Quiet}}, @{n="Date";e={Get-Date}}

Wykonanie takiego skryptu mogłoby dać następujący rezultat:

ComputerName    IsAvailable Date               
------------    ----------- ----               
localhost              True 2015-06-23 19:43:07
www.google.com         True 2015-06-23 19:43:10
svn                    True 2015-06-23 19:43:14
mail.firma.pl          True 2015-06-23 19:43:17

Usuwanie starych plików dziennika (logów)

Praktycznie każda większa aplikacja ma jakieś mechanizmy logowania. Logowane są wyjątki powstałe podczas działania aplikacji, operacje wykonywane przez użytkownika, często zapisuje się dane wymieniane z zewnętrznymi systemami. Każdy, kto miał do czynienia z logami wie, że potrafią one rosnąć jak dług publiczny. W sposób nieograniczony i nieskrępowany. Są wprawdzie takie sposoby logowania, które usuwają stare pliki automatycznie, ale, w moim odczuciu, są w mniejszości. Z tego powodu, warto mieć w arsenale jakiś prosty skrypt do usuwania przestarzałych plików. Załóżmy, że pliki mają rozszerzenie *.log. W takim przypadku moglibyśmy napisać następujący skrypt:

ls *.log | rm

Powyższy skrypt usunie wszystkie pliki z rozszerzeniem *.log z bieżącego katalogu. Gdybyśmy zechcieli usunąć pliki starsze niż tydzień, moglibyśmy zapisać to następująco:

ls *.log |
where LastWriteTime -lt ([DateTime]::Today.AddDays(-7)) |
rm

Skrypty tego typu będą się najczęściej różnić liczbą dni oraz filtrem (np. Log*.txt zamiast *.log).

Pobieranie dziennika zdarzeń systemu Windows

Wiele aplikacji zapisuje ważniejsze wydarzenia do dziennika zdarzeń Windows. Można wprawdzie wejść do Panelu sterowania, wybrać System i zabezpieczenia, następnie kliknąć Wyświetla dzienniki zdarzeń, potem przejść do odpowiedniej sekcji i przeglądać to, co nas interesuje. Gdy chcemy popatrzeć na błędy musimy założyć filtr lub przedzierać się przez dziesiątki logów poziomu informacyjnego. Aby napisać ścieżkę do podglądu logów w Panelu sterowania musiałem sprawdzić na swoim komputerze. A i to nie przyszło łatwo. Znacznie łatwiej zapamiętać polecenie PowerShell:

Get-EventLog -LogName Application

Polecenie pozwala pobrać wszystkie wpisy dziennika i jest to jego największa wada. Znacznie wygodniejsze wydają się poniższe instrukcje:

--Pobierz zdarzenia z poziomem Error
Get-EventLog -LogName Application -EntryType Error

--Pobierz 10 ostatnich zdarzeń z poziomem Error
Get-EventLog -LogName Application -EntryType Error -Newest 10

--Pobierz wszystkie dzisiejsze błędy z poziomem Error
Get-EventLog -LogName Application -EntryType Error -After ([DateTime]::Today)

Zdarza się, że logi należy gdzieś przesłać. W takim przypadku można je skonwertować na coś, co będzie łatwe w obróbce, na przykład CSV lub przyjemne do przeglądania, na przykład HTML:

--Plik w postaci CSV
Get-EventLog -LogName Application -EntryType Error -Newest 10 | Export-Csv -Path C:\Logi.csv -NoTypeInformation -Encoding UTF8 -Delimiter ";"

--Plik w postaci HTML
Get-EventLog -LogName Application -EntryType Error -Newest 10 | ConvertTo-Html > C:\Logi.html

Kontrola nad usługami SQL Server

SQL Server to innal liga niż kalkulator czy notatnik. Uruchomiony na lokalnej maszynie potrafi dość szybko skonsumować dużą część dostępnej pamięci operacyjnej, ale może mieć też wpływ na czas uruchamiania się całego systemu. To dlatego, na domowe potrzeby, warto usługę zatrzymać i uruchamiać tylko wtedy, gdy jest nam potrzebna:

Start-Service MSSQLSERVER
lub: sasv MSSQLSERVER

Po zakończeniu pracy można usługę zatrzymać:

Stop-Service MSSQLSERVER
lub: spsv MSSQLSERVER

Jeżeli mamy więcej instancji lub zatrzymujemy i uruchamiamy kilka usług, można odpowiednio połączyć wywołania:

#uruchom
gsv *SQLSERVER* | Start-Service
#zatrzymaj
gsv *SQLSERVER* | Stop-Service

Powyższe skrypty uruchomią jednocześnie silnik bazy danych, hurtownię danych oraz usługę agenta.

Podsumowanie

Powyższą listę uważam za otwartą i zachęcam do rozwijania jej w komentarzach. Z pewnością każdy ma swoje ulubione skrypty. Częstotliwość wykonywania skryptów z pewnością zależy od rodzaju wykonywanej pracy i pisanego systemu, dlatego wskazówki innych mogą być bardzo cenne.

Kategoria:PowerShell