Jeśli używasz jakiegokolwiek Linuksa, to wiesz, że już “czysty” system posiada mnóstwo programów. Zwyczajnemu użytkownikowi aż nadto. Ale czasami okazuje się, że masz jakieś węższe zastosowanie i co prawda możesz męczyć się z istniejącym oprogramowaniem, ale w zasadzie lepiej by było, jakby gdzieś znalazł się bardziej wyspecjalizowany program. Poszukiwania w google nie dają żadnych rezultatów, programować za bardzo nie umiesz, a napisanie przez kogoś odpowiedniego programu kosztuje majątek. W pewnym momencie przypominasz sobie, że jednym z największych atutów Linuksa są skrypty powłoki.

Gdzieś już widziałeś jakiś skrypt, jak go podejrzałeś, to nie wyglądał na taki straszny. W sieci jest mnóstwo poradników, które mówią o skryptach powłoki, każdy z nich daje olbrzymią ilość przykładów, ale to zazwyczaj są skrypty, które spełniają podstawowe funkcje. Poniżej postaram się przedstawić kilka prostych rad odnośnie tego od czego zacząć i na co zwrócić uwagę zacząć, żeby w efekcie działań powstał skrypt, który jest przydatny, nie zaś czysto teoretyczny. Nie będę przedstawiał tego na przykładach, jest ich od groma choćby na tym portalu. Osobiście piszę skrypty w powłoce bash, ale w zasadzie dla początkującego nie ma zbyt wielkiej różnicy między poszczególnymi powłokami (no, chyba, że są dedykowane do konkretnych celów jak np nologin czy wish).

1. Zdefiniuj konkretny cel

Zanim zaczniesz cokolwiek robić i pisać – pomyśl czego dokładnie chcesz. Jeśli nie zdefiniujesz sobie celu, nie będzie szans osiągnięcia go.

2. Zdefiniuj etapy

Jeśli już masz konkretny cel, pomyśl jak twoim zdaniem najłatwiej go osiągniesz. Spróbuj podzielić go na etapy. Na przykład, jeśli twoim celem byłoby chodzenie w czystych ubraniach, to etapami byłoby zdjęcie ubrań, włożenie ubrań do pralki, wsypanie proszku, odpalenie prania, wyjęcie z pralki i powieszenie na sznurkach, oczekiwanie na wyschnięcie ubrań, założenie czystych ubrań i chodzenie w czystych ubraniach. Podobnie sprawa wygląda ze skryptami – też musisz przemyśleć całą drogę do realizacji swojego pomysłu. Jest to najtrudniejszy element całego procesu, niestety też najrzadziej wymieniany. To za ten schemat postępowania płacisz programistom. Tutaj nie chodzi o znalezienie najprostszego sposobu, który ma jak najmniej kroków, tutaj chodzi o znalezienie sposobu, który wiesz jak zrealizować. Jeśli dobrze podzielisz cały swój skrypt na elementy składowe, to napisanie go zajmie ci niewiele czasu.

3. Pracuj nad jednym etapem jednocześnie

Jeśli już masz skrypt podzielony na kolejne etapy – zacznij realizować je w liniach kodu. Każdy z etapów oddzielaj komentarzem opisującym dany fragment. Jeśli piszesz etap drugi – sprawdź, czy na pewno otrzymuje z etapu pierwszego, wszystko co jest mu potrzebne. Korzystając przykładu z pralką – aby włożyć ubrania do pralki, musisz je mieć w ręku, nie zaś na sobie. Jeśli chcesz w jakimś etapie przeanalizować ściągnięty plik, to plik ten musi zostać pobrany we wcześniejszym etapie.

4. Używaj komentarzy

Zostawiaj w skrypcie notatki. Masz do tego możliwości, możesz nawet zostawić pół strony notatek przy każdej linii kodu. To właśnie notatki pozwolą Ci bezproblemowo poprawić skrypt, jeśli trzeba będzie to zrobić za pół roku.

5. Korzystaj z dokumentacji

Jeśli gdzieś utkniesz – sięgnij do mana lub użyj google. Jeśli nie wiesz co dalej zrobić, jak wywołać jakieś polecenie, co z nim zrobić – poszukaj pomocy. Wszelkie przełączniki polecenia znajdziesz w manie, mniej standardowe zastosowania znajdziesz za pomocą google. Jeśli nie wiesz jakiego polecenia użyć – wpisz w google co chcesz zrobić, na pewno znajdziesz podpowiedź.

6. Unikaj skrótów na siłę

Czasami można sobie skrócić polecenie, za pomocą przełączników innego polecenia. Wtedy kod jest “czystszy” i bardziej trendi. Przy okazji często mniej zrozumiały. Najprostszym przykładem jest tutaj polecenie grep. Za jego pomocą możemy wszystko wykonać na dwa sposoby przekazując mu tekst, który obrobi np.

cat plik.txt | grep poszukiwania

jak i wywołać samodzielnie

grep poszukiwania plik.txt

Wszystko jest czytelne, ale do pewnego momentu. Jeśli dodamy grepowi kilka opcji, do tego za pomocą opcji -e każemy mu wyszukiwać więcej zwrotów, to nagle może się okazać, że zgubiliśmy gdzieś nazwę pliku w którym szukamy. Pierwsze wywołanie jest mniej trendy (i bardziej zużywa klawisze na klawiaturze), ale za to zmniejsza ryzyko naprawdę głupiej pomyłki. Czasami też widzimy, że wszystko tak ładnie się ze sobą składa, że możemy wszystkie kilkadziesiąt elementów skryptu umieścić w jednej linii. Wszystko w porządku, jeśli nie będzie trzeba poprawiać kodu. Rozłożenie tej pojedynczej linii na kilkanaście mniejszych linijek i zrobienie tymczasowego pliku (lub plików) a także dopisanie kilku komentarzy może w przyszłości znacznie ułatwić analizę i poprawienie lub dostosowanie całego skryptu. Przy okazji może okazać się, że część takiego skryptu da się wykorzystać w innym skrypcie.

7. Unikaj nieznanych elementów

Zawsze staraj się pisać w oparciu o znane Ci komendy. Oczywiście, szczególnie na początku jest to trudne. Ale staraj się w skrypcie nie zawierać zbyt wiele nowych poleceń. Jeśli wiesz, że coś zadziała, to nie szukaj na siłę alternatyw celem szeroko rozumianego samorozwoju. Awangardowe rozwiązania są świetne gdy projektujesz knajpę, w zwykłych skryptach często zawadzają. Zazwyczaj lepiej jest iść prosto do celu niż z finezją wylądować w koszu.

8. Definiuj wszystkie zmienne

Zawsze pisząc skrypt zwracaj uwagę na zdefiniowanie wszystkich zmiennych. O ile w językach programowania kompilator zazwyczaj poinformuje cię, że czegoś nie zdefiniowałeś, o tyle w skryptach powłoki brak definicji nie jest przeszkodą, po prostu efekt może być inny od spodziewanego.

9. Nietypowe wywołania

Jeśli twój skrypt wymaga jakiegoś parametru wpisywanego z linii poleceń – sprawdź co się stanie, jeśli zapomnisz go wpisać. Sprawdź co się stanie, jeśli wpiszesz dziwny (na przykład litery zamiast cyfr) parametr. A co się stanie, jeśli wpiszesz cyfrę z siedemnastoma zerami? Albo wręcz zero/liczbę ujemną? Jeśli często zdarzają Ci się przypadkowe pomyłki – może warto pomyśleć nad zabezpieczeniem skryptu i sprawienie, że źle wywołany po prostu nie zadziała (np prosty warunek wykonania – tylko jeśli zmienna leży w zakresie 1-100).

10. Etapy spowalniające

Jeśli widzisz, że któryś etap mocno spowalnia działanie całego skryptu – pomyśl co możesz z tym zrobić. Czasami droga naokoło zajmuje więcej kroków, ale jest znacznie szybsza. Warto też pomyśleć o zmniejszeniu danych wejściowych przed obróbką przez choćby odsianie ich poleceniem grep.

11. Testuj w bezpiecznym środowisku

Jeśli chcesz testować skrypt – spokojnie możesz wykorzystać konto utworzone specjalnie do tego celu. Jeśli przez błąd skryptu stracisz wszystkie dane (w zasadzie raczej się to nie zdarzy, ale lepiej zapobiegać niż leczyć) do których masz prawa zapisu – może ogarnąć cię złość (gdy zrobisz to na domyślnym koncie) lub rozbawienie (gdy wykonasz to na pustym koncie).

12. Uzyskuj zgodę właściciela maszyny

Jeśli masz skrypt, który wykonuje się codziennie, to warto zapytać o zgodę właściciela maszyny. Może podpowie o jakiej godzinie tego nie robić. Niektóre skrypty potrafią zamulić komputer (u mnie w systemie są takie dwa). Jeśli dwa takie spotkają się o jednej porze dnia, to mogą narobić niezłego bigosu.

  • jeshu

    "Jeśli dwa takie spotkają się o jednej porze dwa, to mogą narobić niezłego bigosu." – literówka, ale ogólnie bardzo dobrze się czytało. Dzięki!

  • jacek2v

    Bardzo fajny poradnik. Myślę, że przydatny nie tylko do pisania w bash, ale także w każdym innym języku programowania. A nawet do rzeczy, które nie są związane z informatyką :)

  • o_O

    Najlepiej w edytorze tekstu. Polecam Kate. Można też użyć czegoś konsolowego: nano, vi.

  • o_O

    > Pierwsze wywołanie jest mniej trendy

    Nie tylko mniej trendy, ale odpala także 2 procesy potomne, z czego jednemu (grep) tworzy całe nowe środowisko, i potem łączy oba procesy pipem.
    To drugie polecenie tworzy tylko jeden proces, który otwiera sobie deskryptor do pliku.

    Przy prostych grepach i małych plikach to ogromny narzut, który przy dużej ilości tych plików i współbieżnym odpalaniu grepów po prostu się zemści wielokrotnie wydłużonym czasem wykonania.

    Ponieważ nie każde polecenie obsługuje tak jak grep podanie mu nazwy pliku, można użyć konstrukcji:

    grep poszukiwania < plik.txt

    Niewielki narzut, uniwersalne rozwiązanie i nadal czytelne.

    • Eldorm

      Przy pliku 6 gb (dane z pomiarów) i 5 "-e " średnia różnic czasu wykonywania była praktycznie zerowa (maszyna testowa posiada 2 gb ramu, czyli 3 razy mniej niż ma plik, swap 1 gb). Może swoje teorie poprzesz jakimś testem? Jestem pewny, że osworld chętnie opublikuje.

    • o_O

      Przecież piszę, że chodzi o dużo małych plików, przy których koszt stworzenia procesów i narzut związany z streamowaniem danych będzie zauważalny (a sumarycznie mocno wydłuży wykonanie skryptu).

    • Makar

      Cytując Ciebie:
      "grep poszukiwania < plik.txt "
      Dużo małych plików, cały jeden.
      Jak podasz w cat dużo plików, to na grepa pójdzie 1 wyjście. Jak odpalisz 10 grepów po 1 pliku (zgodnie z Twoim prostszym wywołaniem polecenia), to masz 10 obróbek (i komplikacje w sterowaniu wyjścia – klamry itd). I gdzie tu ta Twoja oszczędność procesów? Twoje teoretyzowanie mówi, że to co podałeś powinno trwać znacznie dłużej. Ale jak zrobisz test, to zrozumiesz, że nie masz racji.
      Przestań czytać dokumenty sprzed 20 lat i powoływać się na ich fachowość.

    • o_O

      Przeczytaj może ze zrozumieniem co napisałem…

    • WJ_

      Człowieku, to się wzięło z czasów, gdy każdy proces był na wagę złota, bo czas procesora się wykupywało. Lata 60-te. I został taki kanon, podobnie jak wciąż żyjący język C.

    • o_O

      Głupoty gadasz. Procesy nadal są drogie, jeśliodpalasz ich tysiące albo więcej.
      Ale ty pewnie jesteś ztych, dla których rozwiązaniem na powolnośc Javy jest kazanie użytkownikowi kupić sobie nowy komputer… W końcu dzisiaj nie płaci się za czas procesora… A może jednak?

  • Savpether

    Używam Fedory i powiem szczerze, że uwielbiam skrypty w bashu – cholernie ułatwiają życie. Windowsa, ze wszystkimi aktualizacjami, oprogramowaniem i konfiguracją stawiam ludziom w ok. 5h (posiadam łącze 20 mb/s, najdłuższa jest instalacja aktualizacji i oprogramowania). Dzięki skryptom, po instalacji Fedory cała jej konfiguracja, instalowanie programów, restarty, aktualizacje, czcionki, dosłownie wszystko odbywa się za pomocą napisanego przeze mnie skryptu w góra 30 minut :)

    Pozdrawiam

    • Skryptu? To samo możesz zrobić za pomocą kickstarta i tam dodać swoje ustawienia co do systemu + skrypty poinstalacyjne.

  • klaster

    ja bym dodal iz jesli udostepniany jest jakis skrypt to nalezalo by na gorze w komentarzu napisac z jakich programow kozysta skrypt by potem nie bylo iz ktos kozysta wywoluje i ma kaszane mowiac ze nie dziala a zdazaja sie takie osoby