Vlákno názorů k článku Správa DNS zónových souborů v Gitu od lol2 - 1st of all - good job. Ale z...

Mělo by to závislost na konkrétním shellu. Ten se taky nepoužívá všude stejný a už jen příkaz echo se chová diametrálně odlišně v různých shellech. Díval jste se, co všechno se v tom hooku řeší? Má to přes 500 řádků, k tomu je navíc asi 350 řádků testů. Takhle složité skripty v shellu jsou jen těžko udržovatelné.

Google například píše: „If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date.“

> Co som ale videl boli bezne veci - spustanie 3rd patry binariek, praca s ich vystupom, praca s datumom, ... vsetko co sa bezne da spravit v shell scripte.

To zní jako výzva. Já jsem psaní shellové verze hooků vzdal, když jsem chtěl:

1. vyzvednout obsah souboru ze staging ( git show :path/to/file)
2. zjistit jméno zóny analýzou obsahu a názvu souboru
3. obsah souboru předat na vstup named-compilezone
4. standardní výstup zahashovat (libovolnou hashovací funkcí), výstup hashe uložit do proměnné
5. ve standardním chybovém výstupu vyhledat sériové číslo zóny a uložit ho do proměnné
6. uložit standardní chybový výstup do proměnné

Tohle všechno bez dočasných souborů a se striktním oddělením programu a dat. Když o tom tak přemýšlím, ani mě nenapadá, jak se dá v shellu hashovat bez vynucení závislosti na OpenSSL nebo něčem podobném.

> Pritom nainstalovat napr. bash je trochu ine ako nainstalovat python.

V čem konkrétně je to jiné?

Shell se hodí na command line a tam to prakticky končí. Vždycky, když jsem psal něco v shell, tak to skončilo na různém nedokonalém parsování zdrojů, nespolehlivém otvírání souborů, neschopností spolehlivě zachytit chybu (set -e něco řeší, ale pak je třeba opačný handling) atd. Navíc byl například problém s paralelizací. Naprostá většina shell kódu navíc spolehá na neexistenci mezer v hodnotách proměnných, na to, že nezačínají pomlčkou atd.

Po překlopení do Perl (nebo Python či cokoliv jiného podle preferencí) pracuju na úrovni funkcí, které mají jasný výstup, jasné chybové kódy nebo exceptions. Mám k dispozici vysokoúrovňové datové struktury. K tomu mám spolehlivé nástroje na parsování strukturovaných dokumentů jako XML, JSON, kde dostanu celý objekt, takže nemusím duplikovat parsování například. Zároveň je můžu spolehlivě modifikovat. Testování je pak samostatná kapitola.

Dočasné soubory v shellu typicky zvyšují čitelnost a nejsou obecným zlem! Dokud nejsou v dočasných souborech citlivá data, tak jsou nejen rozumným prostředkem pro napsání programu, ale navíc umožňují ladění po krocích libovolnému nově příchozímu uživateli/adminovi. Co ale je v shellu zlo, je detekce a ošetřování chyb a potom ještě udržování většího množství strukturálních dat.

Moje 3 důvody kdy opustit shell podle důležitosti:
1. detekce a ošetřování chyb (každého příkazu, včetně aritmetiky a validace vstupů) začnou být příliš složité
2. zpracování strukturálních dat (použití jazyka který alespoň umožňuje vkládat do sebe hashe a pole zvyšuje čitelnost)
3. příliš velký počet identifikátorů (proměnných nebo dočasný jmen souborů) - v takovém případě potřebuju něco "statičtějšího", v případě pythonu nejprve prohnat "mypy" (aby odhalil překlepy v atributech objektů). Pokud se to nemusí měnit in-place tak třeba go nebo C.

Moje důvod kdy jít do shellu:
1. časté spouštění dalšíh programů, obzvlášť pak v pipelinách.
2. "přenositelnost" mezi uživateli/admi­nistrátory

Hashovat bez závislosti na openssl? Co takhle zkusit spustit externí program? Třeba sha256sum?

Taky tam píší:

If you find you need to use arrays for anything more than assignment of ${PIPESTATUS}, you should use Python.

Což nezní moc rozumě. Spíš to psal někdo, kdo nesnáší shell :-)