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
Komentarze: