Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: tojsemja 01. 02. 2015, 11:31:55
-
Ahoj,
(já jsem ten, kdo tu nedávno založil vlákno pěkného a čistého programování v bashi (http://forum.root.cz/index.php?topic=10515.msg118697#msg118697). Chtěl bych se zeptat na Vaše zkušenosti / dojmy (a pojmy) / postřehy... z programování větších "aplikacích" v Bashi. Bashem si vypomáhám nad jedním projektem. Blížím se počtem řádků k magickému číslu 1000 a říkám si co dál?
- jak lépe členit logiku kódu? mám všechno ve funkcích. máte nějaké zkušenosti s vytvářením nějakých knihoven?
- testujete kód v bashi?
- kdy se vyplatí bash opustit a přepsat to třeba do pythonu?
- máte nějaké pozitivní zkušenosti s tvorbou větších bashových aplikací?
:) díky
-
Kite? :D Na Bash se vykašli, ten je na větší věci k ničemu. Vem Python a pokračuj.
-
https://google-styleguide.googlecode.com/svn/trunk/shell.xml
https://unix.stackexchange.com/questions/74994/is-it-common-to-split-larger-script-into-multiple-scripts-and-source-them-in-the
http://dberkholz.com/2011/04/07/bash-shell-scripting-libraries/
-
Kite? :D Na Bash se vykašli, ten je na větší věci k ničemu. Vem Python a pokračuj.
Co bys rád? Uživatel tojsemja nejsem já. V Bashi sice dělám, ale nemám potřebu v něm dělat větší aplikace.
-
Shell je dobrej pokud si 'neprogramator' potrebuje neco mensiho spichnout a nezaplevelovat si pritom mozek vecmi jako datove typy, objekty a pod. Na tohle jsem nevidel nic lepsiho.
-
Jak psano vyse, psat v bashi aplikaci je jako psat OS v bataku =) Ten python urcite spravna volba.
Nicmene z bashe se toho da vymacka rozhodne hodne.
http://sourceforge.net/p/antix-linux/code/ci/master/tree/screenshot-antix_0.1.5_all/usr/local/bin/antixscreenshot.sh
-
Co bys rád? Uživatel tojsemja nejsem já. V Bashi sice dělám, ale nemám potřebu v něm dělat větší aplikace.
co znamena "nemam potrebu delat vetsi apliace" ? tak jsem ITclovek == jsem lehce linej. neco delam dokolecka, tak si na to pisu dalsi a dalsi funkce, vic a vic veci automatizuju, vic premyslim aby skript "poznal" co chci a vic to automatizoval, coz ma logicky dusledek ze velikost kodu roste. (je tu dalsi vliv, hrozne rad programuju takze se tahle moznost nabizi)
-
je otazka co myslis "aplikaci", ja pisu i vetsi bash scripty (300-900 radku) pokud je duvod rozlozim to do vice souboru ktere "includuju", ale primarne mi vyhovuje 1 soubor a ciste cleneni v definovani funkci... testovani delam tak ze si do funkce pridam detekci stavu/promene/cehokoliv, pripadne si funkci vytahnu docasne samostatne do 1 scriptu, nebo testuju primo v terminalu...
ale ono neni dulezite kolik radku, protoze to same co mas na 1000 muze byt po vycisteni/optimalizaci na 200 :)
napr. v tom tvem minulem vlakne si mel neco na 11 radku a prijal si radu na 8radku, ja ti psal to same na 5radku s tim ze to mohlo byt na 3 pri zachovani citelnosti s tim ze zrovna toto bylo kratke 1 radek mezi if fi :)
-
Bash sa oplati opustit az zacnes mat taketo otazky.. Poloz si otazku, naco je shell? Presne na to iste su shellove skripty, len to chces ma v subore aby sa to dalo spustat viackrat. Teda ak mas nejaku postupnost prikazov ktore ta omrzelo stale vypisovat, tak si urobis skript. Ano, mozno vies urobit v bashi aj blog alebo uctovny system. Ale vzdy si poloz otazku, ci to robis iba preto, ze si chces dokazat ze sa to da, alebo je to skutocne efektivny nastroj na tuto aplikaciu? Napr na blog asi pouzijem php, lebo cele php je o tvorbe html (a blog je jednoducha vec) a na uctovny system javu, lebo (okrem ineho) ma na to vykon a lepsie sa tam robi transakcne spracovanie.
-
co ucetnictvi, ale deathmatch - 0verkill (https://artax.karlin.mff.cuni.cz/~brain/0verkill/index.cgi?mainpage#screenshots) :)
-
bashskrypt je skvely na male tasky v shelli ale ked z toho zacne kvasit zlozitejsia vec a nebodaj modularita treba fakt utekat k pythonu alebo php-cli pokial nemate nejake radikalne softverove obmedzenia
ak nedrzite stabnu kulturu (ktora je dost hardcore) tak citatelnost tiez a udrzovatelnost tiez. portabilita je v kybli lebo na normalne veci beriete bash novych verzii
ten skript by mal len prepajat viacero toolov a dat tomu nejaku nadstavbu ale hard kodovanie ma lepsie toolz
-
co znamena "nemam potrebu delat vetsi apliace" ? tak jsem ITclovek == jsem lehce linej. neco delam dokolecka, tak si na to pisu dalsi a dalsi funkce, vic a vic veci automatizuju, vic premyslim aby skript "poznal" co chci a vic to automatizoval, coz ma logicky dusledek ze velikost kodu roste. (je tu dalsi vliv, hrozne rad programuju takze se tahle moznost nabizi)
Když jsem potřeboval renderovat 3D animaci, kterou jsem potřeboval nějak automatizovaně rozprostřít na více vláken na více strojích na geograficky různých místech, vzal jsem si na to Bash. Vyšlo to na 20 řádek. Je to malá nebo velká aplikace? Asi malá, ale v Bashi obvykle nedělám o moc větší, protože to není potřebné. Vezmu pár souborových utilit a Bash použiji jako lepidlo.
-
- jak lépe členit logiku kódu? mám všechno ve funkcích. máte nějaké zkušenosti s vytvářením nějakých knihoven?
Stačí se inspirovat vhodnými návrhovými vzory, ty platí obecně pro jakékoliv programovací jazyky. Jde jen o to, co se lépe udržuje a o to, jak vám to ovlivňuje chod aplikace.
- testujete kód v bashi?
Ano, testujeme. Snažíme se o jednotkové testování a celkem to jde. Ale u složitějších aplikací se to testování provádí docela špatně - veškerá práce s pokročilejšími funkcemi a kontrolou datových typů padá na unixové nástroje. Tento offloading jen komplikuje správu aplikace, pokud se nejedná o aplikaci vlastní. Musíte pak testovat vše n-krát, protože testujete nejenom aplikaci vlastní, ale i cizí, u které očekáváte nějaký výstup. Funkcionální testování provádíme pomocí nástroje "expect", viz manuálové stránky.
- kdy se vyplatí bash opustit a přepsat to třeba do pythonu?
Nad tím má smysl uvažovat jenom tehdy, pokud přemýšlíte o rychlosti, přesném časování, pokročilých datových strukturách či jiných fičurách. Shell programming je úžasný pro lepení komponent v rámci systému. Složitější aplikaci můžete mít i ve formě malých pomocných aplikací, na které se offloaduje zátěž z hlavního shell skriptu. Vzorem je třeba OpenWrt a parsování JSON stringů v shellu - pomocí jsonpath v jazyce C pracují s JSON daty na úrovni shellu.
A tedy - pokud víte, že nebudete muset validovat neustále výstupy, přesměrovávat jej neustále mezi aplikacemi tam a zpět, pokud nebudete mít velké množství závislostí na externích aplikacích, tak právě doporučuji zůstat u shellu. Ale to samé bych Vám řekl i o jakémkoliv jiném jazyce - minimalizace závislostí na externích knihovnách a vhodný návrh aplikace je vesměs cílem jakéhokoliv projektu napsaném v jakémkoliv jazyce. Závislosti na jiných aplikacích jen zvyšují pravděpodobnost rozbíjení kódu.
Každý skriptovací/programovací jazyk má své pro a proti, přemýšlejte spíše o tom, pro jakou platformu budete programovat a přizpůsobte tomu i volbu svého jazyka. Pro Android také napíšete aplikaci v jazyce C nebo i v shellu, ale budete velmi trpět narozdíl od použití Javy nebo Mono platformy.
- máte nějaké pozitivní zkušenosti s tvorbou větších bashových aplikací?
Ano, mám.
-
Funkcionální testování provádíme pomocí nástroje "expect", viz manuálové stránky.
A jednotkové testy můžete také realizovat pomocí expect. Výborný nástroj. :-)
-
V Bashi skripty používam, a to i velké pro vytváření a zpracování dat. Postupně jsem vytvořil jeden velký skript z více malých. Dostal jsem se na asi 26000 řádků/2,7 MiB.
Před spuštěním se kód netestuje, jde prostě řádek pro řádce a cykly for jsou uzavřeny done. Když někde něco chybí, nebo je naopak navíc (do, done, for, uvozovky), skript spadne až na to místo dojde. V případě neznámého příkazu prostě zahlásí chybu.
Python je zcela jistě propracovanějsí ale v něm zatim neumim. To co potřebuji, aby běželo, tak v bashi funguje. Pro větší programování se nejspíš Pythoon hodí.
Pro výpočet přímo používam Fortran, dřív jsem používal Pascal/Delphi a bylo to o dost pomalejší. Gro grafy Gluplot, skripty pro Gnuplot spouští Bash.
-
všem diskutujícím děkuji, zkusím py a uvidíme :)
-
V Bashi skripty používam, a to i velké pro vytváření a zpracování dat. Postupně jsem vytvořil jeden velký skript z více malých. Dostal jsem se na asi 26000 řádků/2,7 MiB.
Z mého pohledu musí být docela šílenost něco takového udržovat. Když mám některý ze zdrojáků delší než 100 řádek, jsem z toho nesvůj.
-
na grafy a vypocty je python dobrej - konretne tohle rozsireni :
http://nbviewer.ipython.org/github/adrn/ipython/blob/2.x/examples/Notebook/Index.ipynb
umi vyuzit i grafiku a openCL
-
Kit
Naštěstí moc údržby není potřeba (kromě zadání pár proměnných na začítku). Skript je sice obrovský, ale je to sesumírovaných několik skriptů dohromady aby šel spustit jeden skript a dnechalo se to běžet. Jednotlivé části na sobě vůbec nezávisí. Velká část jsou podmínky, seznamy proměných.
Problém může být editace textu - při takové velikosti se může sekat, těžší je označit konkrétní část a pod. Ale fungovat to funguje.
-
Kit
Naštěstí moc údržby není potřeba (kromě zadání pár proměnných na začítku). Skript je sice obrovský, ale je to sesumírovaných několik skriptů dohromady aby šel spustit jeden skript a dnechalo se to běžet. Jednotlivé části na sobě vůbec nezávisí. Velká část jsou podmínky, seznamy proměných.
Pokud na sobě jednotlivé části nezávisí, mohlo by jim být dobře i v samostatných souborech. Je to lepší i pro verzování.
Problém může být editace textu - při takové velikosti se může sekat, těžší je označit konkrétní část a pod. Ale fungovat to funguje.
Běžně edituji soubory s 10M řádky a nějaké sekání nepozoruji.