one-liner vs. skrypt

Zauważyłem wiele pytań, odpowiedzi i komentarzy wyrażających pogardę dla (a czasem nawet strachu) pisania skryptów zamiast jednowierszowych. Więc chciałbym wiedzieć:

• Kiedy i dlaczego powinienem pisać samodzielny skrypt zamiast „one-liner”? Lub odwrotnie?

• Jakie są przypadki użycia oraz zalety i wady obu?

• Czy niektóre języki (np. Awk lub perl) lepiej pasują do jednowierszowych niż inne (np. Python)? Jeśli tak, dlaczego?

• Czy jest to tylko kwestia osobistych preferencji lub czy istnieją dobre (tj. Obiektywne) powody, aby napisać jedno lub drugie w szczególnych okolicznościach? Jakie są te powody?

Definicje

• one-liner: dowolna sekwencja poleceń wpisana lub wklejona bezpośrednio w linii poleceń powłoki . Często z udziałem rurociągi i / lub korzystanie z języków takich jak sed, awk, perli / lub narzędzi jak grepalbo cutalbo sort.

  Definiująca jest bezpośrednia realizacja w wierszu poleceń - długość i formatowanie są nieistotne. „Jednowierszowy” może znajdować się w jednym wierszu lub może mieć wiele wierszy (np. Sh dla pętli lub osadzony kod awk lub sed, z przejściami linii i wcięciami w celu poprawy czytelności).

• script: dowolna sekwencja poleceń w dowolnym interpretowanym języku (językach), które są zapisywane w pliku , a następnie wykonywane. Skrypt może być napisany w całości w jednym języku lub może być opakowaniem skryptu powłoki wokół wielu „jednowierszowych” przy użyciu innych języków.

Mam własną odpowiedź (którą opublikuję później), ale chcę, aby stała się ona kanonicznym pytaniem i odpowiedzią na ten temat, a nie tylko moją osobistą opinią.

Kolejna odpowiedź oparta na doświadczeniu praktycznym.

Użyłbym jednowierszowego kodu, gdyby był to kod „wyrzucający”, który mógłbym napisać bezpośrednio po znaku zachęty. Na przykład mogę użyć tego:

for h in host1 host2 host3; do printf "%s\t%s\n" "$h" "$(ssh "$h" uptime)"; done

Użyłbym skryptu, gdybym uznał, że warto zapisać kod. W tym momencie dodam opis na górze pliku, prawdopodobnie dodam trochę sprawdzania błędów, a może nawet sprawdzę go w repozytorium kodu do wersji. Na przykład, jeśli zdecyduję, że sprawdzanie czasu działania zestawu serwerów jest przydatną funkcją, z której będę korzystać wielokrotnie, powyższy jeden wiersz może zostać rozszerzony do tego:

#!/bin/bash
# Check the uptime for each of the known set of hosts
########################################################################
#
hosts=(host1 host2 host3)

for h in "${hosts[@]}"
do
    printf "%s\t" "$h"
    uptime=$(ssh -o ConnectTimeout=5 -n "$h" uptime 2>/dev/null)
    printf "%s\n" "${uptime:-(unreachable)}"
done

Można powiedzieć, że uogólniając

• Jednowarstwowy

  • Prosty kod (tj. Tylko „kilka” instrukcji), napisany w określonym celu jednorazowym
  • Kod, który można szybko i łatwo napisać, gdy jest potrzebny
  • Kod jednorazowy

• Scenariusz

  • Kod, który (prawdopodobnie) zostanie użyty więcej niż raz lub dwa razy
  • Złożony kod wymagający więcej niż „kilku” instrukcji
  • Kod, który będą musiały być utrzymywane przez innych
  • Kod do zrozumienia przez innych
  • Kod uruchamiany bez nadzoru (na przykład z cron)

Widzę tutaj sporo pytań na unix.SE, które wymagają jednego linijki do wykonania określonego zadania. Korzystając z powyższych przykładów, uważam, że drugi jest znacznie bardziej zrozumiały niż pierwszy, a zatem czytelnicy mogą się z niego dowiedzieć więcej. Jedno rozwiązanie można łatwo wyprowadzić z drugiego, dlatego w celu zapewnienia czytelności (dla przyszłych czytelników) powinniśmy prawdopodobnie unikać umieszczania kodu wciśniętego w jednym wierszu dla wszystkiego innego niż najbardziej trywialne z rozwiązań.

Napisz skrypt, gdy:

• wymagany jest więcej kodu
• cenisz czytelność
• konieczne / przydatne jest dodawanie komentarzy, aby pokazać, co robi kod
• musisz przekazać parametry
• chcesz, aby skrypt działał we własnym środowisku (zmienne itp.)
• prawdopodobnie zamierzasz ponownie użyć / dostosować kod do bardziej złożonego celu

Napisz linijkę, gdy:

• potrzebna jest tylko niewielka ilość kodu
• chcesz uzyskać dostęp do zmiennych zdefiniowanych w bieżącej powłoce
• potrzebujesz szybkiego i brudnego rozwiązania

Gdy wymagana seria poleceń jest dość krótka i / lub daje wynik, który mógłby być użyteczny jako część większego potoku lub aliasu poleceń, może to być dobry jednowierszowy.

Zasadniczo myślę, że jednolinijki są zwykle rzeczami, które doświadczony administrator systemu zaznajomiony zarówno z problemem, jak i zastosowanymi poleceniami może napisać na miejscu, bez zbytniego zastanawiania się.

Kiedy jednowierszowa staje się zbyt długa lub wymaga więcej niż bardzo prostych warunków lub pętli, zwykle lepiej jest napisać je jako wielowierszową funkcję skryptu lub funkcję powłoki, aby zapewnić czytelność. Ponadto, jeśli jest to coś, co piszesz, aby było używane wielokrotnie, lub coś, co będzie używane (i być może problematyczne) przez inne osoby, powinieneś poświęcić czas na napisanie rozwiązania w sposób jasny, skomentowany, forma skryptu.

W Pythonie wcięcie jest częścią składni, więc dosłownie nie możesz w pełni korzystać z funkcji języka, jeśli piszesz jednowierszowy.

Jednoliniowe wersje Perla i awk często wymagają użycia surowej mocy wyrażeń regularnych. Ale niektórzy nazywają wyrażenia regularne językiem tylko do zapisu, nie całkiem bez powodu. Pisanie wielowierszowego skryptu pozwala pisać w komentarzach, aby opisać, co powinno robić określone wyrażenie regularne, co będzie bardzo pomocne, gdy spojrzysz na skrypt ponownie, po zrobieniu innych rzeczy przez sześć miesięcy pomiędzy nimi.

Jest to z natury bardzo oparte na opiniach pytanie, ponieważ polega na ocenie, jaki stopień złożoności jest dopuszczalny i kompromisach między czytelnością a zwięzłością; wszystko to jest bardzo kwestią osobistego osądu. Nawet wybór języka może zależeć od spraw osobistych: jeśli dany język byłby teoretycznie optymalny dla określonego problemu, ale nie znasz go i już wiesz, jak rozwiązać problem z innym językiem, możesz wybrać znajomy język, aby wykonać zadanie szybko i przy minimalnym wysiłku, chociaż rozwiązanie może być technicznie nieefektywne.

To, co najlepsze, jest często wrogiem wystarczająco dobrego , a dotyczy to tutaj bardzo dużo.

A jeśli jesteś zaznajomiony z Perl, może już słyszał o TMTOWTDI: Jest więcej niż jeden sposób, aby to zrobić.

Należy pamiętać, że jest to osobista opinia; Dodaj szczyptę soli.

1. Jeśli polecenie mieści się w powiedzmy 80 znakach, użyj jednowierszowej. Długie linie poleceń są trudne do pracy. Istnieje również problem nawrotów, patrz # 2

2. Jeśli chcesz uruchomić polecenie (polecenia) więcej niż raz, użyj skryptu. W przeciwnym razie użyj jednowarstwowej, pod warunkiem, że warunek nr 1 jest spełniony.

3. Jest to bardzo subiektywne, ale tak, widzę, że shell, Perl lub awk są moimi narzędziami dla jednowarstwowych.
4. Zobacz # 1, # 2, # 3.

Widzę i używam jednowierszowego narzędzia jako tymczasowego narzędzia programistycznego do wielokrotnej edycji, dopóki nie zrobi tego, co chcę, lub rozumiem, jak działa subtelność polecenia podrzędnego.

Następnie albo zostaje odnotowane (i opatrzone adnotacjami) w pliku tekstowym na badany temat, albo zostaje oczyszczone w skrypcie, który umieszcza się w mojej osobistej skrzynce PATH, być może w celu dalszego udoskonalenia, parametryzacji i tak dalej. Zazwyczaj jedna linia zostanie podzielona na bardziej czytelną, nawet jeśli nie zostaną wprowadzone żadne inne zmiany lub nigdy więcej nie użyję skryptu.

Ustawiłem moją historię powłoki na ponad 5000 linii, z osobną historią na terminal i na logowanie na pilocie i tak dalej. Nienawidzę nie być w stanie znaleźć w tych historiach jednego wiersza polecenia, które opracowałem kilka tygodni temu i nie sądziłem, że będę potrzebować ponownie, stąd moja strategia.

Czasami cała grupa poleceń musi coś zrobić, na przykład skonfigurować sprzęt; na koniec kopiuję je wszystkie z historii, czyszczę je minimalnie i dodam do skryptu powłoki RUNMEjako notatkę o tym, co zrobiłem, ale także, aby były prawie gotowe do ponownego użycia przez kogoś innego. (Dlatego znajduję narzędzia, które zapewniają tylko GUI, aby skonfigurować taki ból.) Uważam to za niesamowity wzrost wydajności, ponieważ tak często coś, czego oczekujesz tylko raz, musi zostać wykonane jeszcze 5 razy .. .

Chciałbym, aby ludzie w moim zespole pisali skrypty do wszelkich operacji, które mogą być wymagane do wykonania więcej niż jeden raz (tj. „Przepływy pracy” lub „potoki”), oraz do każdego jednorazowego zadania, które wymaga udokumentowania (zazwyczaj rzeczy takie jak „zmodyfikuj pewne rzeczy w niektórych zestawach danych, aby naprawić niepoprawnie dostarczone dane” w naszym przypadku). Poza tym „one-liners” lub skrypty nie mają większego znaczenia.

Nieprawidłowe udokumentowanie przepływów pracy (jako skryptów lub równoważnych) utrudnia wprowadzenie nowych pracowników do projektu, a także utrudnia przeniesienie ludzi z projektu. Dodatkowo utrudnia to wszelkiego rodzaju audytowanie, a śledzenie błędów może być niemożliwe.

Jest to niezależne od tego, jakiego języka używa się do programowania.

Inne miejsca pracy mogą mieć podobne / odmienne zwyczaje lub oczekiwania, być może nawet spisane.

W domu robisz, co chcesz.

Na przykład piszę skrypty, jak tylko zrobię coś niebanalnego w powłoce, na przykład przed przesłaniem odpowiedzi na pytanie dotyczące U&L, lub za każdym razem, gdy muszę przetestować poszczególne składniki polecenia lub zestawu poleceń przed uruchomieniem go dla real".

Piszę również skrypty do powtarzalnych zadań, które naprawdę chcę robić za każdym razem w ten sam sposób, nawet jeśli są one proste, takie jak

• aktualizacja mojego systemu OpenBSD i wszystkich zainstalowanych pakietów (sprowadza się to do trzech krótkich poleceń i kilku innych do sprzątania, zebranych w krótkim skrypcie) lub
• tworzenie kopii zapasowej mojego systemu w pamięci zewnętrznej (zasadniczo jedno polecenie, ale znowu z dość dużą ilością sprzątania, a skrypt pozwala mi również robić różnice między migawkami itp., i musi działać subtelnie inaczej w różnych systemach, i Uruchomię go z pracy crona) lub
• pobieranie poczty (ponownie, zasadniczo pojedyncze polecenie, ale chcę, aby zachowywało się inaczej, gdy jest wywoływane jako zadanie cron i gdy używam go z wiersza poleceń, i nie powinno próbować pobierać poczty pod pewnymi warunkami, i pisze krótki dziennik do pliku).

Korzystam z funkcji powłoki (bardzo rzadko aliasów) dla wygody w powłokach interaktywnych, np. Do domyślnego dodawania opcji do niektórych poleceń ( -Fdla ls) lub do tworzenia specjalistycznych odmian niektórych poleceń ( pmantutaj jest manpolecenie, które na przykład przegląda tylko instrukcje POSIX) .

Wygląda na to, że mam w tej sprawie pogląd mniejszości.

Termin „skrypt” jest celowo mylący, pozbyć się go. To oprogramowanie, które tam piszesz, nawet jeśli używasz wyłącznie bashi awk.

W zespole wolę pisać oprogramowanie z procesem sprawdzania kodu wymuszonym przez narzędzie (github / gitlab / gerrit). Daje to kontrolę wersji jako bonus. Jeśli masz wiele systemów, dodaj narzędzia do ciągłego wdrażania. I niektóre zestawy testowe, jeśli systemy docelowe są ważne. Nie jestem religijny, ale ważę korzyści i koszty.

Jeśli masz zespół administratorów, najprostsza vim /root/bin/x.shjest głównie katastrofą pod względem komunikacji związanej ze zmianami, czytelności kodu i dystrybucji między systemami. Często jedna poważna awaria kosztuje więcej czasu / pieniędzy niż rzekomo „ciężki” proces.

Właściwie wolę liniówki do wszystkiego, co nie zasługuje na ten „ciężki” proces. Można je szybko wykorzystać ponownie za pomocą kilku naciśnięć klawiszy, jeśli wiesz, jak skutecznie korzystać z historii powłok; łatwo wklejać między niepowiązanymi systemami (np. różnymi klientami).

Istotna różnica między (niepoddanymi przeglądowi!) Wersjami jedno-liniowymi a recenzowanym oprogramowaniem („skryptami”): odpowiedzialność za wykonanie jednej linijki spoczywa na tobie. Nigdy nie można powiedzieć do siebie „Właśnie znalazłem to gdzieś jedno-liner, wpadłem bez zrozumienia, co następuje nie jest moja wina” - wiedział używasz bit-of-oprogramowanie niezrewidowanemu i niesprawdzone, więc to jest twoja wina. Upewnij się, że jest wystarczająco mały, abyś mógł przewidzieć wyniki - niech cię diabli, jeśli tego nie zrobisz.

Czasami potrzebujesz tego uproszczonego podejścia, a ustawienie paska na około jeden wiersz tekstu dobrze sprawdza się w praktyce (tj. Granica między kodem sprawdzonym a nierecenzowanym). Niektóre z moich liniówek wyglądają przerażająco długo, ale działają dla mnie skutecznie. Tak długo, jak je omiatam i nie przekazuję go młodszym kolegom, wszystko jest w porządku. W chwili, gdy muszę je udostępnić - przechodzę standardowy proces tworzenia oprogramowania.

Muszę powiedzieć, że jestem nieco przerażony implikacjami pierwszych części pytania. Uniksowe języki skryptowe to pełnoprawne języki programowania, a języki programowania to języki , co oznacza, że ​​są one niemal tak samo nieskończenie plastyczne i elastyczne jak języki ludzkie. Jedną z cech charakterystycznych „nieskończonej plastyczności i elastyczności” jest to, że prawie nigdy nie ma „jednego właściwego sposobu” wyrażania czegoś - istnieją różne sposoby i to jest dobra rzecz! Tak, oczywiście jest to kwestia osobistych preferencji i nie ma w tym nic złego. Każdy, kto mówi, że jest tylko jeden sposób na zrobienie czegoś,

Dawno, dawno temu mój własny ~/binbył pełen „użytecznych” małych skryptów, które napisałem. Ale zdałem sobie sprawę, że większość z nich przyzwyczaiła się w dniu, w którym je napisałem, i nigdy więcej. Im więcej czasu mija, tym mniejszy jest mój binkatalog.

Nie sądzę, żeby było coś złego w pisaniu scenariusza. Jeśli wyobrażasz sobie, że ty lub ktoś inny może z niego ponownie skorzystać, napisz skrypt. Jeśli chcesz „odpowiednio zaprojektować” obsługiwany skrypt, zrób to. (Nawet jeśli nikt go nigdy nie używa, pisanie go jest dobrą praktyką.)

Powody, dla których nie piszę już skryptów (i, jak sądzę, faworyzuję „one-liners”):

• binbałagan w katalogu ma swój koszt. Nie umieszczam już tam żadnych rzeczy, chyba że naprawdę tam są.
• Języki skryptowe, których używam, to języki, których używam ; Do tej pory jestem z nimi bardzo łatwa. Ponowne przepisanie jednej linijki, gdy jest to potrzebne, nie wydaje się pracą; Nie czuję mandatu do przechowywania, zapisywania i używania skryptu tylko po to, aby zmniejszyć obciążenie związane z (ponownym) pisaniem. (Między innymi w pewnym momencie obciążenie związane z przepisywaniem staje się mniejsze niż obciążenie związane z pamięcią o tym, co to jest skrypt).
• Innym powodem, dla którego przepisywanie rzeczy nie wydaje się być ciężarem, jest: historia dowodzenia. Istnieje wiele jednowierszowych skryptów, których nie zapisałem jako skryptów, chociaż używam ich codziennie - ale nie muszę ich przepisywać; Po prostu pamiętam je z historii. W ten sposób są rodzajem skryptu lub pseudonimu biedaka.

Uważam, że w większości przypadków prośba o „jednoskładnik” jest w rzeczywistości prośbą o „ugryzienie dźwięku”, to znaczy:

W kontekście dziennikarstwa zgryz dźwięk charakteryzuje się krótką frazą lub zdaniem, która oddaje istotę tego, co mówca próbował powiedzieć, i służy do podsumowania informacji ...

Ludzie chcą i proszą o najkrótszy kod, który pokazuje rozwiązanie zadanego pytania.

Czasami nie ma sposobu na zredukowanie mowy do „ukąszenia dźwięku”, a także może być niemożliwe zredukowanie skryptu do krótkiej „jednej linijki”. W takich przypadkach jedyną możliwą odpowiedzią jest skrypt.

Zasadniczo „ugryzienie dźwięku” nigdy nie jest dobrym substytutem całej mowy. Tak więc „jedna linijka” jest na ogół dobra tylko do przekazania pomysłu lub praktycznego przykładu tego pomysłu. Następnie, po zrozumieniu pomysłu, należy go rozwinąć (zastosować) w skrypcie.

Napisz więc „linijkę”, aby przekazać pomysł lub koncepcję.

Napisz swój ogólny kod jako pełne skrypty, a nie jednowierszowe.

Pytasz o „strach i pogardę dla skryptów”. Wynika to z sytuacji Q + A, w której często odpowiedź brzmi: potrzebuje tego kroku i tego, ale mogę również umieścić go w jednym wierszu (abyś mógł skopiować i wkleić go i użyć go jako długiego prostego polecenia).

Czasami możesz tylko zgadywać, czy Q lepiej obsługuje szybkie i brudne rozwiązanie do wklejania kopii, czy też „ładny” skrypt jest dokładnie tym, co Q musi zrozumieć.

Wiele zalet i wad tutaj jest prawdą, ale wciąż nie mają racji. Powiedziałbym nawet, że definicje w Q nie są pomocne.

Pliki historii powłoki są „jednowarstwowe”, ale nadal są zapisywane. Funkcja bash operate-and-get-next (C-o)pozwala nawet powtarzać je półautomatycznie.

Prawie nie widzę wspomnianej funkcji słowa . W ten sposób można przechowywać zarówno „skrypty”, jak i „one linery”. Za pomocą kilku naciśnięć klawiszy możesz przełączać się między oboma formatami. Polecenie związek często dopasowania obu.

history -r fileto sposób na odczytanie jednego lub wielu wierszy poleceń (i komentarzy) z dowolnego pliku, nie tylko z domyślnego pliku historii. To zajmuje tylko minimalną organizację. Nie powinieneś polegać na dużym rozmiarze pliku historii i wyszukiwaniu historii w celu pobrania (niektórych) wersji wiersza poleceń.

Funkcje należy zdefiniować w podobny sposób. Na początek umieść thisfunc() {...}plik „funkcje” w katalogu domowym i zrób to. Tak, to pewne koszty ogólne, ale jest to ogólne rozwiązanie.

Jeśli każdy wiersz polecenia i każda odmiana skryptu są przechowywane w osobnym pliku, jest to (teoretyczne, ale obiektywne) marnotrawstwo bloków systemu plików.

One-liner sam w sobie nie ma nic szybkiego i brudnego. Chodzi raczej o tę część, która jest nieco niezadowolona, ​​i to, jak polegamy na historii poleceń, aby ją dla nas zapisać.

@sitaram: twoja jedna linijka ma naprawdę niecodzienne funkcje: linia shebang , nowa linia, cztery wywołania narzędziowe - dwa z nich to „programy”. Myślę, że oryginalny skrypt perla wyglądał ładniej i działał szybciej i nie marnował żadnych bajtów, rozkładając się na 60 linii. A perl pozwala ci również dość mocno wycisnąć.

Dla mnie jest to dokładnie jeden rodzaj wkładki, którego należy unikać. Czy chcesz mieć to (wklejone) w linii poleceń? Nie, a następnie, jeśli mimo wszystko przechowujesz go w pliku (bez względu na skrypt lub funkcję), możesz zainwestować dwa lub trzy bajty nowego wiersza, aby wyglądało to ładnie.

10 minut. później: Chciałem tylko sprawdzić, czy mogę powiedzieć „dwa programy sed”, czy też „dwa zamiany / wywołania sed”. Ale odpowiedzi sitaram już nie ma. Mam nadzieję, że moja odpowiedź nadal ma sens.