Dotaz: Preco povazujete bash za plnhodnotny jazyk?

[lofcek]

Nechcem tu byt za blba, ale bash (a podobne aj ostatne shelly) povazujem za zastarale, tazkopadne, neflexibilne, pomale a nachylne na utoky. A preto ma fascinuje, preco sa niekto na fore vypytuje ako to ci ono urobit v bashi.

Poznate aj nejake vyhody bashu oproti "normalnym" skriptovacim jazykom ako je dajme tomu python, perl, alebo ruby. Lebo jedine co ma napada je jednoduchsie praca so subormi a ovela tazkopadnejsia so vsetkym ostatnym.

---

---

Odpovědi

[Petr Šobáň]

Třeba proto že bash je na 90% distribucí v základu ?

Já většinou co nemůžu napsat v bashu tak napíši v C

[pavlix]

To je mimochodem Python a Perl taky.

[l4m4]

To je mimochodem určitě i interpret PostScriptu...

[pavlix]

Ne že bych ho chtěl používat k něčemu jinému než tisku, i když jsou systémy, které působnost postscriptu značně rozšířily.

[Eda Lodyhatec]

Asi tak:

http://www.pugo.org/main/project_pshttpd/

[falešný amig4poשer]

Bash rozhodně není plnohodnotný jazyk, protože jím žádnou normální ženskou nesvedeš. Ani normálního chlapa .

[Jary]

Co je smyslem této otázky? Co se chceš dovědět?

[sss]

Myslim, ze jen malokdo povazuje shelly za plnohodnotny jazyk. Presto lze jen tezko souhlasit s tim ze by byly "zastarale, tazkopadne, neflexibilne, pomale a nachylne na utoky". Naopak, ulohu toho, nac byly urceny plni mimoradne dobre a pres velke snahy lidi, je nahradit, jak pri interakci s uzivatelem, tak pri startu systemu, prave protoze jsou "velmi sikovne do ruky, flexibilni, rychle, nenarocne a odolne proti utokum", si svou pozici drzi velmi pevne.

Ja naopak povazuju tzv. normalni scriptovaci jazyky, jako napriklad perl, python nebo ruby za "zastarale, tazkopadne, neflexibilne, pomale a nachylne na utoky".

Dovolte mi par osobnich zkusenosti. V polovine '90 jsem zacal sve scripty v bash a awku prepisovat do perlu, protoze "perl je to nejlepsi co mohlo unix potkat" (E.Raymond?). Nakonec jsem dosel k tomu, ze pokud uz je to neco vetsiho je lepsi si to udelat v C/C++ a obalit to v shellu. Krome toho, ze je to rychlejsi a flexibilnejsi je to mnohonasobne jednoduzsi na udrzbu a radu veci pouzivam dodnes. (Slozitou syntaxy perlu jsem si nikdy moc dopodrobna nebyl schopen zapamatovat. Tehdy jsem pochopil, ze jediny podstatnejsi rozdil mezi perlem a C++ je, ze se nemusi prekladat.)

Nekdy po roce 2000, jsem skocil na vlny pythonu, protoze "to je ten jazyk budoucnosti: jednoduchy, plny modulu, ...". Napsal jsem v tom asi za 2 mesice docela sikovnou grafickou aplikaci (wxWidgets + python). Rozhodne kod nebyl nijak prehledny, jak slibovala reklama a uz vubec to nebylo rychle (start byl zoufale pomaly, prekreslovani viditelne pomalejsi nez ostatni aplikace). Vydrzelo to mesic, pak jsem to prepsal s pomerne malou namahou, velmi podobnou strukturou a kodem do C++ a behalo by to dodnes, kdybychom to potrebovali. (To byla doba, kdy jsem pochopil, ze emulace (virtualni stroj) ma efekt jen ve zpomaleni vykonu, prenositelnost mezi systemy je ve skutecnosti taky dost omezena. Rychlost psani kodu v C++ je srovnatelna s Pythonem.)

Nekdy kolem 2005, jsem psal rozsahlejsi system na davkove zpracovani dat, obrazku, databaze.. tedy jsem to napsal v pythonu, trvalo me to tak pul roku a bylo to mnoho a mnoho radku kodu. Zrovna ted pisu funkcne podobny soft, ty tri docela kratke shellove scripty do systemu snad ani nestoji za rec z hlediska programovani a funkcionalita je zakodovana v Fortranu a C++. Pricemz ten funkcionalni system udrzuju uz vic 15 let. (Kombinace dobre multiplatformni knihovny s C++ je asi to nejfunkcnejsi a neprenostitelnejsi co se da realne pouzivat. Fortran je prenositelny i bez knihoven a navic se v nem pise flexibilni, rychly a bezpecny kod aspon 3x rychleji nez v C++.

Mozna by jsi mohl objasnit, proc si myslis, ze shell "povazujes za zastaraly, tazkopadny, neflexibilny, pomaly a nachylny na utoky.". Jestli k tomu mas nejake skutecne duvody nebo je to jen nejaky iracionalni nazor.

[Kit]

Pokud v Perlu a Pythonu programuješ stejným způsobem jako v C++ a Fortranu, tak se ani nedivím, že vidíš jen jejich nevýhody.

Jenže v shellu programuješ jinak. Výkonné činnosti přenecháváš AWK či Fortranu. Shellu ponecháváš jen to, k čemu byl původně vytvořen.

[pavlix]

I v Pythonu přenecháváš náročné výpočty modulům napsaným v C, jinak je výsledek pomalý.

[Kit]

Možná někdo podlehl iluzi, že interpretované jazyky jsou stejně rychlé jako kompilované. To platí jen v případě, že interpretr má vhodné knihovny (zpravidla napsané v C či Fortranu) a programátor ve skriptovacím jazyku dokáže využívat sílu těchto knihoven a případně si nějakou knihovnu v nižším jazyku dopsat.

Tohle bylo splněno právě při kombinaci shellu a Fortranu nebo shellu a AWK, ale při pokusu o přepsání do Pythonu to bylo porušeno.

[pavlix]

Tohle bylo splněno právě při kombinaci shellu a Fortranu nebo shellu a AWK, ale při pokusu o přepsání do Pythonu to bylo porušeno.

To se mohlo stát.

Porovnání rychlosti AWK a Pythonu jsem nikdy neřešil, ačkoli jsem používal obojí. Rozdíly v rychlosti se mi při rozumném použití neprojevily. AWK je oproti Pythonu značně omezený, tak to porovnání ani nemá moc smysl. Nechal jsem si ho jenom na příkazovou řádku a do jednoduchých shell skriptů.

[Kit]

Pokud by se Python používal stejným způsobem jako AWK, určitě by byl rychlejší. Výhodou AWK je, že programátora tlačí do formulace takového skriptu, který zvládá rychle. Odměnou je, že se vstup nemusí složitě parsovat.

V AWK se však dají napsat i klasické a pomalé aplikace.

AWK má pro mne jednu vadu na kráse: Nezvládá CSV, což považuji za vážný nedostatek.

[David Watzke]

Jak nezvládá CSV? Mělo by stačit nastavit správnej oddělovač slov, ne?

[Kit]

Tak se ukaž:

23,12,"Vlasta",500
24,12,"Adam, Eva",600

Vypiš jména a číslo na konci pomocí AWK.

[Šangala]

CSV je divné :), může mít oddělovač ve slově:

Franta,"Kubrt, Úďa a Markétka",Pepa

a taky zdvojenné uvozovky:

Franta,"Kubrt, ""Úďa"" a Markétka",Pepa

transponované do řádků:

Franta
Kubrt, "Úďa" a Markétka
Pepa

[Kit]

Ten poslední zápis je také platný pro jeden záznam nebo jsou to tři záznamy? Jak se v tomto případě oddělují záznamy?

[Šangala]

Jsem to blbě napsal.
Myslel jsem tím, že CSV:

Franta,"Kubrt, ""Úďa"" a Markétka",Pepa

jsou následující tři položky sloupce otočené do řádků:

Franta
Kubrt, "Úďa" a Markétka
Pepa

čistě jen pro rozlišení co je „jedna položka záznamu.

Ale u toho jsem si vzpoměl na další zádrhel CSV:

Franta,"Kubrt, ""Úďa""
 a Markétka",Pepa

Je opět totéž, jen druhý sloupec má v hodnotě '\n'.
Navíc CSV nemá normu ale jen RFC, kde se říká, že jen pokud je CRLF v záznamu musí být uzavřen mezi "" (samozřejmě taky když obsahuje oddělovač nebo ").
Takže pokud záznam obsahuje CR nebo LF, tak NEMUSǏ být uzavřen v "", proto soubor musí být zpracováván „ručně“ sekvenčně a až první nalezená kombinace CRLF, která není mezi "" je konec záznamu (řádku).
Toš bacha při čtení CSV, není problém jej zapsat, ale čtení má své záludnosti.

[Kit]

To není velký zádrhel. V PHP mi normálně funguje i CSV, které má CRLF mezi uvozovkami. Samotné CR bez uvozovek také zvládne, ale LF považuje za konec záznamu stejně jako CRLF.

Nevím ale, jak jsou na tom knihovny jiných interpretrů.

[Šangala]

ale LF považuje za konec záznamu stejně jako CRLF - no a už to není čisté :(…
Už je to dávno, co jsem to řešil v PHP, a nakonec si to udělal v PHP sám, protože jsem s tím měl potíže (ale už nevím jakého druhu, jestli to bylo něco jako 'auto_detect_line_endings', ale mám pocit, že to nějak idiotsky escapovalo znaky…).

[Kit]

Není to čisté, ale je to praktické

Existuje snad nějaký program či knihovna, která má implementováno CSV "čistě"? Pokud ano, asi bych ji nepoužil, protože mé soubory "CSV" mají na konci řádek jen LF a tím nesplňují RFC.

[Šangala]

Potom to tedy nejsou CSV soubory podle RFC, a kdoví jestli takový export pak v různých programech při importu neselže. :(
Při exportu/importu CSV pokud to má být „různé-os-a-aplikace-přátelské“ je vhodné umožnit alespoň definice, separator, znaková sada, desetinný oddělovač, konec řádku, první řádek je/není záhlaví, případně i „textový oddělovač“.

[pavlix]

Potom to tedy nejsou CSV soubory podle RFC, a kdoví jestli takový export pak v různých programech při importu neselže. :(

Zatím jsem vždy viděl selhávat především import správných RFC.

[Šangala]

Konkrétně?, bo ono to s tím koncem řádku na Linuxu je obvykle putna, ale na Win už je to horší pokud to není CRLF.

[pavlix]

Výhodou AWK je, že programátora tlačí do formulace takového skriptu, který zvládá rychle. Odměnou je, že se vstup nemusí složitě parsovat.

A podmínkou je, že je to úloha vhodná pro AWK.

[Kit]

To je další výhoda AWK: Pokud pro něj úloha není vhodná, programátor ji obvykle raději udělá v něčem jiném, než aby se s tím mořil za každou cenu. AWK je filtr.

[pavlix]

Preco povazujete bash za plnhodnotny jazyk?

Protože je? Pokud se plnohodnotností myslí, že v něm jde programovat to, co v ostatních jazycích (vynechám teorii, která za tím je).

Nechcem tu byt za blba, ale bash (a podobne aj ostatne shelly)

Neznalost a hloupost jsou naštěstí dvě různé věci. Ačkoli způsob položení otázky by mohl jisté pochybnosti vyvolat.

povazujem za zastarale

Za zastaralé považuju věci, které jsou plně nahrazené něčím lepším. To v případě shellů není pravda.

tazkopadne

Na úlohy, na které se shell tradičně používá, jsou těžkopádné právě ty ostatní jazyky.

neflexibilne

Pouze pokud s ním řešíš něco, na co není vhodný.

pomale

Věci, které se typicky v shellu řeší, jsou na napsání podstatně rychlejší než v čemkoli jiném a na běh jsou podstatně rychlejší než je potřeba.

nachylne na utoky.

Při typickém použití shell běží pod UID uživatele, který mu zadává vstup. Nepředstavuje tak žádné bezpečnostní riziko.

Poznate aj nejake vyhody bashu oproti "normalnym" skriptovacim jazykom ako je dajme tomu python, perl, alebo ruby.

Práce s ním je typicky jednodušší a rychlejší, pokud chceš spravovat systém a ne vytvářet programy.

Lebo jedine co ma napada je jednoduchsie praca so subormi a ovela tazkopadnejsia so vsetkym ostatnym.

Vzhledem k tomu, že na unixovém systému je naprostá většina věcí dostupná přes soubory, tak je to dost podstatná výhoda. Navíc je v shellu mnohem jednodušší pustit příkaz s nějakými argumenty, přesměrovat jeho výstup, vytáhout zněj to důležité, apod.

Seber administrátorovi shell, dej mu místo něj Python a polož mu na stůl knihu o Pythonu a uvidíš :D.

[nikdo]

Při typickém použití shell běží pod UID uživatele, který mu zadává vstup. Nepředstavuje tak žádné bezpečnostní riziko.

To bych rozhodně netvrdil. Nakoukněte např. do /usr/sbin, /sbin, /etc/init.d ...

Seber administrátorovi shell, dej mu místo něj Python a polož mu na stůl knihu o Pythonu

No co, žádný problém...

1. Přečtu knihu o Pythonu
2. Napíšu si v Pythonu bash
3. Python zapomenu

:)

[pavlix]

To bych rozhodně netvrdil.

Já bych to teda rozhodně tvrdil.

Nakoukněte např. do /usr/sbin, /sbin, /etc/init.d ...

Tam už to znám :).

No co, žádný problém...

Abys začal :).

[l4m4]

Shell je turingovsky kompletní a ke svému účelu, tedy coby příkazové rozhraní operačníco systému, je vyhovující.

Poznate aj nejake vyhody bashu oproti "normalnym" skriptovacim jazykom ako je dajme tomu python, perl, alebo ruby. Lebo jedine co ma napada je jednoduchsie praca so subormi a ovela tazkopadnejsia so vsetkym ostatnym.

Nastav si irb (např.) jako login shell a uvidíš sám, jaké má bash výhody.

[|🇵🇸]

bash je turingovsky úplný, ergo je plnohodnotný. A je po ptákách.

Jeho specifika a syntaxe se nelíbí ani mně, ale zkus si používat třeba Scsh... narazíš na jiné problémy.

[Jakub]

Tak Bash je určen právě pro práci se soubory a pro tento účel je taky navrhnuta rychlost a jednoduchost programování, vše ostatní jako jsou proměnné, pole a jiné sračky jsou tam jen pro nějaký přechod, k ničemu jinému. Tak že pokud chceš používat práci se soubory, používej Bash, chceš li pracovat s proměnnýma nebo array použij plnohodnotný jazyk, nic vím nic míň. Rozhodně bych Bash neodsuzoval, neznám žádný jiný jazyk, ve kterém můžeš tak jednoduše se soubory pracovat...

[l4m4]

Shell je plnohodnotný jazyk. Stejně jako TeX, PostScript, nebo m4. Jen je to jazyk, jehož příkazy jsou programy v daném operačním systému (a případně další věci, protože shell musí mít nějaké built-in příkazy, jako např. cd), což určuje, k čemu se hodí, a k čemu ne.

A nehodí se jen na práci se soubory (na to by asi python shutil stačil). Díky snadnosti, s jakou se vytvářejí přesměrování a pod., se hodí právě ke spojování různých programů, převážně ad hoc a quick'n'dirty stylem, byť jisté korektnosti dosáhnout lze.