Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Jacob 07. 03. 2013, 12:12:56
-
Vím že se dá programovat v bashi, ale zajímalo by mě co v něm programují ostatní resp. pro jaké účely?
Já mám třeba pár jednoduchých skriptů, které po instalaci natahají balíčky, akutalizace, atd..
K čemu nejvíc používáte skripty pro BASH?
-
> K čemu nejvíc používáte skripty pro BASH?
Ke skriptovani.
-
> K čemu nejvíc používáte skripty pro BASH?
Ke skriptovani.
Ježiši...
Dobře tak pro jaké úkoly tedy používáte skripty v Bash?
-
Na provádění skriptů ? ::)
-
Treba hromadne prejmenovani souboru... pokrocile hledani v souborech.... to je stejna otazka jako k cemu ve windows pouzivate .bat soubory... :)
-
K cemu, mno ne k tomu co jmenoval tazatel.
priklad: ke vytvoreni zaloh na vzdálených strojích a jejich stahnuti na uloziste.
priklad: presunuti nahranych souboru pres ftp z ipkamery do slozky dle datumu. Spousteno planovacem cron periodicky.
priklad: skript pro kontrolu anomalii v log souborech ulozenych lokalne ze vzdalenych serveru(vynechavajici radky normalniho provozu ci provozu v vnitrni site a vynechavajici tyto zaznamy dle nazvu/typu logu).
priklad: ruzne udelatka pro nejake ukony(generovani certifikatu, jeho podepsani podCA, nemusi se pokazde resit parametry a cesty)
Jinak receno k cemu se da pouzivat skriptovani v BASHi?
Selským rozumem: k automatizaci opakovaných operací.
-
ok ok děkuju
já je používám jak sem už psal pro úkoly jako aktualizace, práce se složkama apod.
čistě ze zvědavosti mě zajímalo pro jaký typ úloh je používají ostatní :)
-
Třeba pro psaní vlastních initscriptů, skriptů pro ramdisk, skriptů pro reakce na udev eventy a podobně. Prostě pro customizaci OS.
Obecně je shell dobrý na prototypování věcí, které se dají jednoduše napsat v příkazové řádce. Pokud potřebuji něco rychle vyzkoušet, pak to napíšu v shellu nebo pythonu a pak, když je třeba optimalizovat, tak to přepíšu do C. Ale většinou to vůbec přepisovat nemusím :)
Asi hlavní výhoda shellu je, že má pajpy a správu jobů atd. a člověk tak může použít hotové standardní utilitky místo psaní vlastní funkčnosti.
Jinak záměrně píšu shell a ne bash, protože z mé zkušenosti je lepší nepoužívat bashismy. (busybox v ramdisku má třeba jen ash)
-
dalsi vec muze bejt spousteni aplikace se slozitymi parametry (a spoustim ji porad s tytymiz
-
V bashi najčastejšie píšem úlohy pre cron - vytvorenie snapshotov a mazanie starých, dump databázy a podobne.
-
dalsi vec muze bejt spousteni aplikace se slozitymi parametry (a spoustim ji porad s tytymiz
U toho vždycky stojí za úvahu, jestli to neudělat jako alias, místo skriptu.
-
systemova a sitova automatizace vseho druhu, data mining, analyzy, parsovani, transformace dat, vsechno mozne..
-
jak je nekde test, skok tak v tom jde programovat :-)
znam lidi co si svoje veci programuji v TeXu, XML.......
-
kompilace dokumentů ( latex, lyx, pdftk )
zpracování textových dat ( awk )
zpracování multimédií ( imagemagick, ffmpeg )
atd ...
-
Ja si v bashi otviram lahvace ...
-
backup skripty, automatizované spouštěče (např. věcí z MESS nebo DOSBOXu), screenshotery s automatickým uploadem, generátory tabulek do Mediawiki, připojovací skripty pro modemy, automatické přejmenovávače, kráječ MP3 na menší kusy...
-
Chápu-li správně dotaz jako "Kdy ještě použít bash?", tak osobně preferuju odpověď "téměř nikdy". Pokud chcete jen automatizovat pár příkazů nebo Vám hodně pomůžou unixové utilitky, jako sed, awk, grep atd. tak ano. Ale pokud to zavání nějakou logikou, tak je lepší použít ruby/python/perl.
-
Já taky nechápu, proč tolik lidí ještě v bashi programuje a proč ho tolik firem požaduje např. pro testování software. Mě přijde syntaxe bashe strašně těžkopádná a nelogická. Pokud tam už má být nějaký cyklus a podmínky, tak daleko lepší mi přijde napsat skript v perlu nebo pythonu a z něj volat systémové příkazy.
-
Já taky nechápu, proč tolik lidí ještě v bashi programuje a proč ho tolik firem požaduje např. pro testování software. Mě přijde syntaxe bashe strašně těžkopádná a nelogická. Pokud tam už má být nějaký cyklus a podmínky, tak daleko lepší mi přijde napsat skript v perlu nebo pythonu a z něj volat systémové příkazy.
Keďže v perl a python takmer nepoznám, zložité veci napíšem najčastejšie v php (napr. cykly a práca s databázou atď) a ešte zložitejšie (napríklad spracovanie xls súborov a výsledky do Mysql) v Jave.
-
BASHu sa vyhybam oblukom lebo:
1) je hovadsky pomaly
2) zdaleka nema tolko funkcii ako ZSH
Pokial potrebujem, aby nejaky script bezal rychlo, napisem ho radsej v DASH/ASH. Pokial ide o narocnejsi script, napisem ho v ZSH. ZSH sice nie je take rychle ako DASH, ale pise sa v nom velmi pohodlne. Pravda, na niektore tasky sa jednoducho hodi viac sed (a sedscript) atd.
Moje scripty zahrnaju vestko mozne:
- rc.d skripty
- "tooly" na procesovanie suborov s urcitym typom dat - ich konverzia atd.
- fetchovanie dat z webu
- automatizacia systemovych taskov
Nemyslim si, ze script, ktory vola 10-krat grep a sed a cat, ma este zmysel oznacovat scriptom nejakeho konkretneho shellu. Takyto script by v pohode mohol bezat pod hocakym shellom, kedze vacsina procesovania sa deje v subprocesoch. Ale chapem, ze bezna analogia je shell script = BASH script.
Pokial je teda otazka "na co pouzivam BASH script", tak poviem "na nic, lebo je pomaly". Pokial je otazka, "na co pouzivam shellscripty", tak poviem "na vsetko, len aby som to nemusel robit manualne".
Samozrejme, ked ide do tuheho (a rychlost nie je podmienka), tak to radsej zbastlim v Pythone, pretoze je dodavany "aj s baterkami" (rozumej modulmi).
-
...
jasne, 1000 a jeden stroj maj instalovany zsh ... aha, on je bash prakticky uplne na vsem, ale jiste je vyhodna strategie napsat script 10x, abych si moh vzdy vybrat prave dostupne nejrychlejsi prostredi ...
Mimochodem, kdyz chci aby bylo neco rychle, prisu to v assambleru.
-
BASHu sa vyhybam oblukom lebo:
1) je hovadsky pomaly
2) zdaleka nema tolko funkcii ako ZSH
Pokial potrebujem, aby nejaky script bezal rychlo, napisem ho radsej v DASH/ASH. Pokial ide o narocnejsi script, napisem ho v ZSH. ZSH sice nie je take rychle ako DASH, ale pise sa v nom velmi pohodlne. Pravda, na niektore tasky sa jednoducho hodi viac sed (a sedscript) atd.
Samozrejme, ked ide do tuheho (a rychlost nie je podmienka), tak to radsej zbastlim v Pythone, pretoze je dodavany "aj s baterkami" (rozumej modulmi).
Protože python je hovadsky rychlý, že? :D
Z mé praxe se vyplatí neupřednostňovat shell žádný. Když napíšu soubor s funkcemi pro shell, tak chci, aby fungoval pokud možno v BASH, ASH, DASH, atd. úplně stejně. Nebudu přece psát knihovnu funkcí pro každý shell znovu. Proto váš příspěvek opravdu nechápu. Všechny interpretované / skriptovací jazyky jsou pomalé. Ale o rychlost u programů pro shell fakt nejde. Spíš o rychlost psaní programu.
-
Můj nejdelší skript v BASHi byl skript firewallu na bráně ve firmě, má 387 řádků a pracuje s několika konfiguračními/datovými soubory.
Neumím si představit, že bych jej měl napsaný v něčem jiném než v BASHi, i když... :-)
-
Hezká ukázka toho jak pitomá otázka může vést k ještě pitomější diskuzi.
-
Nebudu přece psát knihovnu funkcí pro každý shell znovu.
+1; aj ked som bol za to skritizovany s tym, ze bashizmy su citatelnejsie ako sed, ale u mna to neplati..
BASHu sa vyhybam oblukom lebo:
1) je hovadsky pomaly
Viac ide o algoritmy / napad ako o programovaci jazyk.
Jedna pomerne znama firma raz uverejnila pomerne trivialnu ulohu pre zaujemcov o pozicia programatora: mate velke (x*32bit pre rozne x) cisla zapisane v hexa - co riadok, to cislo - treba vypustit poslednych 32bit kazdeho cisla a z takto spracovanych cisel zistit najdlhsie prefixy - potom oznamit ich pocet. (V skutocnosti islo o to, ze ostatne by sa zmazali / oznamili inemu modulu)
Tam bolo zaujimave, ze pomerne jednoducha (nie prilis optimalizovana) implementacia v C pomocou trie (rovnako ako implementacia pomocou RB-stromov) to zvladla na nejakom datasete za 2s a shell script (tusim hlavne sort a awk) to zvladol za 2,5s.
Ano, niekto povie, ze je bash / shell pomaly, ale ked sa zapocita doba pisania tohto programu / skriptu, tak jednoznacne vyhrava. A u shell scriptov ide prave o toto.
Mimochodem, kdyz chci aby bylo neco rychle, prisu to v assambleru.
OT: vazne dokazete pisat rychlejsie programy v ASM ako v C? Ja som sa snazil na roznych architekturach a vsade ma prekonal kompilator z dobre napisaneho* C (vystup kompilatora som dokazal este vylepsit, ale o to mi nejde).
*tj. boli tam klucove slova restrict vsade, kde patrili; okrem toho explicitna vektorizacia a moznosti ako -fomit-frame-pointer -ftree-vectorize atd.
-
Protože python je hovadsky rychlý, že? :D
Toto mala byt snaha o ironiu? Aby vam to fungovalo, musel by som tvrdit, ze Python je rychly, co som nikde neurobil... a zrejme by ste to vedeli aj vy, keby ste si poriadne precitali moj prispevok.
Proto váš příspěvek opravdu nechápu.
To vidim. Skratka mame rozne nazory.
jasne, 1000 a jeden stroj maj instalovany zsh ... aha, on je bash prakticky uplne na vsem
Zaujimave tvrdenie. Pod "je" asi myslite, ze BASH casto byva sucastou zakladnej instalacie systemu. Iste viete, ze aj ine shelly byvaju sucastou zakladnej instalacie systemu. Jednym dychom dodavam, ze netvrdim, ze ZSH je jeden z nich. Ale vdaka bohu, ze inicializacne scripty prakticky v BASHi nie su.
Mimochodem, kdyz chci aby bylo neco rychle, prisu to v assambleru.
Vazne mate vela casu.
Nebudu přece psát knihovnu funkcí pro každý shell znovu.
+1; aj ked som bol za to skritizovany s tym, ze bashizmy su citatelnejsie ako sed, ale u mna to neplati..
+1 pre sed v kniznici funkcii. Ale ak je taka funkcia len wrapper pre sed script, v podstate to nie je shell funkcia (nevyuziva syntax daneho/ziadneho shellu).
-
Protože python je hovadsky rychlý, že? :D
Mezi skriptovacimi jazyky je pomerne rychly. A tipoval bych, ze nekolikrat rychlejsi nez Bash, aspon u vypoctu, ale benchmark jsem nedelal. Mozna pomuze: http://webcache.googleusercontent.com/search?q=cache:KnpvNsrHq9YJ:www.murga-linux.com/puppy/viewtopic.php%3Fmode%3Dattach%26id%3D16212%26sid%3D9ec56d74e859eb32ab750e74981181a7+&cd=3&hl=cs&ct=clnk&gl=cz&client=firefox-a (http://webcache.googleusercontent.com/search?q=cache:KnpvNsrHq9YJ:www.murga-linux.com/puppy/viewtopic.php%3Fmode%3Dattach%26id%3D16212%26sid%3D9ec56d74e859eb32ab750e74981181a7+&cd=3&hl=cs&ct=clnk&gl=cz&client=firefox-a)
Treba Pythoni seznamy a slovniky jsou podle toho vic nez 20x rychlejsi nez Bashove.
-
Protože python je hovadsky rychlý, že? :D
Mezi skriptovacimi jazyky je pomerne rychly. A tipoval bych, ze nekolikrat rychlejsi nez Bash, aspon u vypoctu, ale benchmark jsem nedelal. Mozna pomuze: http://webcache.googleusercontent.com/search?q=cache:KnpvNsrHq9YJ:www.murga-linux.com/puppy/viewtopic.php%3Fmode%3Dattach%26id%3D16212%26sid%3D9ec56d74e859eb32ab750e74981181a7+&cd=3&hl=cs&ct=clnk&gl=cz&client=firefox-a (http://webcache.googleusercontent.com/search?q=cache:KnpvNsrHq9YJ:www.murga-linux.com/puppy/viewtopic.php%3Fmode%3Dattach%26id%3D16212%26sid%3D9ec56d74e859eb32ab750e74981181a7+&cd=3&hl=cs&ct=clnk&gl=cz&client=firefox-a)
Treba Pythoni seznamy a slovniky jsou podle toho vic nez 20x rychlejsi nez Bashove.
No to ano. Pokud srovnáváte python s bashem, tak to opravdu rychlý je. Ale s c/cpp se to nedá porovnat..
-
OT: vazne dokazete pisat rychlejsie programy v ASM ako v C? Ja som sa snazil na roznych architekturach a vsade ma prekonal kompilator z dobre napisaneho* C (vystup kompilatora som dokazal este vylepsit, ale o to mi nejde).
Ručně optimalizovaný assembler dosahuje až 10x vyššího výkonu než nejlepší veledílo v C/C++ a jsou tam k dispozici záležitosti o kterých se 99 % dnešních programátorů ani nesnilo. Přesto se psát v ASM finančně vyplatí jen veeeeelmi zřídka.
Tam bolo zaujimave, ze pomerne jednoducha (nie prilis optimalizovana) implementacia v C pomocou trie (rovnako ako implementacia pomocou RB-stromov) to zvladla na nejakom datasete za 2s
U takové triviální úlohy v C je rychlost menší než rychlost čtení z HDD na pováženou.
Ale o rychlost u programů pro shell fakt nejde. Spíš o rychlost psaní programu.
Přesně tak, o rychlost v shellu vůbec nejde.
-
Bash používám na to, na co bych na Windows použil Powershell
-
Ručně optimalizovaný assembler dosahuje až 10x vyššího výkonu než nejlepší veledílo v C/C++ a jsou tam k dispozici záležitosti o kterých se 99 % dnešních programátorů ani nesnilo.
Bavime sa o rozsirenom x86 / x86-64 a rozumnych prekladacoch? (nejaka obskurna architektura s jedinym a to neschopnym prekladacom moze dosiahnut kludne aj milion krat vyssi vykon pri pisani v optimalizovanom ASM, ale o take architektury nam snad nejde)
O presne ake zalezitosti sa jedna? Preco ich uz nepouzivaju kompilatory, ked to znamena 10 nasobne zrychlenie?
Kde je na to nejaky benchmark napisany rozumne v C a potom v ASM, ktory si mozem spustit a uvidim ten 10x vyssi vykon?
U takové triviální úlohy v C je rychlost menší než rychlost čtení z HDD na pováženou.
To mozno je - otazka je, ci stoji za to to zrychlovat viac - jeden dal tu ulohu tusim za 0.5 sekundy, ale ten uz si spravil svoj alokator pamati vhodny pre tuto ulohu a malloc() volal len raz atd (takze narocnost aj na takuto trivialnu ulohu pomerne velka); zaujimave bolo, ze ludia pouzivajuci viac threadov a aj ti s vyvazovanymi stromami skoncili casovo na urovni ludi, ktori tieto optimalizacie nerobili (nieco trva start threadu, nieco synchronizacia a nejaky readahead u OS asi stihal nacitanie z disku efektivnejsie; data boli z realneho sveta, a ziadne degenerovane pripady tam nenastavali).
-
O presne ake zalezitosti sa jedna? Preco ich uz nepouzivaju kompilatory, ked to znamena 10 nasobne zrychlenie?
O to, že v ASM můžeš plně vytížit jednotlivé exekuční jednotky a také můžeš používat plné výhody SSEx, AVX. Například pouhé přepsání některých algoritmů z C do SSE zvedne výkon 4x, to ale zatím kompilátory moc neumějí a proto se to dělá ručně, například v audio video kodecích, pomocí compiler intrinsics. To už jsme ale daleko od původní debaty.
-
Po bashi siaham, ked potrebujem cokolvek parsovat rychlo, pretoze poskytuje jednoduche pajpy a mozem vyuzivat kopec commandov v Linuxe a tiez mozem spustat nove procesy.
-
O to, že v ASM můžeš plně vytížit jednotlivé exekuční jednotky
To imho zvladne lepsie kompilator ako clovek. Vazne - kto dokaze pri pisani ASM uvazovat nad exekucnymi jednotkami, prekladanim kodu, vhodnym vyuzitim registrov, roznymi rychlostami instrukcii atd? A to nehovorim o takom prekladani instrukcii, ze si kompilator "uvedomi", ze je nejaka cast procesoru obsadena a preto pouzije pomalsiu instrukciu, ktora sa ale vykonava inde a tak to bude celkovo rychlejsie.
Na pisanie takehoto kodu podla mna mozog cloveka (ako som ja) nie je dost dobre stavany a na citanie takto napisaneho kodu uz vobec nie.
a také můžeš používat plné výhody SSEx, AVX. Například pouhé přepsání některých algoritmů z C do SSE zvedne výkon 4x, to ale zatím kompilátory moc neumějí a proto se to dělá ručně, například v audio video kodecích, pomocí compiler intrinsics.
Ja si myslim, ze "nejlepsi veledilo v C" by malo SSE pouzivat vsade, kde je to treba. Intrinsics nepovazujem za nieco mimo C - ostatne, je to z pohladu programatora skoro uplne "normalna funkcia", aj ked nie standardizovana a nepreklada sa ako volanie funkcie.
Jednoduchu vektorizaciu zvladalo aj obycajne GCC uz pred mozno 3 rokmi, ked som si nahodou cital instrukcie jedneho mojho programu a hladal som miesta, kde by to islo vylepsit. Tam, kde to nezvladne GCC same prichadzaju zase intrin...
To už jsme ale daleko od původní debaty.
Jasne - akurat ma zaujimalo, ci je to s C az tak zle - a nastastie to tak nevyzera.
-
Jasne - akurat ma zaujimalo, ci je to s C az tak zle - a nastastie to tak nevyzera.
Je to zlé odjakživa, například všechny obvyklé kompilátory mají memcpy ručně optimalizovaný ASM, včetně MSVC i GCC. Dál to nebudu rozvádět i když by nám to vydrželo na dlouhé hodiny, to není smysl této diskuze.
-
Pánové. Nebyl dotaz náhodou o využití bashe?
PS.: Prosím na tento příspěvek nerozjíždět další flame...
-
PS.: Prosím na tento příspěvek nerozjíždět další flame...
A pokud na flejmování používám skripty v bashi, tak flejmovat můžu?
-
PS.: Prosím na tento příspěvek nerozjíždět další flame...
A pokud na flejmování používám skripty v bashi, tak flejmovat můžu?
Když sem dáte výpis těch skriptů, tak ano.
-
Tady je flame a nikdo mě nepozval ::)
To je bordel!
-
Když sem dáte výpis těch skriptů, tak ano.
if [ "$name" = "student"]; then
echo "99,9% absolventů nikdy nevyužije znalost důkazů vlastností Turingova stroje. Zato 99,9% absolventů by využilo základní znalost pracovního práva."
else
echo "Unity je jediné desktopové prostředí s promakaným UX"
fi
-
Dobře Ty ;D
Právě jsi vymyslel BASHFLAME ;D
-
Salát....nerdi flejmujou v brainfucku!
-
Já myslím, že u mnoha studentů by to skriptování vypadalo asi takto:
C:\Documents and settings\bighacker>explorer http://www.redtube.org/
;D
-
You need the latest Flash player to see this video. :(
-
Offtopic... (ontopic?)... Jsem 14 dní v novém zaměstnání a objevil jsem tady úžasnou věc - testovací framework v bashi. Desítky tisíc řádek kódu bashe a upřímně jsem udivenej, jak hezky je to napsaný a dobře to funguje. A to jak na Linuxu, tak na OS X (primární target), tak i na Cygwinu.
-
Desítky tisíc řádek kódu bashe
Dobře sis vybral zaměstnavatele :) Takový který má na to psát a udržovat desítky tisíc řádek kódu bashe se musí brodit v penězích.
Bash je skvělá věc, ale na tak velké věci fakt ne. Testy se dělají obvykle ve stejném jazyce ve kterém se píše projekt nebo v C#/Javě a tak.
-
Desítky tisíc řádek v BASHI? ::)
A já si pořád říkal, v čem je VISTA vlastně napsaná ;D
PS: Příště doporučuji si neplést BASH a Python/Perl ;D
-
PS: Příště doporučuji si neplést BASH a Python/Perl ;D
Věřil bych, že to byl bash, kdyby nechtěli použít bash, tak spíš než po perlu, nedejbože pythonu, sáhnou např. po LISPu.
-
Bash je skvělá věc, ale na tak velké věci fakt ne. Testy se dělají obvykle ve stejném jazyce ve kterém se píše projekt nebo v C#/Javě a tak.
Projekt je C++. Ten Bash je hlavně od toho, aby připravoval prostředí, pouštěl binárky, sbíral návratový hodnoty, logy, stdout a stderr a tak dále a tak podobně. Mně osobně to přijde docela fajn. Jak řikám, základ je, že je to dobře napsaný.
Jinak AFAICT byly pro Bash dva důvody: 1) kolega, kterej to převážně psal, miluje Bash :-) . 2) máme ho defaultně nainstalovanej na všech strojích vč. Windows - Python, Perl i cokoliv jinýho bychom museli instalovat. (Teď se hrabu v nějakejch perlovejch projektech a po pravdě teda zlatej Bash...)
-
Jak řikám, základ je, že je to dobře napsaný.
Člověk někdy žasne nad tím, jak bezva věci se dají uělat s různými nástroji, když jim někdo rozumí a pracuje čistě. Třeba porty ve FreeBSD jsou postavené nad "obyčejným" make (BSD verzi make) a šlapou docela hezky :)
-
Projekt je C++. Ten Bash je hlavně od toho, aby připravoval prostředí, pouštěl binárky, sbíral návratový hodnoty, logy, stdout a stderr a tak dále a tak podobně. Mně osobně to přijde docela fajn. Jak řikám, základ je, že je to dobře napsaný.
Na tohle se Bash hodí, ale to nevysvětluje proč jsou toho desetitisíce řádků. Netvrdím že Bash je k ničemu, jenom že to muselo trvat strašnou spoustu času a čas jsou peníze. Normálně by se testovalo tak, že by se přímo v C++ napsaly testy na jednotlivé funkce a třídy.
-
Ty desetitisíce řádků jsou opravdu zajímavé ;D
-
K čemu nejvíc používáte skripty pro BASH?
Pro jednorazovky (jakykoli hromadny manipulace se soubory), nekdy si ukladam onelinery, ktery pouzivam casto, abych si usetril psani, pripadne obcas pouzivany skriptiky, napr. neco jako http://pastebin.com/dCGwn4YN (http://pastebin.com/dCGwn4YN) (zabiti programu pokud si vezme moc pameti) - typicky use-case u me.
Proste cokoli, kde cloveka netrapi rychlost, nema to velky rozsah a kde se z vyhodou vyuzije vlastnosti sh/bash :)
-
Bash nemá smysl používat, python je ve všem lepší.
http://stackoverflow.com/questions/2424921/python-vs-bash-in-which-kind-of-tasks-each-one-outruns-the-other-performance-w
Kevin Little to tam vystihl naprosto přesně:
Generally, bash works better than python only in those environments where python is not available. :)
-
Bash nemá smysl používat, python je ve všem lepší.
Python neznám, jak by se tam udělalo bashovské cmd1 | cmd2 > file.txt?
-
Python neznám, jak by se tam udělalo bashovské cmd1 | cmd2 > file.txt?
Pokud bash provozuješ jen jako launcher externích programů tak ano, je kolem toho méně omáčky než v jiných programovacích jazycích. Situace se ale velice rychle začne lámat ve chvíli, kdy budeš v bashi chtít opravdu programovat, to znamená používat větvení, cykly a funkce (o objektech nepíšu, to bash neumí). Z vlastní zkušenosti můžu říct, že je rychlejsí naučit se python než psát nebo udržovat cokoliv netriviálního (>= 100 řádků) v bashi.
-
Bash nemá smysl používat, python je ve všem lepší.
Aha, tak to asi bude okrajový význam slov "ve všem lepší", který mi zatím unikl ;)
-
Aha, tak to asi bude okrajový význam slov "ve všem lepší", který mi zatím unikl ;)
subprocess.call("cmd1 | cmd2 > file.txt", shell=True)
V čem je to horší než bash?
-
subprocess.call("cmd1 | cmd2 > file.txt", shell=True)
V čem je to horší než bash?
Takže pustím python, abych z něj pouštěl shell?
Mimochodem, v bashi zase mohu udělat toto:
python << EOF
// cokoliv v pythonu
EOF
-
To že najdeš jednu konstrukci, která se dá napsat v bashi na méně řádků než v pythonu, nic nevypovídá o tom, který jazyk je vhodnější na programování. Původní dotaz byl K čemu programování v BASH? a já říkám k ničemu, python je ve všem lepší.
-
To že najdeš jednu konstrukci, která se dá napsat v bashi na méně řádků než v pythonu, nic nevypovídá o tom, který jazyk je vhodnější na programování. Původní dotaz byl K čemu programování v BASH? a já říkám k ničemu, python je ve všem lepší.
;D ;D
To je pořád dokola, Losnu nebo Mažňáka?
Ono odpovědět na tak hloupě (eufemismus) zadanou otázku snad asi ani nejde.
Asi by bylo třeba přesněji specifikovat "na co konkrétně".
...
Kevin Little to tam vystihl naprosto přesně:
Generally, bash works better than python only in those environments where python is not available. :)
Ano.
Ale je třeba si všimnout toho "detailu": in those environments where python is not available
A někde prostě ten python není, tečka.
-
Já měl tu čest udržovat bash skript, který měl asi 500 řádků a který napsal někdo jiný. I když je to malý kus kódu, tak takovou zkušenost nikomu nepřeju. Nakonec jsem to přepsat do pythonu. Přepisem jsem ztratil míň času než udržováním, je to poloviční a už se do toho i dají přidávat nové funkce, aniž by to nějakou stávající rozbilo. Pokud máte dost času a chcete si hrát s bashem vaše věc, ale na programování to není, bash je co se týká syntaxe a funkcionality tak 30 let zpátky za normálními jazyky.
Kde python není, tak tam se opravdu použít nedá (jak překvapivé), ale i tak bych se snažil použít něco jiného než bash.
-
To že najdeš jednu konstrukci, která se dá napsat v bashi na méně řádků než v pythonu, nic nevypovídá o tom, který jazyk je vhodnější na programování. Původní dotaz byl K čemu programování v BASH? a já říkám k ničemu, python je ve všem lepší.
Snažil jsem se naznačit, že pokud je třeba kombinovat různé externí programy, pak je asi vhodnější ten bash. A ano, i to bych označil za programování.
-
Pokud máte dost času a chcete si hrát s bashem vaše věc, ale na programování to není, bash je co se týká syntaxe a funkcionality tak 30 let zpátky za normálními jazyky.
Kde python není, tak tam se opravdu použít nedá (jak překvapivé), ale i tak bych se snažil použít něco jiného než bash.
Každý jazyk se hodí na něco jiného. Když jsem potřeboval paralelně spouštět 4 procesy, které se střídavě ukončovaly a měly být spouštěny s dalšími parametry z fronty, tak mi Bash vyšel jako nejlepší řešení s poměrně krátkým skriptem. Pracovat však s jeho polem je utrpení a zpracovávat vstupní data v cyklu je děs. Proto se držím pravidla, že pro každý problém nejprve vyberu vhodný jazyk nebo jejich kombinaci tak, aby každý dělal jen takovou část činnosti, kterou umí nejlépe.