Ponieważ poprzedni artykuł o Bashu okazał się bardzo poczytny, postanowiłem stworzyć mini serię artykułów o mniej lub bardziej znanych poleceniach i funkcjach wbudowanych w basha, czy przydatnych skrótach.
Bash Bushido to książka poświęcona podsystemowi Linux / Unix / Windows dla systemu Linux (WSL), która zawiera około 150 sztuczek i wskazówek dotyczących pracy w- i z konsolą, w szczególności pisaniem skryptów w powłoce Bash. Poradnik przeplata się ze specyficznym poczuciem humoru autora i garścią anegdot. Głównymi odbiorcami książki są inżynierowie SysAdmins / DevOps.
Źródłowa wersja poradnika Bash Bushido (w języku angielskim) znajduje się na githubie, gdzie także można zgłaszać poprawki (wersja do czytania github.io/bash-bushido-book/). Jest również dostępna wersja na czytniki e-booków Bash Bushido Kindle Edition. Na niniejszym blogu mamy zaszczyt przedstawić polską wersję pisaną przez samego autora. Zapraszamy :)
W tej części cyklu Bash Bushidō dla wojowników konsoli opowiem o edytorze Vim oraz o następnych funkcjach biblioteki readline.
W trzeciej części drogi bashowego wojownika przyjrzymy się „desygnatorowi zdarzeń” oraz jego przyjaciołom: „desygnatorowi słów” i „modyfikatorom”. Na koniec udoskonalimy także klasykę hakera.
Każdy z nas ma swoją historię. Na szczęście nie będziemy się zajmować trudnymi, zawiłymi i nie zawsze moralnie jednoznacznymi ludzkimi historiami. Naszą historią będzie dzisiaj historia w Bashu, czyli biblioteka oraz plik tekstowy prosto z projektu GNU, z której Bash korzysta. Będziemy sterować zachowaniem tej biblioteki poprzez odpowiednie ustawienia zmiennych w powłoce.
Techniki stosowane w testowaniu oprogramowania można podzielić na wiele kategorii. Jedną z nich jest podział testowania ze względu na to, czy będziemy działać na uruchomionym programie/aplikacji/skrypcie, czy też nie. Jak łatwo się domyślić, testowanie statyczne zawiera w sobie techniki, które działają na nieuruchomionym programie oraz/lub jego artefaktach. Z kolei testowanie dynamiczne wymaga działania programu lub jego fragmentu (np. modułu). Dziś omówimy przydatne narzędzie ShellCheck do statystycznej analizy skryptów bashowych, które pomaga pisać lepsze skrypty.
Korzystając z sieci typu P2P (np. Torrent), zdarza nam się pobrać zawartość, w której jest plik README. W pliku tym z reguły znajdziemy informację à propos osoby lub grupy, która tę zawartość przygotowała lub udostępniła. W tej części Bash Bushidō zajmiemy się tematem wypisywania tekstu na ekran – oczywiście w niecodzienny sposób. Jest to najlżejsza część naszej drogi wojownika.
Można być fanem skryptów powłoki lub ich po prostu nie lubić. Nie zmienia to faktu, że czy nam się to podoba, czy nie, wciąż występują „często i gęsto”. Co – o zgrozo – jeszcze straszniejsze, czasem sami je piszemy! Tworząc nietrywialne skrypty, będziemy zmuszeni prawdopodobnie na pewnym etapie odpluskwiać (usuwać błędy), czyli debugować kod skryptu.
W tym artykule poruszę temat, który może zostać niesłusznie uznany za krytykę administratorów systemów oraz Basha. Uważam jednak, że należy spojrzeć prawdzie w oczy i zauważyć, że od czasu do czasu zdarza nam się popełniać te same błędy. Nie zawsze są one naszą winą. Czasem ustanowione techniki i narzędzia (takie jak Bash) po prostu obiektywnie niezbyt nadają się do zadań, które są przed nami stawiane.