Proč psát celý bash skript ve funkcích?

Začal jsem používat to samé styl bash programování po přečtení příspěvku blogu Kfir Lavi „Defensive Bash Programming“ . Uvádí několik dobrých důvodů, ale osobně mi připadají nejdůležitější:

• Postupy se stávají popisnými: je mnohem snazší zjistit, co má konkrétní část kódu předpokládat. co dělat. Místo zdi kódu uvidíte „Ach, funkce find_log_errors čte tento soubor protokolu kvůli chybám.“ Porovnejte to s nalezením spousty awk / grep / sed řádků, které použijte bůh ví, jaký typ regulárního výrazu uprostřed zdlouhavého skriptu – nemáte tušení, co to tam dělá, pokud tam nejsou komentáře.

• můžete ladit funkce uzavřením do set -x a set +x. Jakmile víte, že zbytek kódu funguje dobře, můžete pomocí tohoto triku zaměřit se na ladění pouze této konkrétní funkce. Jistě, můžete přiložit části skriptu, ale co když je to zdlouhavá část? Je snazší udělat něco podobného:

   set -x parse_process_list set +x 

• Použití tisku s cat <<- EOF . . . EOF. Už jsem to několikrát použil, aby byl můj kód mnohem profesionálnější. Navíc parse_args() s funkcí getopts je docela pohodlný. To opět pomáhá s čitelností, místo toho, aby se vše vešlo do skriptu jako obrovská zeď textu. Je také vhodné je znovu použít.

A samozřejmě je to mnohem více čitelné pro někoho, kdo zná C nebo Javu nebo Valu, ale má omezené bash zkušenosti. Co se týče efektivity, není toho moc, co můžete udělat – samotný bash není nejefektivnější jazyk a lidé dávají přednost rychlosti a efektivitě pro Perl a Python.Můžete však nice funkci:

nice -10 resource_hungry_function 

Ve srovnání s voláním nice na každém řádku kódu, to snižuje spoustu psaní a lze jej pohodlně použít, pokud chcete, aby se pouze část vašeho skriptu spouštěla s nižší prioritou.

Podle mého názoru také běžící funkce na pozadí také pomáhají, když chcete mít celý spousta příkazů spuštěných na pozadí.

Některé z příkladů, kde jsem použil tento styl:

• https://askubuntu.com/a/758339/295286
• https://askubuntu.com/a/788654/295286
• https://github.com/SergKolo/sergrep/blob/master/chgreeterbg.sh

Komentáře

• Nejsem si jistý, zda byste měli brát jakékoli návrhy z tohoto článku velmi vážně. Je pravda, že má několik dobrých nápadů, ale zjevně to není někdo, kdo by skriptování používal. Ne single v kterémkoli z příkladů je uvedena v citátu (!) a navrhuje použití UPPER C Názvy proměnných ASE, což je často velmi špatný nápad, protože mohou být v konfliktu s existujícími env vars. Vaše body v této odpovědi dávají smysl, ale zdá se, že odkazovaný článek napsal někdo, kdo je jen zvyklý na jiné jazyky a snaží se vnutit svůj styl do bash.
• @terdon Vrátil jsem se k článku a znovu si ho přečetl. Jediné místo, kde autor zmiňuje pojmenování proměnných velkých písmen, je “ Immutable Global Variables „. Pokud považujete globální proměnné za ty, které musí být v prostředí ‚ s prostředí, má smysl je učinit velkým. Postranní poznámka: bash ‚ s manual neuvádí ‚ konvenci stavu proměnných. I zde přijatá odpověď říká “ obvykle “ a jediný “ standardní “ je od společnosti Google, která ‚ nereprezentuje celé odvětví IT.
• @terdon k další poznámce, 100% souhlasím s tím, že v článku měl být zmíněn citát o proměnných a bylo na něj poukázáno také v komentářích na blogu. Také bych ‚ někoho, kdo používá tento styl kódování, neposuzoval, bez ohledu na to, zda ‚ byl znovu použit v jiném jazyce. Celá tato otázka a odpovědi jasně ukazují, že ‚ má to výhody a stupeň, do kterého iv id = „9b8d4d3bb1 ‚ „>

Čitelnost je jedna věc. Ale modularizace má víc než jen toto. ( Semi-modularizace je pro funkce možná správnější.)

Ve funkcích můžete ponechat některé proměnné lokální, což zvyšuje spolehlivost a snižuje pravděpodobnost věci se kazí.

Další výhodou funkcí je opakovaná použitelnost . Jakmile je funkce kódována, lze ji ve skriptu použít několikrát. Můžete jej také přenést do jiného skriptu.

Váš kód teď může být lineární, ale v budoucnu můžete vstoupit do sféry multi-threading nebo multi- zpracování ve světě Bash. Jakmile se naučíte dělat věci ve funkcích, budete dobře připraveni na krok do paralely.

Ještě jeden bod k přidání. Jak si Etsitpab Nioliv všimne v komentáři níže, je snadné jej přesměrovat z funkcí jako koherentní entity. Existuje ale ještě jeden aspekt přesměrování pomocí funkcí. Konkrétně lze přesměrování nastavit podél definice funkce. Např .:

f () { echo something; } > log 

Volání funkcí nyní nevyžaduje žádné explicitní přesměrování.

$ f 

To může ušetřit mnoho opakování, což opět zvyšuje spolehlivost a pomáhá udržovat věci v pořádku.

Viz také

• https://unix.stackexchange.com/a/483304/181255

Komentáře

• Velmi dobré odpovězte, i když by bylo mnohem lepší, kdyby to bylo rozděleno do funkcí.
• Možná přidáte, že funkce vám umožní importovat tento skript do jiného skriptu (pomocí source nebo . scriptname.sh a tyto funkce používejte, jako by byly ve vašem novém skriptu.
• Tyto ‚ jsou již zahrnuty v jiné odpovědi.
• To si vážím. Ale ‚ bych raději nechal důležité i ostatní lidi.
• Čelil jsem případu dnes, kde jsem místo echa musel přesměrovat část výstupu skriptu do souboru (poslat jej e-mailem). Musel jsem prostě udělat myFunction > > myFile k přesměrování výstupu požadovaných funkcí. Docela pohodlné. Může to být relevantní.

Ve svém komentáři jsem zmínil tři výhody funkcí:

1. Snadněji se testují a ověřují správnost.

2. Funkce lze v budoucích skriptech snadno znovu použít (získat)

3. Váš šéf je má rád.

A nikdy nepodceňujte důležitost čísla 3.

Chtěl bych se věnovat ještě jednomu problému:

… takže možnost libovolně vyměnit pořadí běhu není něco, co bychom obecně dělali. Například byste „najednou nechtěli dát declare_variables za walk_into_bar, což by to zlomilo.

Chcete-li získat výhodu rozdělení kódu na funkce, měli byste se pokusit tyto funkce vytvořit co nejnezávislejší. Pokud walk_into_bar vyžaduje proměnnou, která Pokud se jinde nepoužívá, pak by tato proměnná měla být definována v walk_into_bar a měla by být lokální. Proces rozdělení kódu na funkce a minimalizace jejich vzájemných závislostí by měl kód učinit jasnějším a jednodušším .

V ideálním případě by funkce měly být snadno testovatelné jednotlivě. Pokud se kvůli interakcím nedají snadno otestovat, znamená to, že by mohly mít prospěch z refaktoringu.

Komentáře

• I ‚ d tvrdím, že ‚ je někdy rozumné modelovat a vynutit tyto závislosti, vs. refaktorování, aby se jim vyhnulo (protože pokud existují enoug h z nich a ‚ jsou dostatečně chlupatí, což může vést jen k případu, kdy už věci nebudou modulovány do funkcí vůbec). Velmi komplikovaný případ použití kdysi inspiroval rámec k tomu, aby to udělal .
• Co je třeba rozdělit na funkce, by mělo být, ale příklad zachází to příliš daleko. Myslím, že jediný, kdo mě opravdu buguje, je funkce deklarace proměnné. Globální proměnné, zejména statické, by měly být globálně definovány v komentované části věnované tomuto účelu. Dynamické proměnné by měly být lokální pro funkce, které je používají a upravují.
• @Xalorous Viděl jsem praktiky, kde jsou globální proměnné inicializovány v proceduře, jako přechodný a rychlý krok před vytvořením procedury, která čte jejich hodnotu z externího souboru … Souhlasím, že by mělo být čistší oddělit definici a inicializaci, ale málokdy se musíte ohnout, abyste podstoupili výhoda číslo 3 ;-)

I když naprosto souhlasím s opětovnou použitelností , čitelností a jemným líbáním šéfů, ale v bash a je ještě jedna další výhoda funkcí >: variabilní rozsah . Jak ukazuje LDP :

#!/bin/bash # ex62.sh: Global and local variables inside a function. func () { local loc_var=23 # Declared as local variable. echo # Uses the "local" builtin. echo "\"loc_var\" in function = $loc_var" global_var=999 # Not declared as local. # Therefore, defaults to global. echo "\"global_var\" in function = $global_var" } func # Now, to see if local variable "loc_var" exists outside the function. echo echo "\"loc_var\" outside function = $loc_var" # $loc_var outside function = # No, $loc_var not visible globally. echo "\"global_var\" outside function = $global_var" # $global_var outside function = 999 # $global_var is visible globally. echo exit 0 # In contrast to C, a Bash variable declared inside a function #+ is local ONLY if declared as such. 

Ve skutečném světě to příliš často nevidím shell skripty, ale pro složitější skripty se to jeví jako dobrý nápad. Snížení soudržnosti pomáhá vyhnout se chybám, při nichž překrýváte proměnnou očekávanou v jiné části kódu .

Opakovaná použitelnost často znamená vytvoření společné knihovny funkcí a source začlenění této knihovny do všech vašich skriptů. To jim nepomůže běžet rychleji, ale pomůže vám to rychleji psát.

Komentáře

• Jen málo lidí explicitně používá local, ale myslím, že většina lidí, kteří píší skripty rozdělené do funkcí, stále dodržují princip designu. Usign local jen ztěžuje zavádění chyb.
• local zpřístupňuje proměnné funkci a jejím dětem, takže ‚ je opravdu hezké mít proměnnou, kterou lze předat dolů z funkce A, ale není k dispozici pro funkci B, která může chtít mít proměnnou se stejným názvem, ale jiným účelem.Takže ‚ je dobré pro definování rozsahu a jak řekl Voo – méně chyb

Rozdělíte kód na funkce ze stejného důvodu, jako byste to udělali pro C / C ++, python, perl, ruby nebo jakýkoli kód programovacího jazyka. Hlubším důvodem je abstrakce – zapouzdřujete úkoly na nižší úrovni do primitiv (funkcí) na vyšší úrovni, takže si nemusíte dělat starosti s tím, jak se věci dělají. Zároveň se kód stává čitelnějším (a udržovatelnějším) a logika programu bude jasnější.

Při pohledu na váš kód mi však připadá docela zvláštní mít funkci deklarovat proměnné; to mě opravdu přiměje zvednout oči.

Komentáře

• Podceňovaná odpověď IMHO. Navrhujete tedy deklarovat proměnné ve main funkci / metodě?

Zcela odlišný důvod, než jaký byl již uveden v jiných odpovědích: z jednoho důvodu se někdy používá tato technika, kde jediným prohlášení o nefunkční definici na nejvyšší úrovni je voláním main, je zajistit, aby skript náhodou nezklamal, pokud je skript zkrácen. Skript může být zkrácen Pokud to je piped from process A to process B (the shell), and process A terminates from whatever reason before it has been finished writing the whole script. To se obzvláště pravděpodobně stane, pokud proces A načte skript ze vzdáleného zdroje. I když to z bezpečnostních důvodů není dobrý nápad, je to něco, co se děje, a některé skripty byly upraveny tak, aby se problém předvídal.

Komentáře

• Zajímavé! Považuji však za znepokojující, že se o tyto věci musí starat každý z programů. Na druhou stranu, přesně tento main() vzor je obvyklý v Pythonu, kde se na konci souboru používá if __name__ == '__main__': main().
• Python idiom má tu výhodu, že umožňuje ostatním skriptům import aktuální skript bez spuštění main. Předpokládám, že podobný strážný by mohl být vložen do bash skriptu.
• @Jake Cobb Ano. Nyní to dělám ve všech nových bash skriptech. Mám skript, který obsahuje základní infrastrukturu funkcí používaných všemi novými skripty. Tento skript lze získat nebo spustit. Pokud je zdroj, jeho hlavní funkce se neprovede. Detekce zdroje vs. spuštění probíhá prostřednictvím skutečnosti, že BASH_SOURCE obsahuje název provádějícího skriptu. Pokud je ‚ stejný jako základní skript, skript se spouští. Jinak je ‚ získáván.
• S touto odpovědí úzce souvisí a používá bash při zpracování ze souboru, který je již na disku, jednoduché řádkové zpracování. Pokud se soubor během běhu skriptu změní, čítač řádků se ‚ nezmění a ‚ bude pokračovat na špatném řádku. Zapouzdření všeho ve funkcích zajistí, že ‚ je vše načteno do paměti před spuštěním čehokoli, takže změna souboru to ‚ neovlivní.

Některé relevantní pravdivosti programování:

• Váš program se změní, i když váš šéf trvá na tom, že tomu tak není.
• Na chování programu má vliv pouze kód a vstup .
• Pojmenování je obtížné.

Komentáře začínají jako mezera pro to, aby nebyly schopen jasně vyjádřit své nápady v kódu * a zhoršovat se (nebo se jednoduše mýlit) se změnami. Proto, je-li to možné, vyjádřete pojmy, struktury, uvažování, sémantiku, tok, zpracování chyb a cokoli jiného, co souvisí s porozuměním kódu jako kódu.

To znamená, Funkce Bash mají problémy, které se ve většině jazyků nenacházejí:

• Stínování jmen je v Bash hrozné. Například zapomenutí použít klíčové slovo local způsobí znečišťování globálního prostoru jmen.
• Použití local foo="$(bar)" má za následek ztrácí výstupní kód bar .
• nejsou žádné pojmenované parametry, takže musíte mít na paměti, co "$@" znamená v různých kontextech.

* Je mi líto, pokud to uráží, ale poté používání komentářů několik let a vývoj bez nich ** po další roky je celkem jasné, co je lepší.

** Používání komentářů pro licencování, dokumentaci API a podobně je stále nutné.

Komentáře

• Nastavil jsem téměř všechny místní proměnné tak, že jsem je na začátku funkce prohlásil za null …local foo="" Poté je nastavíte pomocí provádění příkazu, aby působily na výsledek … foo="$(bar)" || { echo "bar() failed"; return 1; }. Tím se rychle dostáváme z funkce, když nelze nastavit požadovanou hodnotu. Kudrnaté závorky jsou nezbytné, aby bylo zajištěno, že return 1 se spustí pouze při selhání.
• Chtěl jsem jen komentovat vaše odrážky. Pokud používáte ‚ subshell funkce ‚ (funkce oddělené závorkami a nikoli složenými závorkami), 1) nedělejte ‚ Nemusíte používat lokální, ale získáte výhody místní, 2) Nenechte se ‚ setkat s problémem ztráty kódu ukončení nahrazování příkazů v local foo=$(bar) tolik (protože ‚ nepoužíváte místní) 3) Don ‚ si nemusíte dělat starosti o náhodném znečištění nebo změně globálního rozsahu 4) jsou schopni předat ‚ pojmenované parametry ‚ které jsou ‚ místní ‚ do vaší funkce pomocí syntaxe foo=bar baz=buz my-command

Proces vyžaduje sekvenci. Většina úkolů je postupných. Nemá smysl se s objednávkou pohrávat.

Ale velkou věcí na programování – včetně skriptování – je testování. Testování, testování, testování. Jaké testovací skripty aktuálně musíte ověřit správnost svých skriptů?

Váš šéf se vás snaží vést od toho, abyste byli skriptem, až po programátora. Je to dobrý směr, kam se vydat. Lidé, kteří přijdou po vás, vás budou mít rádi.

ALE. Vždy si pamatujte své kořeny orientované na proces. Pokud má smysl mít funkce seřazené v pořadí, ve kterém jsou obvykle prováděny, udělejte to, alespoň jako první průchod.

Později uvidíte, že některé z vašich funkcí jsou manipulace se vstupem, výstupy ostatních, další zpracování, další modelování dat a další manipulace s daty, takže může být chytré seskupit podobné metody, možná je dokonce přesunout do samostatných souborů.

Později můžete uvědomte si, že jste nyní napsali knihovny malých pomocných funkcí, které používáte v mnoha svých skriptech.

Komentáře a mezery se nemohou dostat nikde blízko čitelnosti, jaké funkce mohou, jak ukážu. Bez funkcí byste pro stromy neviděli les – velké problémy se skrývají mezi mnoha řádky podrobností. Jinými slovy, lidé se „nemohou současně soustředit na jemné detaily a na velký obraz. To nemusí být v krátkém skriptu zřejmé; pokud však zůstane krátké, může být dostatečně čitelné. Software se zvětší, ale ne zmenší , a určitě je to součást celého softwarového systému vaší společnosti, který je určitě mnohem větší, pravděpodobně miliony linek.

Zvažte, jestli jsem vám dal takové pokyny:

Place your hands on your desk. Tense your arm muscles. Extend your knee and hip joints. Relax your arms. Move your arms backwards. Move your left leg backwards. Move your right leg backwards. (continue for 10,000 more lines) 

V době, kdy jste prošli polovinou, nebo dokonce 5%, byste zapomněli, jaké byly první kroky. Většinu problémů jste neviděli, protože jste neviděli les pro stromy. Porovnejte s funkcemi:

stand_up(); walk_to(break_room); pour(coffee); walk_to(office); 

To je určitě mnohem srozumitelnější, bez ohledu na to, kolik komentářů můžete v sekvenční verzi po řádku vložit. také daleko zvyšuje pravděpodobnost, že si všimnete, že jste zapomněli připravit kávu a pravděpodobně zapomněl sit_down () na konci. Když vaše mysl myslí na detaily grepových a awk regulárních výrazů, nemůžete „myslet na velký obrázek -„ co když není připravena káva “?

Funkce vám primárně umožňují vidět celkový obraz, a všimněte si, že jste zapomněli připravit kávu (nebo že někdo může upřednostňovat čaj). Jindy se v jiném rozpoložení staráte o podrobnou implementaci.

Existují i další výhody popsané v další odpovědi, samozřejmě. Další výhodou, která není jasně uvedena v ostatních odpovědích, je to, že funkce poskytují záruku, která je důležitá při prevenci a opravě chyb. Pokud zjistíte, že nějaká proměnná $ foo ve správné funkci walk_to () byla špatná, víte, že se musíte podívat pouze na dalších 6 řádků této funkce, abyste našli vše, co by mohl být tímto problémem ovlivněn, a vše, co by mohlo způsobili, že to bylo špatně. Bez (správných) funkcí může být cokoli a všechno v celém systému příčinou nesprávnosti $ foo a $ foo může ovlivnit cokoli a všechno. Proto nemůžete bezpečně opravit $ foo, aniž byste znovu zkoumali každý řádek programu. Pokud je $ foo pro funkci lokální, můžete zaručit, že všechny změny jsou bezpečné a správné kontrolou pouze této funkce.

Komentáře

• Toto není ‚ t bash syntax.Je to ‚ škoda; ‚ si nemyslím, že existuje způsob, jak předat vstup do podobných funkcí. (tj. pour(); < coffee). Vypadá to spíš jako c++ nebo php (myslím).
• @ tjt263 bez závorek, ‚ s bash syntax: nalít kávu. U parenů je to ‚ téměř každý jiný jazyk. 🙂

Čas jsou peníze

Existují další dobré odpovědi , které šíří světlo z technických důvodů k napsání modulárně skriptu, potenciálně dlouhá, vyvinutá v pracovním prostředí, vyvinutá pro skupinu osob nejen pro vlastní potřebu.

Chci zaměřte se na jedno očekávání: v pracovním prostředí „čas jsou peníze“ . Takže absence chyb a výkonnost vašeho kódu jsou hodnoceny společně s čitelností , testovatelností, udržovatelností, refaktorovatelností, opětovné použití …

Psaní v “ modules „ kód zkrátí dobu čtení potřebnou nejen samotným kodérem , ale i časem použitým testery nebo šéf. Navíc si všimněte, že čas nadřízeného je obvykle placen více než čas kodéra a že váš nadřízený vyhodnotí kvalitu vaší práce.

Dále psaní v nezávislé „moduly“ kód (dokonce i bash skript) vám umožní pracovat „paralelně“ s další součást vašeho týmu, zkrácení celkové doby výroby a v nejlepším případě využití odborných znalostí jednotlivce k revizi nebo přepsání části bez vedlejších účinků na ostatní, k recyklaci právě napsaného kódu „tak jak je“ pro jiný program / skript, k vytvoření knihoven (nebo knihoven úryvků), ke snížení celkové velikosti a související pravděpodobnosti chyb, k ladění a důkladnému testování každé jednotlivé části … a samozřejmě se bude organizovat logicky rozdělte svůj program / skript a zvyšte jeho čitelnost. Všechno, co vám ušetří čas a tak peníze. Nevýhodou je, že se musíte držet standardů a komentovat své funkce (že máte noneth co dělat v pracovním prostředí).

Dodržování standardu zpomalí vaši práci na začátku, ale to urychlí práci všech ostatních (a také vašich) poté. Když spolupráce vzroste v počtu zapojených lidí, stane se z toho nevyhnutelná potřeba. Takže například i když věřím, že globální proměnné musí být definovány globálně a ne ve funkci, rozumím standardu, který je inizializuje ve funkci s názvem declare_variables() voláno vždy v prvním řádku main() jednoho …

V neposlední řadě nepodceňujte možnost v moderním zdrojovém kódu editory k zobrazení nebo skrytí výběrových samostatných rutin ( skládání kódu ). Tím se zachová kompaktní kód a uživatel se opět soustředí na úsporu času.

^{Zde výše můžete vidět, jak je rozložena pouze funkce walk_into_bar(). I ty ostatní měly každý 1000 řádků, stále byste mohli mít pod kontrolou celý kód na jedné stránce. Všimněte si, že je přeložen i do sekce, kde přejdete k deklaraci / inicializaci proměnných.}

Další důvod to je často přehlíženo, je syntaktická analýza bash:

set -eu echo "this shouldn"t run" { echo "this shouldn"t run either" 

Tento skript zjevně obsahuje syntaktickou chybu a bash by jej neměl vůbec spustit, že? Špatně.

~ $ bash t1.sh this shouldn"t run t1.sh: line 7: syntax error: unexpected end of file 

Pokud bychom zabalili kód do funkce, nestalo by se to:

set -eu main() { echo "this shouldn"t run" { echo "this shouldn"t run either" } main 

~ $ bash t1.sh t1.sh: line 10: syntax error: unexpected end of file 

Kromě důvodů uvedených v jiných odpovědích:

9. Psychologie: Programátor, jehož produktivita se měří v řádcích kódu, bude mít motivaci psát zbytečně podrobný kód. Čím více řízení tím, že se programátor soustředí na řádky kódu, tím více motivuje program, aby rozšířil svůj kód s nepotřebnou složitostí. To je nežádoucí, protože zvýšená složitost může vést ke zvýšeným nákladům na údržbu a zvýšenému úsilí potřebnému k opravě chyby.
   • WP, zdrojové řádky kódu; Nevýhody, komentáře č. 9

Komentáře

• Není to tak špatná odpověď, jak říkají hlasy proti. Poznámka: AGC říká, že i toto je možnost, a ano, je. Neříká ‚, že by to byla jediná možnost, a ‚ nikoho neobviňuje, pouze uvádí fakta. I když si myslím, že dnes je téměř neslýchaný přímý “ kódový řádek “ – > “ $ / šéfové.