Zpětná kompatibilita BASH skriptů

[Kit]

Python3 je přece jen trochu jiný jazyk.

s takovým přístupem větší projekt nezmigruješ. Musí přechodně fungovat jak v Pythonu 2, tak v Pythonu 3.

Je spousta aplikací napsaných v Pythonu2, které nikdo migrovat nebude.

Bavíme se o shellových skriptech, u kterých se Python použije jen jako jeho rozšíření. O větších projektech nebyla řeč.

[Reklama]

[Lol Phirae]

Za me rozhodne nedodrzovat. BASH 4 prinesl spoustu uzitecnych novinek a uz nekolik let je vsech hlavnich distribucich.  Sezente si nejakou aktualni knihu nebo nejaky novejsi web tutorial a zacnete programovat, na nejakou zpetnou kompatibilitu se muzete vyprdnout. Pochybuji, ze jeste nejaka linuxova distribuce, ktera ma support (aktualizace), pouziva BASH v3. Napisu par skriptu prakticky kazdy tyden a bez [[ =~ ]], variable expansions a associativniho pole bych to uz delat nechtel.

No, asi tak nějak... Pamatuji před cca 10+ (?) lety hromadnou onanii, jak předěláme všechno, co závisí na BASHi, do POSIX-kompatidebilního shellu (v Debianu hrůza jménem dash). Těch tisíců promrhaných hodin totálním nesmyslem. 

[k3dAR]

Zdravím.

Učím se trochu programovat v BASH a narazil jsem na otázku, zda dodržovat při programování zpětnou kompatibilitu s dřívějšími verzemi BASH. Ptám se tedy, v jakých případech by se měla zpětná kompatibilita dodržovat a v případě, že jo, tak jak hluboko do historie verzí BASH.

v klidu ignoruj at pouzijes neco jineho abys mel mene problemu (napr. python kterej jak uz bylo receno s prechodem z python2 na python3 je problem)...

pokud planujes pouzivat scripty i jinde nez na GNU/Linuxu ma vyznam se snazit vyhnout tomu co BASH nabizi, tedy psat jen pro #!/bin/sh to ze to ve vysledku vola bash nebo dash je irelevantni, protoze pokud je to volane pres link sh, tak se pouzivaji jen ciste sh moznososti...

na druhou stranu, pokud pocitas s pouzitim vyhradne na GNU/Linuxu vubec bych se nebal pouzivat BASH pokud se to bude hodit, nebo klidne vzdy pokud nebudes delat zpracovani hromady dat kde sh muze byt rychlejsi... v malem meritku to nepoznas...

za me treba z BASH vyuzivam nahrady znaku v promenych, napr:

Kód: [Vybrat]

neco="aaa bbb 111"
echo ${neco/bbb}
aaa 111
v sh by se muselo resit napr pres sed

Kód: [Vybrat]

neco="aaa bbb 111"
echo ${neco} | sed 's/bbb //'
aaa 111

vice o vsech dalsich moznostech nahrady v promene: https://www.tldp.org/LDP/abs/html/parameter-substitution.html
z "Advanced Bash-Scripting Guide": http://www.tldp.org/LDP/abs/html/index.html
coz je soucast vyborneho "The Linux Documentation Project": http://www.tldp.org/index.html

[Kit]

za me treba z BASH vyuzivam nahrady znaku v promenych, napr:

Kód: [Vybrat]

neco="aaa bbb 111"
echo ${neco/bbb}
aaa 111


Tohle je zrovna dobrá ukázka použití Bashe. Bohužel se však stále setkávám s používáním polí, které dokáží skript pěkně zašmodrchat. Přitom Bash nabízí mnohem lepší možnosti.

[Jenda]

Python3 je přece jen trochu jiný jazyk.

Tak na to se dá logicky odpovědět, že Bash 4 je také jen trochu jiný jazyk.

Součástí OS bývá Python2 a Perl5.

Ano, a jak dlouho?

[Reklama]

[Kit]

Python3 je přece jen trochu jiný jazyk.

Tak na to se dá logicky odpovědět, že Bash 4 je také jen trochu jiný jazyk.

Pokud vím, tak je Bash4 zpětně kompatibilní, což se o Pythonu3 tvrdit nedá.

Proti Bash4 nic nemám, vadí mi jen zneužívání polí.

[fe]

Za me rozhodne nedodrzovat. BASH 4 prinesl spoustu uzitecnych novinek a uz nekolik let je vsech hlavnich distribucich.  Sezente si nejakou aktualni knihu nebo nejaky novejsi web tutorial a zacnete programovat, na nejakou zpetnou kompatibilitu se muzete vyprdnout. Pochybuji, ze jeste nejaka linuxova distribuce, ktera ma support (aktualizace), pouziva BASH v3. Napisu par skriptu prakticky kazdy tyden a bez [[ =~ ]], variable expansions a associativniho pole bych to uz delat nechtel.

Michal

BASH v3 používá:
1) SLES 11 -> EOL duben 2022
2) macOS -> z důvodu licence tam asi buden navždy, nebo bude muset Apple migrovat na nějaký jiný BASH compatible shell

Ale jinak s vámi souhlasím, BASH v3 je minimum, v práci si bohužel nemohu dovolit využívat novinky z BASH v4, právě z důvodů podpory výše uvedených OS.

[pedro]

na zacatku skriptu urci interpret a dal se na to vyser

[D.A. Tiger]

[k3dAR]
Diky moc

[Marek]

Ahoj,

rád bych doplnil odpovědi o něco, co tu chybí.

Kód: [Vybrat]

#!/bin/sh je super pokud chceš být kompatiblni se všemi možnými shelly (a v takovém případě se chceš vyhnout bashi a píšeš posix script, jak již bylo zmíněno) ale původní otázka se týka  kompatibility BASHů.

Proto bych doporučil použít

Kód: [Vybrat]

#!/usr/bin/env bash
I proto když se třeba záměrně nechceš okrást o BASH funkcionalitu. Plus je to dnes jakýsi standard ale to je moje doměnka vycházející ze zkušenosti 

Výše zmýněná konstrukce zajistí spuštění bashe, který je právě na sysytému nainstalován (resp. první bash v cestě $PATH).

[kmarty]

Plus je to dnes jakýsi standard ale to je moje doměnka vycházející ze zkušenosti 

Tohle jsem videl prakticky vyhradne jen u Pythonich scriptu (kde bych tu snahu ten pythoni bordel aspon trochu ukocirovat chapal), u shell scriptu se spis sazi na kompatibilni zapis (a pouziti #!/bin/sh) pokud jde o snahu zachovat funkcnost vsude mozne.

[JardaH]

Zdravím.

Učím se trochu programovat v BASH a narazil jsem na otázku, zda dodržovat při programování zpětnou kompatibilitu s dřívějšími verzemi BASH. Ptám se tedy, v jakých případech by se měla zpětná kompatibilita dodržovat a v případě, že jo, tak jak hluboko do historie verzí BASH.

Pokud ti jde v prvé řadě o přenositelnost, pak doporučuji POSIX shell. Např. na MacOSX je bash 3.x, na Linuxu všude většinou 4.x. Např. asocitativní pole jsou podporovány až od 4.x. Další problém může být GNU, BSD nebo komerční svět. Takže GNU obecně podporuje nejvíc nekompatibilních fýčuránek. Takže např napsat sed skript přenositelný mezi Linuxem a MacOSX je oser.

Spousta portabilních scriptů začíná nějakých 100 řádkovým case-esac blokem: http://standalone.contextgarden.net/setup/first-setup.sh
Tady hlavně kvůli instalaci binárek, ale občas tam jsou i různý nekompatibility na úrovni systémových/POSIX utilitek. Kdysi mě třeba zaskočilo, že Slackware nemá dlouhé přepínače na CLI, napsal jsem pro zákazníka skript, kde jsem použil pro lepší čitelnost dlouhé přepínače z RedHatu a musel jsem to předělávat...

Např. chování a přepínače něčeho tak zásadního jako je echo jsou dost nepřehledné, takže použij spíš printf. Pokud píšeš skripty pro sebe, tak si ušetři práci a na kompatibilitu se vyprdni, pokud je to jen pro Linux a pro tebe.

Spíš se zaměř na čitelnost, nějaké strukturování (functions) a kontrolu návratových kódů a přepínačů a občas si to nech zkritizovat shellcheckem.

[nm]

...Pokud píšeš skripty pro sebe, tak si ušetři práci a na kompatibilitu se vyprdni, pokud je to jen pro Linux a pro tebe.

Spíš se zaměř na čitelnost, nějaké strukturování (functions) a kontrolu návratových kódů a přepínačů a občas si to nech zkritizovat shellcheckem.

Myslim, ze budu spise psat skripty v Linuxu a pro sebe. Co mi v takovem pripade doporucujete? Naucit se psat skripty POSIXove (nektere linuxove distribuce jsou lepsi ve starych verzich), nebo se naucit ficury z BASHe (pro novejsi systemy)? To bych ale pak musel umet rozlisit vsechny Bashismy - tedy znat rozdily BASH vs POSIX sh (a pripadne i dash).

[Michal Zacek]

Jak uz jsem tady psal nekde na zacatku diskuze, pokud to nepotrebujes, je zbytecne nejakou zpetnou kampatibilitu resit. Kdyz budes dobre znat BAash, zvladnes, bez problemu napsat i POSIX kompatibilni skript. Pokud umis alespon trochu programovat doporucuji knizku "Bash Notes For Professionals". Bash neni nijak slozity takze neni treba ztracet cas nejakou teorii.

[Marek]

Plus je to dnes jakýsi standard ale to je moje doměnka vycházející ze zkušenosti 

Tohle jsem videl prakticky vyhradne jen u Pythonich scriptu (kde bych tu snahu ten pythoni bordel aspon trochu ukocirovat chapal), u shell scriptu se spis sazi na kompatibilni zapis (a pouziti #!/bin/sh) pokud jde o snahu zachovat funkcnost vsude mozne.

Argument vůči informaci vytržené z kontextu. Proto jsem to také vztahoval k BASHi.