bash versus python

Szkriptek: Python, Perl, Bash, ...

Sziasztok!

Volt egy egyéjszakás kalandom, amikor is hirtelen felindulásból bash -ban megírtam egy weboldal generálást PoC célzattal.

Ez anyira jól sikerült, hogy utána tovább írtam, bonyolítottam, aztán még jobban bonyolítottam, és most ott tartok, hogy van cirka 80+ kilobyte -nyi bash kódom, ami bár átlátható, de nem túl szép. Egy rakat for ciklus, benne echo, aztán megint for, meg döntések a kapott GET/POST paraméterek alapján, valamint helyi fileok olvasgatása és írása.

SQL vagy más adatbázis nincs használatban, mert olyan kevés (néhány kilobyte) adattal dolgozik, hogy az bőven belefér a file cache -be, így a "grep -F foobar alma.txt" valójában a memóriából megy, nem tekintve  grep forkolásának az idejét. De ebből sincs sok, mert a program az elején beolvassa mindent egy monstre asszociatív bash tömbbe, és utána a sok echo meg for már innen dolgozik, nem nyúlunk a lemezhez. Bash string manipulációk, illetve sed/awk még előfordul, ez utóbbiak bizonyára rosszat tesznek a performanciának, de valójában ezekből sincs olyan rengeteg. (Mondjuk azt nem tuom, hogy mennyi a rengeteg, na mindegy.)

A gondom azzal van, hogy a jelenlegi jellemzően 4-7 másodperces HTML renderelési időt sokallom.

Úgy vélem, hogy két út áll előttem.

1, a jó módszer, hogy újraírom az egésze pythonban, a jelenlegi célt figyelembe véve, de teljesen más módszertannal, vagyis nem tartok meg a jelenlegi kódból semmit. Ez elég sok időbe kerülne, ami pedig nincs.

2, Ezért arra gondoltam, hogy mi lenne, ha nem találnám fel újra a spanyolviaszt, hanem a jelenleg működő, kitesztelt, azonban lassúcska üzleti logikát másolnám át pythonba? Vagyis a bash echo helyett python print, bash if [[ helyett if ( és az awk/sed helyett a python string műveleteket hsználnám.

Mit gondoltok, ez nagyságrendileg mennyit gyorsíthat egy 80-90% -ban echo -t használó bash kódon?

Van ezzel valakinek tapasztalata?

  • 1923 megtekintés

( apal v | 2020. 12. 30., sze – 15:39 )

Hm... a bash nem gyors, de azert 4-7 sec-es renderelesi ido azert elegge tulkapasnak tunik. Persze ha 100x100 egymasba agyazott sed/grep/awk-t hiv meg akkor lehet az is lassu. Ezesetben tudsz par dolgon azert gyorsitani (`cat xyz | whatever` => `whatever < xyz`, `echo $a | whatever` => `whatever <<<$a`, /dev/shm /tmp helyett, a bash-tombokkel es bash-regexpekkel _nagyon_ sokat tudsz nyerni ha egyebkent nem hasznalod, ...), ilyeneket erdemes megnezned. Vagy ilyesmi hogy a sok awk => sh => awk => sh => ... lanc helyett minden awk-ban van. 

Elso korben igy, ilyen szemmel neznem meg a kododat mintsemhogy mas programnyelvbe attennem.

De tanulasnak meg ilyesminek persze jo. Es mig a bash-kodod az mukodni fog 10-20 ev mulva is, a python az lehet hogy a kovetkezo sub-minor verziofrissitesnel osszeomlik majd.

Én szívesen közreadnám, mert bár néhány szempontból gáz, de legalább negatív példának jó lesz valakinek. :-)

De előtte engedélyt kell kérnem rá, mert bár (szerintem) nem tartalmaz semmi titkosat, nem adhatok ki céges infót engedély nélkül. Ha a főnökeim rábólintanak, elérhetővé teszem a kókálmányomat. (max néhány beégetett IP címet elmaszkolok benne)

Ja, shell-scriptek írásánál ami lassú, az a sok fork/exec. Azaz amit meg lehet írni a sjaát belső eszközeivel, azt abban érdemes, de nyilván mértékkel. Amiket láttam ilyen scripteket, azokban jellemzően ott lehet sebességet nyerni, amiket apal írt, meg ha a grep izé | awk '{ ecet ; }'   jellegű kódot "optimalizálod" awk '/izé/ { ecet ; }' formába. (spóroltál egy pipe létrehozást, két átirányítást, nehány fork-ot, stb). Nyilván mindenen lehet extra futásidőt nyerni, de emberek nem szoktak mikrooptimalizációval szarakodni. De mutatok extrém példát. Alanti kóddal pl. éppen lehet tesztelni, hogy adott shell esetén a szimpla "változó növelése eggyel" művelet 5 lényegesen különböző formája között is van érzékelhető futásidő különbség, az más kérdés, hogy nem túl esélyes, hogy 600 ezres ciklusban csinál valaki ilyet, de ezzel együtt is 2 másodpercnyi különbség adódik stabilan a legjobb és legrosszabb futásidők között. :-) (és akkor az original Bourne-shell-ben használt i=`expr $i + 1` forma nem is szerepelt a tesztben - ez amúgy pont a fork/exec miatt nagyon sokkal lenne lassabb).

echo 'i=$(( i + 1 ))'
i=0
time while [[ i -lt 655350 ]] ; do
i=$(( i + 1 ))
done

echo 'let i=i+1'
i=0
time while [[ i -lt 655350 ]] ; do
let i=i+1
done

echo '(( i=i+1 ))'
i=0
time while [[ i -lt 655350 ]] ; do
(( i=i+1 ))
done

echo '(( i++ ))'
i=0
time while [[ i -lt 655350 ]] ; do
(( i++ ))
done

typeset -i i
echo 'i=i+1'
i=0
time while [[ i -lt 655350 ]] ; do
i=i+1
done

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Az iménti for ciklus Python3-ban 40-szer gyorsabban fut le. Ha a ciklus mindkettőnél 10-szeres, akkor 90-szer gyorsabban.

#!/usr/bin/python3

for i in range(655350):
    True

Egyúttal az előző példák:

#!/bin/bash

echo 'i=i+1'
i=0
while [[ $i -lt 655350 ]]; do
    i=$[$i+1];
done
echo $i

#!/usr/bin/python3

print ('i=i+1')
i=0
while i < 655350:
    i+=1
print (i)

Szintén 30-szorost meghaladó tempóval hasít az utóbbi a bash-hoz képest. 10-szer nagyobb ciklusnál 50-szerest meghaladó tempóval.
A Lua a Python3-ra rávert, a nagyobb ciklusnál 5-szörös tempót.

#!/usr/bin/lua

print ('i=i+1')
local i=0
while i < 6553500 do
    i = i+1
end
print (i)

Csak jelzem, hogy a bash-ban az

i=$[$i+1];

(hivatalos néven aritmetikai helyettesítés) az pontosan ugyanaz, mint a

i=$(($i+1));

(amit írtam - csak az általam használt szintaxist a ksh is megeszi, nem csak a bash), ellenben viszont teljesen más, mint az általam a példában szintén szereplő

typeset -i i ; i=i+1

ami viszont kihasználja a változók "integer" tipusú példányainak speciális kezelhetőségét.

Más szóval: teljesen máskódbázis értelmezi azt amit te írtál, meg amit én.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ezt lehet még gyorsítani

time for i in {0..655350} ; do : ; done

- ez speciel sokkal jobban hasonlít a pythonos range operátorra :-)

Jav: talán ez a ciklus is 0-tól menjen :-)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

A range() érdekes cucc. Ma ez úgy működik Python3 és Rust nyelven, hogy az osztály next() metódusát hívja meg minden lépésben, aztán a vége Python StopIteration, Rust esetén pedig None.
Bármilyen    for x in akármi(értékek) cuccot tudsz csinálni így Pythonban és Rust-ban egyaránt. A visszatérő x pedig lehet összetett értékekből álló tuple is.
Tehát Pythonban a for x in .... az osztály iterátorának __next__() metódusát hívja.

$ python3
Python 3.8.6 (default, Sep 25 2020, 09:36:53)

>>> a = range(3).__iter__()
>>> a.__next__()
0
>>> a.__next__()
1
>>> a.__next__()
2
>>> a.__next__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration
>>>

Rust esetén is hasonló. Összedobtam gyorsan egy szemléletes példát: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist…

Hmm... ez egy jó meglátás.

Tényleg van jó pár str="$(echo "$akarmi" | sed ... | awk | ...)" tipusú értékadásom ami sokszor lefut.

Végigmegyek a kódon, és átírom optimálisabbra, egyrészt mert ez belátható méretű feladat, másrészt mert előre mutató dolog, ha megszokom az "echo ... |" helyett a "<<< ..." használatát.

Köszönöm!

További tippek az "$(echo "$akarmi" | sed ... | awk | ...)" kiváltására:

  • awk -v Valtozó=${Valtozo}
  • awk ... Valtozo=ENVIRON["Valtozo"]  (set -a vagy export Valtozo !!)
  • eval használata
  • sed - helyette elég az awk, de műkedvelőknek talán elég a sed. Abban is lehet programot írni. ;)
  • hosszú bevasalt konstans -> text here
  • echo helyett írhat mindjár az awk is, de mindenképp echo $Valtozo $(awk...)
  • utasítás zárójel használata - rossz példa: { echo "start" ; cat file } | awk ...
  • ha már awk, akkor sok dolgot meg lehet abban is írni!

Az utóbbira egy példa - router újraprogramozása telnet felületen: config -> awk -> telnet <-> router

Ebben a felállásban az awk vezérli a telnetes menüket és írja be a config elemeit az input mezőkbe.

( ibenny v | 2020. 12. 30., sze – 15:58 )

apal kollega javaslataval indulnek el, a bash-kod refaktorlasaval is nagy javulast erhetnel el, ami jovobiztosabbnak is tunik. Nemreg talalkoztam a ShellCheck nevu kis tool-lal, ami megvizsgalja a shell-scripted es javaslatokat tesz a javitasra, amondo vagyok, arra is erdemes lenne ranezned, sok hasznos javaslata van, meg ha nem is hasznalsz fel mindent.

( kroozo v | 2020. 12. 30., sze – 19:22 )

Én elsőre inkább azt kérdezném, hogy a 4-7 sec az miért sok? Mármint hacsak ez nem valami "dinamikus" oldal mögött van (amikor viszont azért rögtön elkezdenék gondolkozni a shellen) igazából ez leginkább csak változásnál érdekes, akkor meg egy pipelineban a 4-7 sec vs 1-2 sec az kevésbé érdekes szerintem. Szóval érdemes lehet ebből a szempontból is elgondolkodni.

Viszont ha már a spanyolviaszt emlegetted, vanilla pythonban biztos hogy nem ugranék neki, van egy köbvödör static site generátor...

A weboldal nem static. Vannak benn lenyíló részek, meg gombok, meg űrlap, szóval javascriptet is generálok az éppen megjelenő aktív elemekehez.

Ez a része nem szép, például nem használok CSS -t, hogy aztán osztályokat rendeljek az elemekhez, hanem ahol éppen tartok egy ciklusban, ott az adott objektumnak direktben állítom be a színét, méretét, stb.

Ez az elején nagyon nem tetszett a browsernek, de aztán a kollégám javaslatára a kimenetet nem soronként adtam vissza a browsernek, hanem megvártam míg tejesen kész a HTML kód, és akor egyben catoltam ki a kimenetre.

A generált HTML így sok felesleges elemet tartalmaz, ez CSS -el szebb lenne, de nálam a bash oldalon csak egy kicsit hosszabb az echo utáni szöveg.

A gond az, hogy amikor a felhasználó rákattint benne egy elemre, akkor a 4-6 másodperc már fájdalmasan hosszú válaszidő.

Számomra nem tiszta, hogy a bash-nek a html kód legenerálása tart ennyi ideig, vagy maga az adatok feldolgozása.

Illetve az sem, hogy a bash és a böngésző hogyan van összekapcsolva, nyitva van egy port és a bash script fut, előre legenerálja a html oldalt, vagy minden hívásnál lefuttatja újra.

Elég fura az, hogy ha valaki kattint egy elemre, az 4-6 másodperc legyen. 

Nem, ez egy teljesen primitiv, egy mar meglevo webszerveren (apache) egy oldschool cgi-bin -ben elhelyezett status.html ami belul valojaban egy bash.

Meghivaskor beolvassa a szerverre korabban feltoltott fileokat egy jo nagy tombbe (ez gyors) aztan a tomb (ami valojaban egy struc) elemeit vizsgalva egyes reszeket megfelelo modon ir ki.

Nehany tablazatot general, sima table tr td elemekkel, de persze nehanyat egybe is agyaz, hadd szenvedjen a broswer. :-)

A cellakba szinesen irja bele a szoveget, meg kis ikonkakat (svg) amik kattinthatoak. A kattintas primitiv onclick ami a html forras elejere pakolt script fuggvenyeit hajtja vegre. Itt JS oldalon van nemi parameter szamolgatas, de ez is gyors, es ebbol lesz egy uj GET vagy POST hivas, ugyanerre a status.html -re.

Ez indulaskor aztan megnezi, hogy mit kapott, es akkor csinal valamit, egy-ket grep, awk, es atiranyitas, ez is gyors. Aztan nekiall ujra legeneralni a tablazatot, es ez az ami lassu.

Hmm. Ha mashogy oldanam meg a UI elemeket, akkor a kigeneralt tablazatok mehetnenek cache-bol, elvegre tobbnyire ugyan az lesz a vegeredmeny, leginkabb akkor valtozik a kepernyore kerulo tartalom, ha kattinras tortenik.

Ez egy rendszer statuszt mutato oldal, ami az operator szamara kattinthato, ha valami piros, akkor egy kis ikonra kattintva "lenyitja" a reszt, es aztan a lenyitott reszen megjeleno telefon vagy boritek ikonra kattintva SMS vagy email ertesitest kuld a problemarol, ami automatikusan a megfelelo cimre/szamra megy a megfelelo szoveggel, amit szinten a bash oldal generalt bele.

Tudom, parasztos, de hat ilyen az amikor egy PoC olyan jol sikerul, hogy egyszer csak szinte magatol eles uzembe all. :-)

Elolvasva mit csinál a script, az jutott elsőre eszembe, hogy erre bármi más nyelv sokkal alkalmasabb lenne, mint a BASH script :-D
Kézenfekvő lenne PHP vagy Python pl. Mindkettőhöz rengeteg segédlet van webes feladatokhoz.

Nyelvtől függetlenül:

Nem lehetne szétbontani a feladatot egy hívásra futó és egy ütemezetten futó részre?
- a hívásra futó lenne a frontend amit az operátor kattinthat,
- az ütemezetten futó rész állítaná elő a nagy táblázatot (olyan gyakorisággal, ahogy a forrás tartalom változhat, vagy esetleg valami eseményvezérelt módon - nem ismerem a környezetet, amit figyel), ami sokáig tart.

Vagy még egy olyan lehetőség, hogy ami kattintásra történik, az nem komplett új oldal generálást-betöltést eredményezne, hanem valami JS/AJAX módon csak oda töltené be a kinyíló rész tartalmát.

"JS/AJAX módon csak oda töltené be a kinyíló rész tartalmát" - az is egy ugyanolyan html-kérés a szerver felé, úgyhogy vagy ír egy másik scriptet, ami az ilyen rész kéréseket feldolgozza, vagy marad így. Mondjuk én fognám magam, és azzal indítanék, hogy vi akarmi.pl :-) és abban use CGI, aztán mehetne a móka :-D

Na igen, nem írtam le konkrétan, de valóban, újabb script-ek és/vagy a jelenlegi szétbontása kellene mindegyik ötletemhez.

Vagy extrém módon, a jelen script-en belül megvalósítani minden fentebbi üzemmódot, és indítási paramétertől (vagy *nix világból inkább symlink név alapján) eldöntve, mit csináljon éppen. :-)

Igen, most en is ezen gondolkozom.

Jelenleg a kigeneralt tablazat nem teljesen egyforma minden alkalommal, mert ha belekattint az operator, akkor plusz reszkent megjelenik benne a lenyilo resz egy oda generalt urlappal es gombokkal.

Most azon gondolkozok, hogy egy tok egyforma tablazatot generalhatnek a hatterben, es azt ebbol a cache-bol tolnam ki. Ebben pedig fixen benne lennenek a sorok azonositoi, amire ha rakattint, akkor egy masik frame-ben jelenik meg az urlap tartalom.

Igy nem kell mindig generalni a statikus tartalmat, csak azert, hogy tabla elem szinten stimmeljen a dinamikus tartalommal.

Hmm.. ezzel csak az a gond, hogy ha az operator kattint, akkor megvaltozik a tablazat (mert "kezelte" a sort) ergo ilyenkor pont hogy ujra kene generalni a tablazatot. Hmm.. Ezt valahogy mashogyan kene kezelnem. Pl. Egy kulon .js file generalas, ami onload -ra lefut, es az adott azonositoju elemeken (amelyeket a hatterben generalok) beallitja a visible flag-et, igy a sok elembol allo tablazat kvazi statikus, mert csak egy rovid kliens oldali kod az ami dinamikussa teszi, viszont ezt gyorsan le lehet generalni klikkeles utan.

Nagyon sok olyan rendszer volt mar, ahol aki lohalalaban osszedobott valami szart, az elterjedt, es utana - ha volt ra - tettek rendbe technikailag. Mig a konkurencia termeke - ami 2 honappal kesobb jott ki a szepen megtervezett kodjaval - meg eltunt a homalyban. Van olyan, hogy a PHP-s fosodhoz kell egy sajat PHP->C++ fordito, hogy ertelmes sebesseggel fusson, de annyi kodot irtal mar hozza, hogy nem eri meg ujrairni (ld. facebook). A tiednel meg valoszinuleg az a legjobb, ha a jelenlegi tapasztalatodat felhasznalva leulsz, es megirod rendesen valamiben, ami nem bash.

A strange game. The only winning move is not to play. How about a nice game of chess?

Elmeletben kinyithatna egy div -et a katiintas, es betolthetne oda tartalmat, de nem trivialis, hogy hogyan ferne el. Eleg bonyolultra sikerult a sok egymasba agyazott es rowspan/columnspan -al megbolonditott tablazat.

De egy kulon frame -ben elhelyezhetoek az urlap elemei es a gombok is.

Ez kérem, egy stabil, jól bevált, sokak által letesztelt technológia!

Oké, kicsit fapados*, de túlélte még a kiírthatatlannak hitt Flash -t is!

Miért ne építsek egy olyan technológiára, ami jó eséllyel még engem is túlél?!

:-D

 

* marketingül: Letisztult és átlátható a funkcióhalmaz és a szintaktika is.

Aha.

Hát, szép önszívatásnak hangzik :) Amit ilyenkor valamennyire még lehet csinálni, hogy a "dinamizmus" a jsben lakik, de ez nyilván adott esetben viszonylag nagy mennyiségű átdolgozást igényel, szóval én most hajlanék arra, hogy inkább akkor javítgass shell scriptből forkokat kifele.

Illetve hosszabb távon érdemes végiggondolni, hogy pontosan mi is kell, mert azért egész sokáig el lehet jutni rendesen szervezett html templatekkel, valami webes "widget settel" meg adott esetben valami cső egyszerű REST framewrokos kiszolgálással a változó adatokhoz, nem biztos, hogy olyan nagy munka lenne.

( ggallo | 2020. 12. 30., sze – 20:19 )

Én egy (sok) SSH-t használó infó gyűjtő és mentő BASH script-et írtam vagy két éve (hálózati eszközök konfigurációját menti). Ahogy Te is írod, nekem is (összetett) tömbökkel, grep, sed, awk eszközökkel dolgozik, a futás végén különböző statisztikákat, kigyűjtéseket, összegzéseket ad arról, mint végzett.

Most kitaláltam, hogy csinálok elé egy webes oldalt, hogy a mentéseket a kollégák kényelmesen, SSH-zás (és az én felhívásom) nélkül elérjék. Rövid nézelődés után arra jutottam, hogy nem szeretném file rendszerből felolvasgatni a weblap generálásakor, hogy mi érhető el, DB-ből kellene inkább, úgy gyorsabb, biztosabb. A BASH script DB-s fejlesztését alapjában elvetettem, én nem érzem, hogy a BASH script lehetőség erre lenne kitalálva (sőt, már a mentő script-et is túlhasználatnak érzem ilyen téren). Persze minden megoldható mindenben, de van-e értelme... Mondjuk ez a script nem igazán hosszú, úgy 650 sor, 19 kB.

Erre gondoltam egyet, hogy gyorsan beletanulok a Python-ba (sose használtam eddig), mert azt mondják nagyon jó, ilyen célra (is) használható nyelvnek, és megírom újra abban, a már kitalált plusz funkciókkal.

Neki is ugrottam, beletanulással együtt kb. 4 nap alatt lett kész, jóval bővebb funkcionalitással, DB kezeléssel (még azt is beleírtam, hogy az addigi file alapú konfig/nyilvántartás DB-s migrálása meglegyen). A futási sebesség összehasonlíthatatlan az én esetemben, kb. 10x gyorsulást eredményezett az újraírás. Ráadásul kezdő Python-osként sima lineáris/procedurális programként csináltam meg, nem OOP alapokon ahogy illene, éppen azért, hogy minél kevesebb időmet vigye el. Majd ha egyszer sok időm lesz, átírom.

Én javaslom az újraírás megfontolását is ezen tapasztalatom alapján.

Erre a felhasznalasra kifejezetten alkalmas a multiprocessing modul (pl. a map hivas). Gondolom valahol egy ciklusban vegigmesz az eszkozokon, es mindegyikrol osszeszeded a szukseges infot, ami jol parhuzamosithato, nem CPU igenyes, es a halozat is valoszinuleg birja. Ha mondjuk 4 szalon toltesz mindent, akkor az kb. 4x gyorsulast jelent.

A strange game. The only winning move is not to play. How about a nice game of chess?

Nagyon köszönöm az észrevételt, el is olvasom a neten a részleteket ezzel kapcsolatban, mert valóban egy ciklus csinál mindent, és az egyes lépései nem függenek egymástól semennyire, párhuzamosíthatóak.

Na, a 4 nap ezzel foglalkozás pont nem volt elég arra, hogy kinyomozzam, hogy hogyan is lehetne igazán jól csinálni! :-)

Valójában teljesen mindegy a futásidő, mert napi rendszerességű a mentés, és a 350 eszközön a BASH script is végig ér szűk egy óra alatt, de tanulás oldalról nagyon érdekel a dolog, így megcsinálom ezt a párhuzamosítást mindenképp.

( uid_6201 v | 2020. 12. 30., sze – 21:13 )

Szerkesztve: 2020. 12. 30., sze – 21:27

Python3 erre alkalmas és itt is kihasználva a lehetőségeit, nem másolva át a shell-ben kényszerből leprogramozottakat.

Ha kell standalone web szerver példa: https://gist.github.com/mdonkers/63e115cc0c79b4f6b8b3a6b797e485c7
de sok esetben célszerű lehet ez is: https://www.tutorialspoint.com/python_network_programming/python_http_s…
Ha kell template engine: https://jinja.palletsprojects.com/en/2.11.x/

$ python3
Python 3.8.6 (default, Sep 25 2020, 09:36:53)
>>> import jinja2

stb. stb.

( kruska v | 2020. 12. 30., sze – 21:49 )

Nálam nagy ugrást hozott a bash scriptjeimben, hogy az adatfeldolgozást adatbázisba tettem át. Csak egy mezei sqlite-t használok, ez csak egy szimpla bináris és egy adatbázisfile. Az adatokat beletolom egy táblába, és ott már SQL parancsok segítségével sokkal egyszerűbb az adatok kezelése (legalábbis nekem jobban kézreáll, mert az awk sajnos nem annyira jó barátom).

Néhány kiragadott példa:

sqlite3 $db "INSERT INTO tape (id, type, created, label, location, position) VALUES (\"$u\",\"$type\",\"`date -I`\",\"$2\",\"$l\",\"D\")"

sqlite3 $db "UPDATE drive SET tid=\"$u\", process=\"idle\" WHERE library=\"$l\""

target=`sqlite3 $db "SELECT position FROM tape WHERE location=\"$l\" AND id=\"$tid\""`

tid=`sqlite3 $db "SELECT tid FROM backup ORDER BY bcreated DESC LIMIT 1"`

if [ "$SCRIPTVERSION" != "`sqlite3 $db 'SELECT version FROM appsettings'`" ]; then

( hory v | 2020. 12. 31., cs – 00:53 )

bash alapvetoen bazi sokmindent meg tud csinalni maga is; a standard unix tool hivasok nagy resze igazabol (valamivel rondabban) megoldhato pure bash-ben.

Ami nekem sokat jelentett, az az IFS + read (es maris parse-olhatod az inputot bash-bol kozvetlenul), illetve a bash beepitett regex support-ja (asszem bash 4 -tol van csak, szoval relative uj; erdemes megnezni a "what's new" szekciot a bash release-knel!).

( uid_6201 v | 2021. 01. 01., p – 11:58 )

Szerkesztve: 2021. 01. 03., v – 18:59

A fentebb bemutatott teszt kódokhoz még egy adalék: gawk. Azért a gawk, mert önmaga tud TCP kapcsolatot kezelni.

#!/usr/bin/gawk -f

BEGIN {
    print ("i=i+1")
    i=0
    while ( i < 6553500 ) {
        i++
    }
    print ( i )
}

És ha megnézzük csak erre az egyszerű példákra a futásidőket, belátható hogy a bash hurrá, de nem mindenre megfelelő választás a szkriptnyelvek között. Kirívóan lassú.

time ./teszt.bash  # 6553500 -> 32,47 másodperc
time ./teszt.py     # 6553500 -> 0,68 másodperc
time ./teszt.awk   # 6553500 -> 0,39 másodperc
time ./teszt.pl      # 6553500 -> 0,27 másodperc # utólag perl 5.30
time ./teszt.lua   # 6553500 -> 0,14 másodperc
time ./teszt.js    # 6553500 -> 0,13 másodperc # utólag nodejs 12.18
time pypy3 ./teszt.py # 6553500 -> 0,096 másodperc
time ./teszt.php # 6553500 -> 0,068 másodperc # utólag PHP 7.4.9
time luajit ./teszt.lua # 6553500 -> 0,014 másodperc

OpenWRT esetén például a kis háttértár és kis memóriafoglalás miatt LUA mellett döntöttek. Itt látható néhány LUA-ban írt web szerver: http://lua-users.org/wiki/LuaWebserver
GAWK-ban is található web szerver implementáció: https://github.com/kevin-albert/awkserver
Python3 esetén alapból kész modulok vannak: https://gist.github.com/mdonkers/63e115cc0c79b4f6b8b3a6b797e485c7

( arpi_esp v | 2021. 01. 02., szo – 22:03 )

en anno a 2000-es evek elejen irtam egy halozat monitorozo rendszert, par bash scriptbol indult, aztan lett html tablazat generalo script is aztan kesobb ez egyre komplexebbe valt, lettek cgi-k amiket weben parametereztem stb, mig par ev alatt mar - a komplexitas es az egyre tobb input adat miatt - vallalhatatlanul lelassult. a python akkoriba kezdett befutni, a perl-hez nem volt gyomrom, igy eloszor csak a sebesseg kritikusabb reszeket irtam a py-be, es ezzel hosszu evekre megmentettem a projektet, mig vegul kb 5 eve irtam ujra 0-rol az egeszet pythonban.  sql-t meg mindig nem hasznal, fileokban van minden, neha rengeteg kis fileban, de ahol emiatt lassu volt ott atpakoltam egy ramdiskre/tmpfs-re azt a konyvtarat es cronbol orankent lementettem.

szoval en azt csinalnam, hogy ami nagyon lassu csak azt irnam at, a tobbit meg hagynam bash-ban.

( nagylzs v | 2021. 01. 04., h – 08:41 )

Szerintem írd újra, jobban jársz. Elolvastam hogy hogy alakult ez ki, de akkor se értem az indíttatást. Bash-ben soha nem fognék hozzá ilyesmihez, PoC célzattal se. Bármire ami ciklust meg feltételeket tartalmaz, érdemes rendes programnyelvet használni. (A bash nem rendes programnyelv.)

Kivételnek számít szerintem az, ha:

1. Arra van szükség hogy mindenhol fusson, ott is ahol nincs telepítve python. Bár ebből a szempontból a bash is kérdéses, az ilyet bourne sh -ban szokás, mivel a bash általában a /usr alá települ, és a "mindenhol fusson" eset akkor számít igazán, ha nem sikerült mount-olni a /usr -t...

2. Ha rc script-et akarsz írni (de igazából erre is sh-t szokás, főleg azért mert a /usr mount-olása előtt is működnie kellene)

3. Ha nagyon nagyon egyszerű dologról van szó, rekurziók meg függvények nélkül, amit egyszerű átlátni.

Szerintem akkor kellett volna átírni Python-ra vagy valami másra, amikor meghaladta a 100 sort. :-)

Persze tudom ez így utólag nem segít a mostani problémádon.

Itt az egy éjszakás feladat az volt, hogy lehet-e értelmesen összekötni két rendszert, hogy az egyik által létrehozott infókat egy böngészőben lehessen megnézni, ahelyett, hogy az leveleket küldene. De mindezt úgy, hogy nincs teszt rendszer, ezt egyből az élesen lehetett csak létrehozni, így a kockázatok és mellékhatások minimalizálása miatt semmi plusz szoftvert nem akartam.

Mivel elméletben rém egyszerű volt a dolog, bash -ban írtam, mert aznap este még több meló volt az adatok transzfomálása mint a html generálás.

Az első éjszakán egy sima fekete-fehér táblázat volt a végeredmény, ami arra volt jó, hogy lássuk, az üzleti koncepció jó, és hasznos. Ez úgy 8-10 sor file olvasás és adat kezelés, meg talán 10-20 sor echo volt. Az első status.html még egy képernyőn elfért, mert a nagy meló a környezet (az adat küldő szerver oldal, és a web szerver fogadó része) megírása volt. Az most is bash, és ezeket nem is akarom átírni, mert minek?

Ezután mindig csak egy kicsit kellett módosítani a html renderelésen, először színes lett, aztán a table elemekből lett több, majd jött az ötlet, hogy egy form nem ördöngősség, ellenben hasznos. Funkcionálisan nincs vele gond, fejleszteni sem egy ördöngősség, mert az algoritmus rém egyszerű.

Csak ezen a nyelven a string manipulációk egy része külön bináris indítását okozza, (grep, sed, awk, tr) ami nem jó.

Maga a bash szerintem tök jó hasonló kis programok írására, de komolyabb szoftvert, aminél már az elején látszik, hogy mekkora lesz, persze nem ebben kezdenék el. Ez a projekt viszont konkrétan úgy született, hogy egy délután a kollégával elkezdtünk dumálni, hogy hogyan lehetne még jobbá tenni ezt a valamit, és jött az ötlet, hogy vezessük ki webes felületre. Hazafele forgattam magamban az ötletet, este letettem a gyerekeket aludni, asszonypajtásnak nem volt kedve sorozatot nézni, én meg még nem voltam álmos, így hát leültem a gép elé. Hajnalra megjelent az első eredmény, ezért másnap tök büszkén mentem be, és mutattam a kollégának, hogy idenézz, mit rittyentettem!

Ns, hát most már én is látom, hogy mit rittyentettem. :-)

> Az első éjszakán egy sima fekete-fehér táblázat volt a végeredmény, ami arra volt jó, hogy lássuk, az üzleti koncepció jó, és hasznos. Ez úgy 8-10 sor file olvasás és adat kezelés, meg talán 10-20 sor echo volt. Az első status.html még egy képernyőn elfért, mert a nagy meló a környezet (az adat küldő szerver oldal, és a web szerver fogadó része) megírása volt. Az most is bash, és ezeket nem is akarom átírni, mert minek?

Pedig szerintem pontosan ez volt az a pont amikor a "point of concept" rész véget ért. Azt a 20 soros programot még nagyon egyszerű lett volna átírni rendes programnyelvre.

és hogy minek? - nos ha nem lenne vele probléma akkor nem csináltál volna róla fórum témát

> Csak ezen a nyelven a string manipulációk egy része külön bináris indítását okozza, (grep, sed, awk, tr) ami nem jó.

legalább példákat hozzál már erre, mert pont a bash azért (az eredeti /bin/sh-val ellentétben) ehhez  már ad néhány hasznos eszközt. (Itt egy példaszál az elméletre. Nem azt mondom, hogy ezt vagy ilyeneket kell használni, de lehet ilyeneken gondolkodni.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem azt mondom, hogy nem képes rá!

Csak azt mondom, hogy én nem ismerem, vagy valamiért nem használom.
Utóbbi lehet szimpla hülyeség is, de akár tudatos döntés is, például az olvashatóság miatt.
Ha csak egyszer kell végrehajtani, akor egy bonyolult regexp vagy bash "krikszkraksz" string manipuláció hiába gyorsabb,
ha egy év múlva én, vagy egy ezen a téren kevésbé rutinos kolléga nyúl hozzá, és félreérti a kifejezést.
A szép (olvasható, érthető, követhető) kód szerintem fontosabb mint a nyelv minden lehetőségének kihasználása.

Ilyenekre gondolok:

key="${pair%%=*}"
val="${pair##*=}"

A változó nevek miatt itt egyértelmű, hogy akkor ez most mi a szösz, de más nevekkel egy idecsöppenő emberke
lehet, hogy csak nézne, hogy mi is ez a százalék százalék egyenlő csillag?

        
Alább néhány részlet a scriptből, ezeket ne tudom, hogy ennyire követhetően meg lehet-e valósítani csak bash nyelven.

Függőlegesen akarom kiírni a blokk nevét, de ha túl kevés hely van neki akkor csak az első karaktert írom ki:

if [ $blockLineCount -le "$((${#statusTable}-2))" ]; then
        showStatus="<object title=$statusTable>$(echo "${statusTable:0:1}" | tr '[:lower:]' '[:upper:]')</object>"
else
        showStatus="$(echo "$statusTable" | tr '[:lower:]' '[:upper:]' | sed -e 's/\(.\)/\1<BR>/g')"
fi

Na, ez tipikus hibám, erősen átírásra szorul, echo helyett <<< lesz belőle, kivéve, ha ennél is jobban meg lehet csinálni.
Hmm... Most belegondolva, shortDateTime="${datetime:1:8} ${datetime:10:8}" vagy valami hasonló sokkal egyszerűbb lenne ide. :-)

shortDateTime="$(echo "$datetime" | cut -d '+' -f 1 | tr 'T' ' ')"

Ez sem szép, de legalább csak egyszer fut le:

histLines="$( grep -E "^[0-9]* (new|mail|sms|on|off) " "${outFile_Prefix}history_${pickYear}_${pickWeek}.txt" | grep -Fv "AUTO-TEST_MESSAGE" | tac)"

Ami sokat jelentene nekem, az a cut parancs bash verziója lenne, mert abból sok fut le.
Egyszerű grepet lehet csinálni if [[ "$szenakazal" == *"pici tu"* ]] formában, és a ~= esetén a regexp is muködik ha csak igen-nem felelet kell, és nem az egész sor.
Persze attól még lehet soronként ifelni, végül is, az sem egy rossz stratégia, a kérdést a grep indítások száma és a beolvasandó file mérete dönti el.

key="${pair%%=*}" # key is everything before = (chop the '=' and everything after it)
val="${pair##*=}" # val is everything after = (chop the '=' and everything before it)

 

és máris érted te is, meg az utánad jövő is. Attól, mert nem bízol az utánad jövő tudásában (hogy érti a shell összes huncutságát), de pont ugyanennyi erővel az se biztos, hogy a grep, awk, cut és tr eszközöket érti.

Legtöbbször pl. a tr-t meg lehet spórolni, mert a shell is tudja amire használod (és 99%, hogy olcsóbb shellben, mint a fork/exec-es tr-rel); illetve pl. a sed is tud ilyet (\u, \l, \U, \L és \E módosítók)

A kérdés nyilván az, hogy mennyire primitív szintig megyünk le egy eszköz funkcionalitásának kihasználásába. Itt átírtam amit lehet kizárólag shell eszközökre - illetve ahol nincs stabilan működő (*) , ott is lehet spórolni:

if [ $blockLineCount -le "$((${#statusTable}-2))" ];
        ### showStatus="<object title=$statusTable>$(echo "${statusTable:0:1}" | tr '[:lower:]' '[:upper:]')</object>
        showStatus="${statusTable:0:1}" # we need the first character only
        showStatus="${showStatus^}" # in UPPER CASE
        showStatus="<object title=$statusTable>${showStatus}</object>"
else
        ### showStatus="$(echo "$statusTable" | tr '[:lower:]' '[:upper:]' | sed -e 's/\(.\)/\1<BR>/g')"
        showStatus="$(echo "$statusTable" | sed -e 's/\(.\)/\u\1<BR>/g')" # put <BR> after each character and convert them to UPPER CASE
fi

 

(*) a kód : a=alma ; echo "${a//?/\0<BR>}" - ezzel 3 baj van: csak a ksh-nál van dokumentálva, csak a ksh-ban működik, és szerintem nem \0, hanem \1 kéne oda :-)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

> Bármire ami ciklust meg feltételeket tartalmaz, érdemes rendes programnyelvet használni. (A bash nem rendes programnyelv.)

Így :) Mindig mondom, hogy mikor egy scriptbe először leírod, hogy if, akkor kell tudatosítani, hogy a) ha most nem kezded el átírni másba, akkor ha nő, az arcodba fog robbanni. b) eddig szinte mindig nőtt.

Pedig már olyan hamis állítás is elhangzott, hogy a bash "nem program írására való". Persze ezt az állításit is könnyedén meg lehetett cáfolni. ;)

Olyan cáfolhatatlan állítások ugyan vannak, hogy

  • valaki nem képes (elsőre, másodikra) felmérni egy feladat adatfeldolgozási igényét
  • a print/printf és társai bármilyen program lassító tényezői
  • tömeges adatfeldolgozást nem shellben kell írni

A shellben a ciklus és a test egyáltalán nem lassú. Ha adatokkal és formátumokkal kell dolgozni, akkor viszont nem gazdaságos. A fork/exec sem lassú, de azért célszerű optimalizálni: pl. for() { awk } helyet célszerű a for() { }|awk

Az adatfeldolgozásra gyors, egyszerű fejlesztést kínál az awk.

(zellernek is)

Semmi ilyesmit nem állítottam. Biztos vagyok benne, hogy a fenti problémát is meg lehet csinálni úgy shellben, hogy ne tartson sok másodpercig. És természetesen lehet vele programot írni, csak imho nem érdemes. A shell imho egy elég szar programnyelv, az eszközkészlete elég halovány szinte bármi máshoz képest, és ami a legnagyobb baj(om nekem) vele, hogy elképesztően sokat kell a nyelv problémáival foglalkozni a saját problémáim helyett. (Ez a topic is jó példa, kb akármi másban jó eséllyel ezen a ponton fel sem merül még a teljesítmény probléma, hogy másodpercekig rendereljünk egy htmlt.)

Természetesen rém kényelmes, hogy ott van kéznél, csak ide leteszünk egy kis .sh-t, aztán már át is hidaltuk az illesztési problémánkat, meghegesztettük azt a kis hiányzó funkciót, nem kell ide más, azzal macera van.* Összeszámolni nem tudom, hány ilyen kis pötty-shból az évek alatt növekedett szörnyeteget láttam már, amit már mindenki csak bottal mert piszkálni, és komoly effortot igényelt a kiváltása, viszont igény volt rá, mert már esett-kelt, lassú volt, szar volt bővíteni, stb stb stb.

Szóval értem, hogy kissé sarkítás az első if, de nekem az egy jó ökölszabály, hogy na most gondold végig, hogy nem lesz-e ebből szörny, és ha igen, akkor kezd el normálisan csinálni. Természetesen lehet normálisan shellben is, akinek jobban benne van a kezében, annak kedves egészségére, mint mondtam, én nem szeretem. Illetve ez is olyan, mint a perl, hogy lehet benne szép kódot írni, csak nem szokás :D Szóval ha oda kerül a helyére valami más, akkor nagyobb eséllyel lesz nem széjjel barmolva.

És persze az awk gyors egyszerű adatfeldolgozást kínál. Mint kb bármelyik random scriptnyelv.

* Persze ebből adódóan nem kell teszt se, meg normális verziózás se, mert azzal is.

Én azt szoktam mondani, hogy a bejelentkezés után vane gy szerszámosláda, tele mindenféle eszközzel, és van a feladat, amit meg kell oldani. A feladathoz kell választani az eszközt, és ennyi.
A shell scriptek jók tudnak lenni, rcs/cvs/svn/git/akármilyen repókban normálisan, más nyelven elkövetett dolgokhoz hasonlóan verziózni - igényesség kérdése az egész. Ahogy nem python-ban a kód értelmes, átlátható formázása is.

"meghegesztettük azt a kis hiányzó funkciót" - nekem ilyen kis meghegesztésekből van egy rakat függvényem/eljárásom, amit ha kell, tudok hazsnálni vagy úgy, hogy egy.az egyben behúzom a scriptbe, vagy úgy, hogy a kérdéses részt kapja csak meg. Ez sem "varázslat", csak évek sora alatt felgyűlt olyan tudás, ami fájl formában is létezik :-)

Az evolúciós fejlődés helyett az entrópia segítette scriptburjánzást én is rühellem - ahogy a nulla kommenttel ellátott zagyvulásokat is. Nem egy, nem két "elődöm" után volt szerencsém scripteket maszírozni - volt, aki után kvázi öröm volt dolgozni, és volt, akinek a produktumát... Szóval funkcionálisan azonos megoldással helyettesítettem :-)

A végiggondolás már a PoC _előtt_ meg kell, hogy történjen, bár ami igaz, az igaz, eleinte akinek kalapácsa van, az mindent szögnek néz - de idővel a jobbak kinövik ezt a hozzáállást és (visszacsatoolva az első gondolatomhoz) megtanulják, hogy a szerszámosládában van többek között csavarhúzó meg popszegecselő is.

 

a szerszamlada megkozeliteshez:  lehet hogy valaki ugyesen banik a kalapaccsal, barmit meg tud vele szerelni, meg ha nem is tul hatekonyan, mig hiabva van popszegecselo is a ladaban, ha azt nem tudja hogyan kell hasznalni, es a surgos megoldaldo feladat mellett nincs ideje RTFM-re.

anno en is azert irtam bash-ban scripteket, mert azt ismertem, a pythont egyaltalan nem, a C meg nem igazan erre valo (irrealisan sok ido lett volna c-ben megirni ugyanazt, bar ketsegtelenul gyors lett volna).

> A shell scriptek jók tudnak lenni, rcs/cvs/svn/git/akármilyen repókban normálisan, más nyelven elkövetett dolgokhoz hasonlóan verziózni - igényesség kérdése az egész. Ahogy nem python-ban a kód értelmes, átlátható formázása is.

Persze, csak nagyon sokszor nem ez a jellemző. Természetesen van ilyen is, de kétségtelen tény, hogy mivel a "A végiggondolás már a PoC _előtt_ meg kell, hogy történjen," ezért felém ritkán jön a shell mint primary tool, szóval tipikusan ott jön, ahol már menet közben derül ki, hogy ja, na itt még kell mondjuk egy kis szeretet pl build stepben a jenkins/gitlab/jóégtudjaépp miben, vagy még egy kis simogatás az ansible modul után, egy kis exportolgatás a konténer indítóscriptjében, stb, stb. Ezek meg jellemzően olyanok, hogy biza oda lesz írva a jenkins job-ba pl, mert ha nem oda lenne, akkor már rögtön nem is lenne olyan egyszerű berángatni a megfelelő git repoból.

> "meghegesztettük azt a kis hiányzó funkciót" - nekem ilyen kis meghegesztésekből van egy rakat függvényem/eljárásom, amit ha kell, tudok hazsnálni vagy úgy, hogy egy.az egyben behúzom a scriptbe, vagy úgy, hogy a kérdéses részt kapja csak meg. Ez sem "varázslat", csak évek sora alatt felgyűlt olyan tudás, ami fájl formában is létezik :-)

Pesze, csak kérdés, hogy amit kimásoltál, azt utána majd pl hogy utóköveted ;)

> Én azt szoktam mondani, hogy a bejelentkezés után vane gy szerszámosláda, tele mindenféle eszközzel, és van a feladat, amit meg kell oldani. A feladathoz kell választani az eszközt, és ennyi. [ + kalapács ]

Persze. És ezen a shell szerintem nagyon sokszor megbukik. Egyszerűen azért, mert szerintem az nem annyira kalapács, mint inkább svájci bicska. Lehet vele mindenfélét csinálni, egyszerűbb dolgokat jól, bonyolultabbakat kényelmetlenül, meg lassabban, meg vigyázva, hogy szét ne cseszd (se a bicskát, se a munkadarabot), de a legnagyobb előnye azért mégiscsak az, hogy mindig kéznél van. És ha már tervezünk, akkor ritkán jutunk arra, hogy majd a bicsakkal megcsinálom.

Egyébként egyetértünk, a sarkított "először leírod az ifet" pontosan arról szól, hogy legkésőbb itt gondolkodj el kérlek rajta, hogy erre biztos a shell lesz a legjobb eszköz? Ténykérdés, hogy a kérdés feltételének módjában van némi perjudikáció és némi provokáció is. :) De az architect sapimban egészen jól bevállik, hogy aki bonyolult dolgokat shellbe akar írni, az indokoljon.

A shell imho egy elég szar programnyelv, az eszközkészlete elég halovány szinte bármi máshoz képest, és ami a legnagyobb baj(om nekem) vele, hogy elképesztően sokat kell a nyelv problémáival foglalkozni a saját problémáim helyett. (Ez a topic is jó példa, kb akármi másban jó eséllyel ezen a ponton fel sem merül még a teljesítmény probléma, hogy másodpercekig rendereljünk egy htmlt.)

És ezzel (meg a továbbiakkal) mindent elmondtál. Már 25 éve írok komolyabb programokat shellben. Ez nem azt jelenti, hogy hozzád képest mindent tudok. Inkább csak azt, amire szükségem van, illetve azt, hogy mit érdemes benne csinálni. Vagy mikor kell shell helyett/mellett awk vagy C.

A legfontosabb az adatok mennyiségét és típusát felmérni, majd a tevékenységeket. Utána jöhet a tervezés.

A "hattyúdalom" egy backup szerver, ami kb. 125 kliens logjait és adatait menti "kvázi online". Összesen 14 féle adattípust ment, ellenőriz, indexel, sőt a tevékenységet adatbázisba is írja. (de minek...) A fejlesztőknek a kiválasztott intervallumból és típusból log letöltést biztosít weben keresztül. Jelenleg >36M mentést tárol, takarít maga után és teljesen automatikusan működik. Napi >80M processzt futtat.

Szerintem lehet shellben nagy és biztonságos programot írni.

> És ezzel (meg a továbbiakkal) mindent elmondtál. Már 25 éve írok... [szokásos hosszas litánia valami csodálatos projektről]

Köszi, tisztában vagyok azzal, hogy a te farkadnál a világon csak te farkad nagyobb. Lehet egyszer kölcsön kéne adni hajbinak :D

> Szerintem lehet shellben nagy és biztonságos programot írni.

És hol állítottam ennek az ellenkezőjét?

Aha. A szokásos hosszas litánia legalább 4 (négy) mondatra rúgott. A csoda meg abszolút nem csoda, csak nekem működik.

Néhány feltételt már korábban is leírtam és itt is. Hatalmas farkam nyilvánvalóan árnyékot vethetett, így aztán az ámulattól a tervezés kifejezés nem érte el a tudatküszöbödet. Ezért rögzült az eredeti véleményed:

Természetesen rém kényelmes, hogy ott van kéznél, csak ide leteszünk egy kis .sh-t, aztán már át is hidaltuk az illesztési problémánkat, meghegesztettük azt a kis hiányzó funkciót, nem kell ide más, azzal macera van.

Természetesen nem állítottad, hogy shellben nem lehet nagy és biztonságos programot írni. Csak azt, hogy kóklerek heggesztenek vele, nem értesz hozzá, ezért inkább mással oldod meg a feladataidat. (Ami verziózható. ;)) Ilyesmit már más is mondott:

Nem tudom mi az, de ellenzem!

/Hófehérke és a hét törpe: Tudor/

> Aha. A szokásos hosszas litánia legalább 4 (négy) mondatra rúgott. A csoda meg abszolút nem csoda, csak nekem működik.

Ténykérdés, hogy a szokásos öntömjénezésnél rövidebbre sikerült. :)

>  Csak azt, hogy kóklerek heggesztenek vele,

Még csak ezt sem állítottam. Gyakran "kóklerek" hegesztenek* vele, gyakran a kóklerek hozzá is mernek pancsolni, mert "csak shell", gyakran úgy van használva, hogy nem úgy kezelődik, mint a "rendes" kód, akkor is, ha egyébként nem hülye emberek csinálják. És gyakran olyan ITs szakemberek, akiknek egyébként a kódírás nem a fő foglalatosságuk, szóval nem is nagyon tudják, hogy hogyan kell azt jól csinálni.

> nem értesz hozzá,

Annyira, mint te, biztosan nem. Annyira, hogy fel tudjam mérni, hogy programnyelvnek semmi különös, gyakorlatilag semmit nem tud, amit ne tudna más, hiányzik belőle egy rakás dolog, cserébe fosásig van landminne-nal a legegyszerűbb részeken is**, annyira igen. Én elhiszem, hogy ez 25 év távlatából már kevésbé látszik, meg rutinból megy a kerülgetésük, meg kialakult a stockholm szindróma is, meg hogy 25 éve még egy sokkal szenzibilisebb választás volt (bár ... nekem ugyan 25 még nincs, de már majdnem, és már akkor sem tűnt ez olyan jó ötletnek), de ettől még a shell nem lesz egy jó nyelv. És ettől természetesen hozzáértő kezekben még lehet benne normális, jól működő dolgokat csinálni. És van olyan, amikor az a sensible választás. Azt is elhiszem neked, hogy azon a területen, ahol te mozogsz, ez gyakoribb, mint ahol én.

Félre ne érts, szeretem én, az interaktív shell csodálatos dolog, csak egy seggel ritkán sikerül két lovat jól megülni. A unix shellek nagy részének a programozás részét nem is nagyon sikerül. Érdemes vetni egy pillantást a powershellre, ami scriptnyelvnek imho alapjában véve jobb, cserébe interaktív shellnek gyakorlatilag használhatatlan.

> (Ami verziózható. ;))

A nagy farkad árnyéka úgy látszik erősen gátolja a szövegértésed. Találd már ki kérlek, hogy azt is mondtam, hogy egy shell scriptet nem lehet verziózni.

* örülök, hogy nem csak én akarom mindig két g-vel leírni :D

** Mindig szórakoztat, hogy a fél szakma köpködi a pythont, mert a whitespace, bezzeg a shell meg a spacek...

"Mindig szórakoztat, hogy a fél szakma köpködi a pythont, mert a whitespace, bezzeg a shell meg a spacek..." - A shell-ben ha öt space van a | előtt, meg nulla utána, senkinek sem lesz belőle baja - a spacel-ek _számossága_ semmit sme befolyásol, nem része a szintaxisnak. Ellentétben a pájtonnal... Oké, a paraméterekben, az értékadásokban/változókban/adatszerkezetekben tudni kell helyesen kezelni a whitespace-eket is.

> Oké, a paraméterekben, az értékadásokban/változókban/adatszerkezetekben tudni kell helyesen kezelni a whitespace-eket is.

Hát ez az. Jól megválasztott* szeparátor, és sokat segít, hogy az adat meg a kód kicsit nehezen választható el egymástól. Ami a gyakorlatban, különösen így együtt, legalább egy nagyságrenddel nagyobb szopás meg hibalehetőség, mint hogy a python whitespaccel indentál. Illetve ha már a nulla, akkor azért külön kiemelném az '='-t a nem mindegy, hogy van vagy nincs esetben. Szóval oké persze, de ez bizony nettó önszopatás, akkor is, ha nektek az agyatok már hozzászokott. Akinek még nem, abban esetleg felmerül, hogy a "de mi van, ha space van az adatban" az a shell problémájának kerülgetése a sajátom helyett. ;)

*persze hogy jól, a faszom se akarna mást gépelni szeparátornak interaktívan.

"legalább egy nagyságrenddel nagyobb szopás meg hibalehetőség, mint hogy a python whitespaccel indentál" - Aki yaml-lel szopott már azért, mert egy helyen egy space-szel több/kevesebb volt, az másképp látja a dolgot. És ez csak konfig, nem kód. És ha a kód egy része elcsúszik, akkor jó esetben összeborul a program, rossz esetben hibás eredményt ad úgy, hogy lehet, hogy észre sem veszed.

Ha már ilyen jól benne vagyunk a szidásban, kicsit szídjuk meg a LUA nyelvet is.
Szkriptnyelv ez is, tempójára nem lehet panasz, főleg LuaJIT futtatókörnyezettel. Az OpenWRT webes konfigját is LUA-ban írták.
De a kis mérete folytán az NGINX-be is befészkelte magát és sok más progi belsejébe.

[kötözködés]

Egy db space yamlben imho mindenképp indentation errort fog okozni, és szólni fog a parser

[/kötözködés]

Szerintem akinek szindrómája van, az látja másképp. ;) Mármint ez a jó esetben összeborul mantra az pont ugyanúgy igaz shellben is, amikor épp a paraméter lista csesződik szét miatta mondjuk. Pont ugyanúgy meg tud bújni, csak ráadásul sokkal több helyen. 

Illetve erős csúsztatás ám a yamlel jönni, ahol valóban szoktak lenni randa hosszú sok képernyős borzalmak, amik validak, pythonban ha van ilyened, akkor annak a kódnak már úgyis mindegy, nem egy elcsúszó tabulálástól lesz szar.

"Egy db space yamlben imho mindenképp indentation errort fog okozni, és szólni fog a parser" - vagy sem, és benyeli a program, hogy az adott értékadás egy szinttel bentebb van. Tudom, szembe jött a probléma, és annyit lehetett látni, hogy az átkonfigurálás előtt működött valami, utána meg nem. Mint kiderült, egy szóközzel elcsúszott a módosítás.
 

Na jó, de ezt innentől szoftver tervezési hibának is vehetjük, nem feltétlen a YAML hibája...
Ugyanis ha olyan key nem lézetne egy szinttel bentebb/kintebb, akkor kapásból hibaüzenetet adna (elvileg, ha le van kezelve a hiba...), hogy ilyen opció ezen a szinten nincs is, miért írtad bele. Már látnád is, hogy nem jó az a behúzás.

Az meg a másik kérdés, hogy "modern" állományokat hozzájuk illő "modern" szerkeszővel kell írni, és ne én nyomjam a szóközt a YAML 8. szinthez tizenhatszor (vagy tizenötször/tizenhétszer, ahogy sikerül).

Én 30 évvel ezelőtt Turbo Pascal-lal alapítottam meg programozói mivoltomat. Az után irtó furcsa volt a Java/C# sima {} párja a BEGIN...END helyett (nem láttam hol van, utáltam begépelni, stb). Aztán idővel megtetszett, hogy nincs teleírva egy csomó, igazából hasznontalan, irmétlődő karakterrel a kód.
Az olyan kódoktól, mint a Python meg a YAML pedig egyenesen a hideg rázott, hogy dehát hogy? Nincs blokk eleje-vége kiírva! Nem látszik, ki-kivel van! Az első netplan konfignál szédültem az után a pár sor után, ami egy sima fix IPv4-hez kell.
Aztán elkeztem Python-ban egy script-et, mert BASH-ban nagyon durva lett (itt csatlakoznék is a "BASH nem való 50 sornál hosszabb programhoz" táborhoz), a PHP meg nem shell script-nek való igazán, és rájöttem, mekkora királyság az indentálással blokkosítani, és mennyire jól olvasható és tiszta így a kód...

Szerinem az, hogy egy nyelvet és az eszközt meg kell ismerni ahhoz, hogy jól használd, az eléggé alapvetés. Lehet C-ben is szép kódot írni (láttam) és Pascalban is csúnyát (szintén láttam). Az pedig, hogy valaki nem ismeri a nyelv eszközkészletét, illetve mennyire hajlandó azt megtanulni, az emberfüggő. Mint ahogy az is, hogy kinek melyik nyelv fekszik jobban.

Szerintem minden (legtöbb?) adatábrázolás esetén bele lehet futni abba, hogy van szeparátor, ami viszont szerepelhet az adatban is, tehát "védeni" kell. Erre a védelemre shellben 3 módszer is létezik - az, hogy vannak olyan emberek, akik nem szeretik megtanulni, hogy mikor melyik a jó / preferált - az nem a nyelv hibája - egyéb nyelv esetén is kell ilyesmit megtanulni.

Én amúgy eléggé meglepődtem, mikor akármilyen doksiban azt olvastam, hogy a Pythonban nem javasolt (tiltott?) a tabulátor használata - ami nekem azért kellemetlen, mert anno amikor tanulgattam az ámítógépet használni, akkor nekem valahogy az esett kézre az indentáláshoz, és nem az X db. szóköz. Az indent parancsot akkor még cb-nek hívták (C Beautifier) , és az se volt túl elterjedt - ezek a modern IDE-k meg még nem voltak fasorba se.

ja, és a nagy P-k közül (Perl, Python, PHP, PowerShell) melyikre lehet azt mondani, hogy multiplatform, szép, logikus, és nem fogod magad szopatni, ha azt használod? Ja, a Python helyből kiesik, mert ami Py2 -> Py3 kapcsán végbement, az azért eléggé ellentmond ennek.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

> Szerinem az, hogy egy nyelvet és az eszközt meg kell ismerni ahhoz, hogy jól használd, az eléggé alapvetés. Lehet C-ben is szép kódot írni (láttam) és Pascalban is csúnyát (szintén láttam). Az pedig, hogy valaki nem ismeri a nyelv eszközkészletét, illetve mennyire hajlandó azt megtanulni, az emberfüggő. Mint ahogy az is, hogy kinek melyik nyelv fekszik jobban.

> Szerintem minden (legtöbb?) adatábrázolás esetén bele lehet futni abba, hogy van szeparátor, ami viszont szerepelhet az adatban is, tehát "védeni" kell. Erre a védelemre shellben 3 módszer is létezik - az, hogy vannak olyan emberek, akik nem szeretik megtanulni, hogy mikor melyik a jó / preferált - az nem a nyelv hibája - egyéb nyelv esetén is kell ilyesmit megtanulni.

Azt azért ugye lehet, hogy bár én megtanultam ezeket a "triviáliákat" azért még továbbra is azt mondom, hogy ez komperatív a többiehez képest rossz, sokat kell ilyesmivel foglalkozni más nyelvekhez képest? És nem, nyilván nem tanultam meg mindet, mindig mély tisztelettel nézem, amikor ilyenekről beszélgettek, de mindig meg is állapítom magamban, hogy máshol viszonylag  "just works" dolgokon vakaróztok. És ez engem meg szokott erősíteni abban, hogy a megoldandó probléma helyett, a shellével foglalkoztok

Illetve a védelemre külön is: most azt hagyjuk is, hogy nagyszerű ez a három, de pont kettővel több, mint amennyit az ember szeretne, azért az egy elég lényeges különbség, hogy a shellben ezzel lépten-nyomon foglalkozni kell, mert a text alapú baszakodás miatt állandóan összekeveredik. Egy "rendes" nyelven az esetek igen jelentős részében az adatot a kód a határán kezeljük egyszer, és utána már nincs ezzel baj. Egy perles opendir eredménye sose fog megsértődni később, ha egy filenévben, amit paraméterként használnánk space van. Illetve sokkal ritkább az is, hogy mint a pipenál a program két darabja között serializálva kell adatot átadni.

Összehasonlításképp a másik hely, ahol ezzel rendszeresen gond van, az az sql, tele is van vele az internet, hogy hogyan ne csináld szarul, meg fedjük el mindenfélével.

> Én amúgy eléggé meglepődtem, mikor akármilyen doksiban azt olvastam, hogy a Pythonban nem javasolt (tiltott?) a tabulátor használata - ami nekem azért kellemetlen, mert anno amikor tanulgattam az ámítógépet használni, akkor nekem valahogy az esett kézre az indentáláshoz, és nem az X db. szóköz. Az indent parancsot akkor még cb-nek hívták (C Beautifier) , és az se volt túl elterjedt - ezek a modern IDE-k meg még nem voltak fasorba se.

Nem tiltott, csak ellenjavalt. Egy dolog tiltott (as in enforced) python3-ban, keverni a spaces és a tabos indent keverése, ami lássuk be, elég logikus ma már. És igen, pont az a mondás, hogy új kódba csak akkor írj tabot plz, ha konzisztensnek kell maradni a már meglevő, régi kódbázissal, mert annak idején valóban logikusabb volt a tab. (És egyébként hosszú hitvitákat lehet folytatni arról, hogy melyik a jobb, mindkettő mellett/ellen van valid érv, marad hitvitának)

> ja, és a nagy P-k közül (Perl, Python, PHP, PowerShell) melyikre lehet azt mondani, hogy multiplatform, szép, logikus, és nem fogod magad szopatni, ha azt használod?

Egyikkel sem, :D de azért szerintem legkevésbé a pythonnal. A PHP szerintem elég borzasztó (bár disclaimer, lehet, hogy sikerült megjavítani, nagyon rég néztem, de kétlem), a perl -- hát van, akinek tetszik, cserébe az objektum orientált része elég harmatos, a ps meg van unixra, ez elmondható róla, hogy aztán használni is lehet-e valamire, az kérdés :) Természetesen a pytonnak is megvannak a bajai jócskán, van a nyelvben is meg az stdlibben is egy rakás blődség.

> Ja, a Python helyből kiesik, mert ami Py2 -> Py3 kapcsán végbement, az azért eléggé ellentmond ennek.

A 2-3 átállás nem tudom, miért olyan nagy szopatás, mint aminek felfújják. Egyrészt jó soká tartott (túúl soká), másrészt az esetek igen jelentős részében nem volt akkora tragédia átállni, közben pedig ott volt a six, ha nagyon szeretted volna futtatni mindét platformon. De ha ez zavar, akkor perl, ott végül azt mondták, hogy a perl6 legyen inkább új nyelv.

Természetesen az interpreter verziózásból mindenhol van gond, de az interpretált nyelvek rákfenéje, pontosan ugyan így igaz a shellekre is. Ott se mindegy melyik bash vagy melyik ksh van alatta. És ha a py2->3 ellentmond ennek, akkor ha leveszed a szemüveged, észreveheted, hogy shellben a POSIX/nem POSIX, bashizm, kshizm, "ja, hogy busybox", meg a gawk, mawk, faszestudjawk és hasonlók is ugyanilyen szívás, nagy tételben.

... tavaly átírtam Python3-ra egy nagyobb lélegzetvételű kódhalmazt, amit még 2006 körül Python2-ben írtam. Egy nap alatt megvolt a lényegi része.
Gyakorlatilag 90%-ban print akármi --> print (akármi), továbbá xrange --> range meg pár apróság. De szép tempóval tudtam haladni.

Ha benne vagy, akkor azért nem az a pokol tornáca érzés átírni. Tény hogy ezeket át kell vezetni.
Az mondjuk szívás, ha olyan modult használtál (import akármi), amit Python2-ből nem portoltak át Python3-ra. Szerencsére itt nem volt ilyen.

Ennél nagyobb dolog, amikor a tempó miatt úgy döntök, hogy nem a klasszikus cPython-nal fogom futtatni a kódot, hanem a sokkal gyorsabb PyPy3-mal. Ez utóbbinál a legelső felmérés az, hogy mely modulok nincsenek PyPy3-ra portolva a cPython-os környezetből és kiváltható-e? Van olyan eset, amikor nem, tehát már itt hátra arc. Viszont ha nincs semmi extra, akkor simán futtatod cPython3-mal illetve PyPy3-mal is ugyanazt a kódot átírás nélkül.

De olyan is volt, hogy kevésnek tűnt a PyPy3 tempója is az adott feladathoz. Ebben az esetben fogtam a Python kódot és átdolgoztam Rust-ra. Ez melósabb volt, szerencsére kisebb kódhalmazt kellett átírnom és a moduloknak is volt megfelelője Rust-ban.

1. Lehet, hogy mindenkinek kisujjból kirázva megy itt a py2-py3 átállás, de azért ez elég sok szoftvernél a mai napig nem történt meg (FreeBSD portsban épp megy a takarítás, hát dobálnak ki dolgokat rendesen). Sőt rémlenek emlékek nagyobb cégekről, akiknek pl. a menedzsment eszközeik py2 alapúak voltak, és elég nehezen ment a továbblépés.

2. Ha viszont annyira überfasza az a python, akkor hogy a francban van, hogy két implementáció (vagy mi a fene is a hivatalos nevezéktan) közötti váltás esetén ilyesmibe bele lehet bukni, hogy nincs "portolva" egy modul? Már a C-kódoknál is az volt a helyzet, hogy ha értelmesen írtad meg, akkor nem okozott problémát a gcc - pcc - clang - lattice c - aztech c használata. Erre a nyelvre meg minden jót elmondanak, és erre kiderül, hogy itt is vannak implementációs problémák? Vagy éppen csak annyi, amit korábban már mondtam: ismerni kell az eszközt, hogy jól tudjuk használni?

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

1. hat en is sokaig rettegtem a py2->py3 atallastol, aztan egyszer ravettem magam es kiderult hogy egyaltalan nem veszes.

a print() es xrange es tarsai trivialis dolgokat a 2to3 tool megcsinalja, a space->tab egysegesitest is meg lehet oldani automatizalva, amivel en leginkabb kuzdottem az a stringek kezelesenek valtozasa (py2-ben az str tipus byte array es unicode is lehetett), de ezt szivesen atirtam mert a py2-ben agyrem volt, a py3-ban ezt letisztaztak vegre.

biztos van par olyan 3rd party modul amit nem portoltak, de azokat vszinu azert mert 5+ eve nem is fejlesztik. amit sokan hasznalnak azt azert reges reg portoltak mar...

2.-ra: nezd meg a php-t, ott alverzionkent is annyi inkompatibilitasi valtoztatas van (pl. php 5.2-5.3-5.6-7.0-7.1 kozott biztosan) hogy a legtobb webhostingon muszaj minden verziot futtatni parhuzamosan mert minden php app csak 1-2 adott verzioval mukodik.

Hát igen.

$ vim teszt.py

:set expandtab
:retab
:wq

Ennyi a tab -> space átalakítás.

PHP 5 --> PHP 7 ... na az is hasonló váltás volt, mint a Python2 -> Python3. "Hú de bonyolult, nincs időnk." Aztán amikor rászorítottuk a fejlesztőket, 1 délelőtt áttolták a mysql -> mysqli témát meg az ereg_replace -> preg_replace változást. Ezen kívül alig volt valami probléma. Szóval a "lehetetlen átdolgozni" végül 1 délelőtt volt.

Egyébként a többi nyelvnél is van "obsoleted" majd "removed" téma. Ebben a fiatal Rust sem kivétel. Itt a Cargo.toml-ben jelzett edition = "2015" vagy "2018" a te döntésed. A kettő funkcióhalmaza együtt nem megy.

Na, a PowerShellt azt tegyük el valahova jó messzire, mert agyf4sz.

Értem én, hogy csudijó, persze a DOS, alias cmd.exe után egy felüdülés, ezt aláírom, elvégre elég alacsonyan volt a mérce.

Nade van ugye az a dolog, hogy amikor az ember elkezd kódolni, akkor van egy "agyi állapota" az adott nyelvvel kapcsolatban, hogy hogyan absztrahálja a feladatot.

Ha bash -ban írok, akkor az if után tudom, hogy jön egy [ nevű program, aminek adok mindenféle paramétert. Ebben a nyelvben procedúrálisan gondolkodok, és bár tudom, hogy meg lehet erőszakolni OOP módra, de hülye azért nem vagyok, bash -ben az ember úgy ír programot mint kiskorában basic -ben, vagyis ebbe az irányba indul el az agyam.

C++ esetén viszont alap, hogy OOP, és ez máris eljesen más hozzáállást jelent a probléma megoldásához, ergo az agyam egy tök más irányba indul el.

Aztán PowerShellbe meg jön az if ( [system.string]$ldap.dataset.expected.userobj[$uid].sshPubKey minusz e kú ... nabazz, ez egy paraméter?! Ja, nem. De akkor a tökömért kell úgy csinálni mintha az lenne!

Lehet, hogy ettől a "kozmetikai" problémától csak nekem áll el a szőr a hátamon, de nekem nagyon.

Kár, hogy tényleg jól meg lehet vele oldani windowsos problémákat, mert szívesen kerülném ha lehetne, de muszáj használni, mert hasznos ez a ronda állat, fúj.

"Na, a PowerShellt azt tegyük el valahova jó messzire, mert agyf4sz." - egy ls -l kimenetét hányszor és hányféleképp kell szúrnöd mondjuk a fájlok dátumára és nevére? Hogy is néz ki az "ls" kimenetében a fájl dátuma? Ha azt nézem, hogy a shell-ben a mókolások jelentős része arra szolgál, hogy az egyik program kimenetét oylanra maszírozzuk, amilyen bemenetet vár a másik...
Oké, ps-ben jellemzően HosszúNevűCamelCase dolgokkal kell operálni, de ettől eltekintve nagyon sok dologban messze a shell scriptek előtt jár.
Ahogy sokszor írtam már: feladathoz az eszközt: nagyon sok esetben a ps a jó megoldás, más esetben meg a shell script, vagy épp a perl, php, python, akármi.

Tudom, hogy hasznos, de ronda! Zavarba ejtő! Minek kellett erőlteni a '-eq' -t az '==' helyett? A '-eq' egy kutya közönséges paraméter, ha egybeírod azzal ami előtte-mögötte van, már ki is nyírtad, ellentétben az '==' el, ami egy nyelvi elem, és egészen máshogyan működik. Miért kellett keverniük a szezont a fazonnal? Nekem csak ez a része fáj a PowerShellnek.

Az ls nem ronda, mert --time-style=long-iso azt jóccakát.

Linux alatt imádom, hogy egy csomó parancsnak vagy alig változik a kimenete az idők során, vagy van neki posix kapcsolója, pl. a df -nél ez tök hasznos. RHEL 6 -ról 7-re átálláskor egy igen nagy bash kódhalmazomtól tartottam, hogy esetleg gubanc lesz a teszt során, de kiderült, hogy csak a top -nak változott egy paramétere a memória kiiratásnál. Ezt az állandóságot, kiszámíthatóságot szeretem a linuxban, jó, nem mondom, hogy itt minden betonba van öntve, de azért érződik még a POSIX szelleme.

A (Free)BSD-s ls-nek -D és -T opciója van erre, ellenben a POSIX semmi hasonlót se ad és egyedül a POSIX locale-re írja elő a jól ismert hol-ilyen-hol-olyan időformátumot - egyéb locale esetén értelemszerűen az LC_TIME határozza meg..

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"Linux alatt imádom, hogy egy csomó parancsnak vagy alig változik a kimenete az idők során" - Amikor a RHEL5-ben lévő 32 bites "ls" binárist (annak minden tartozékával...) át kellett másolni a 64 bites RHEL6-os gépekre, mert egy adott kritikus alkalmazás egy "ls -KisSzékHóemberMatricaFiszF@sz " kimenetét olvasta fel, és  változott az ls paraméterezése és kimenete... Az de qrvajó volt...

Hát pont nem azért ;-) Régen volt, pontosan nem emlékszem, hogy milyen kapcsolósorozattal produkálták az alkalmazás által elvárt kimenetet, de az biztos, hogy RHEL6-ban adott group-nak a PATH-ban előrébb kellett szerepelni a /usr/local/bin/ -nek, hogy default-ban a régi ls-t kapják meg... Igaz azzal meg az volt a bajuk, hogy az IPA-s (sssd) uid/gid feloldására nem volt képes, úgyhogy user/group helyett csak a számokat látták...

Így gondolkodnak a pfSense fejlesztői is: Írjunk php-ben tűzfalat! Persze egy-két rendszer utilityt kell használniuk, mert különben a kernel is php lenne. ;)

Aztán boot után megette a macska az usereimet! Némi nyomozás után kiderül az oka: Hogy megvédjék a saját (mintával megjelölt) usereiket, újraírják a /etc/user-t. Ehhez meg olyan parancs kimenetét masszírozzák, amelynek elfelejtették elolvasni a man-ját.

Összefoglalva a kettős hibaokot:

  • Ok nélkül nem kell mindent a választott programozási eszközzel megvalósítani.
  • Külső program indítása előtt először ell kell olvasni a man-t.

Megoldás a problémádra:

  • Shell scriptben nem az ls-t használom, hanem egy pár soros C programot, ami saját maga forkolja a find-ot és hívja a stat()-ot. A végén egy printf() kiírja a kitalált formátumban a név, dátumok, méret, stb adatokat. Ezzel azt is megoldom, amit az ls nem, és sokkal gyorsabb.
  • A man szerint az ls dátuma pl. ilyen: 2021-01-04 21:51:41.453789467 - ehhez a --full-time, vagy a -l --time-style=iso opciók kellenek. (The TIME_STYLE argument can be full-iso, long-iso, iso, locale, or +FORMAT. FORMAT is interpreted like in date(1).) Ebből az látszik, hogy a dátumot még kiscica alakban is ki lehet íratni - némi man olvasás után.

Bizony, Hofi is megmondta: Pattintson egyet az ostorral ... ha kicsapja a szemét - akkor telefonközpontos.

"a shell meg a spacek..." Csak rutin kérdése. Ha érted amit leírtál, akkor természetesnek tűnik. Csak azt kell megjegyezni, hogy a shell először minden kifejezést felold és behelyettesít. Hanem ilyen lovat akartál, akkor meg kell védeni vagy jelölni kell a szándékodat. Erre nem születni kell - elég elolvasni. ;)

Ha abbahagynád az öntömjénezésről zengő hőseposzt... Csak azt próbáltam szemléltetni, hogy egy >1M paraméterrel dolgozó rendszer kicsit nagyobb feladat, mint néhány weboldal megszerkesztése. (Hátha más is olvassa. - Ahhoz, hogy megfelelő sebességgel működjön, nem az üres for ciklus futásidejéből indultam ki. :-D)

Szerinted "az interaktív shell csodálatos dolog", de nem erről van szó. Inkább default shellnek nevezném - persze attól még interaktív is, míg a powershell inkább scriptnyelv. Inkább régi keletű az a véleményem, hogy egy rendszeren a default shell a legjobban kidolgozott, hiszen a rendszer 70%-a is abban íródott. (*nix rendszereknél)

Az interaktivitás nem azt jelenti, hogy be tudsz írni parancsokat. Ki lehet egészíteni az environment-et változókkal és függvényekkel. Ezzel az adott rendszerhez specifikus interaktív környezeted lesz.

Találd már ki kérlek, hogy azt is mondtam, hogy egy shell scriptet nem lehet verziózni.

Itt. Persze nem azt állítottad, hogy nem lehet, hanem nem szokás. Kissé kavarodik a "nem értek hozzá/nem szeretem" és a "más/mindenki/általában szarul csinálja", ezért nem szereted. A kóklerekről meg lásd az első mondatot. Valami nem attól lesz szar, mert a kólerek azt hiszik, hogy tudjak használni.

Az unix shellekre nem mint programozási eszközre kell gondolni, hanem egy olyan eszközre, amin keresztül eléred az egész rendszer. Márpedig azt részben szövegfeldolgozó rendszernek találták ki, ezért minden megtalálható a feladathoz.

A heggesztés helyett heddzsesztést szerettem volna írni, de lusta voltam. ;) (Ez nem azonos a hegesztéssel. Higgyél nekem, van a fiókban egy gépészmérnöki diplomám. :-D)

Azzal egyetértek, hogy célszerű az elején, (már a PoC előtt) végiggondolni, hogy hova fajulhat a dolog, - én is jobban tettem volna, ha megfogadom a híres Bene Gesserit  mondást, miszerint: A kezdet kezdetén kell a leggondosabban ügyelni rá, hogy meglegyen a dolgok egyensúlya. 

Nade, a fene se figyelte. :-)

Igazából az a gond, hogy egy nem teljesen definiált projekt esetén az ember nem akar túl nagyot invesztálni, ezért azzal kezdi, ami a legkevesebb befektetést igényli, ÉS amit a belátható feladatra alkalmasnak vél. Én kis PoC -ot álmodtam, ha ez egy kis staikus oldal maradt volna, akkor most nem beszélgetnénk erről. A cég rendszereiben fut vagy 20-30, de lehet, hogy akár 50 különböző kis scriptem is, néhány sorostól a néhány oldalasig, ezek nem nőtték ki magukat, sokukról már meg is felejtkeztem, mert gond nélkül teszik a dolgukat.

Sok fejlesztésnél látom, hogy elkezdődik egy projekt valami igény mentén, majd ahogy halad a megvalósítás, megváltozik az igény. Ez egyébként nem feltétlen rossz, csak nyilván, problémát jelent ha túl merev volt az eredeti terv és macerás eltérni tőle, mert repedezni kezdenek a már felhúzott falak.

Nekem van egy állatorvosi ló projektem a cégnél. Erre egyrészt büszke vagyok, másrészt meg tényleg a világ vicce a dolog.

Ez egy monitorozó rendszer szerver oldala. Tudom, van ezernyi dobozos monitor rendszer, ki az a hülya aki nulláról fejleszt egyet, na, hát én. Erre több ok is volt, amelyek közül sok még máig valid, egyszer egy sör melett majd sírva röhögve mesélek róla, de leírni azért nem írom le. Na. :-)

Ez a kód 300+ kilobyte méretű. Ok, van benne komment is, de azért ez azzal együtt is sok. Viszont amit tud, hát az elég jó. A hibák álapotának követése, aktív webes GUI, high availability (feldolgozó node kiesés esetén hibatűrés, megléte esetén terhelésmegosztás), ismert hibák adatbázisa, automatikus kiértesítés, email és SMS csoportok kezelése, automatikusan több szálra skálázódó adatfeldolgozás, a koncepcióból adódóan kifejezetten jó jel/zaj arány előállítása, ismert probléma esetén a riasztás kikapcsolása, DoS védelem, és egyszerű bővíthetőség pluginokkal. Valamint egy automata teszt rendszerrel is rendelkezik az állapotgép teszteléséhez, szóval a core funkcionalitás bármilyen nem triviális módosítás után validálható.

Ezt 5 éve kezdtem írni, konkrétan nulláról. A beérkező adatokat bash scriptek küldték,és ennek az első feladata nem volt más, mint hogy aggregálja össze a beérkező üzeneteket, és ha gubanc van, akkor egy levélben küldje el az összes riasztást, és ne annyi levél jöjjön ahány riasztás történt, mint ahogy az előző rendszer tette. Ez is fél oldal kód volt cirka az elején, így hát sokáig nem volt gond azzal, hogy bash -ben írtam.

Most, 5 évvel később már más a helyzet. Ha tudtam volna, hogy ide jutunk, akkor eleve pythonban kezdem.

Két-három fordulópont volt amikor felmerült az átírása.

Első alkalommal, amikor már nehezen volt kezelhető a mérete az egyetlen forrás filenak, akkor felmerült, hogy átírom, de végül is úgy döntöttem, hogy egyszerűbb több filera szétszedni a jelenlegi kódot, és source -olni ami kell.

Másodjára amikor a bővíthetőség merült fel, illetve egy olyan funkció igénye merült fel, amire tudtam, hogy a bash nem alkalmas. De akkor meg megoldottam a godiuszi csomót azzal, hogy pluginokkal tettem bővíthetővé, mondván, hogy ha kell a nehéz funkció, akkor oda be lehet dobni akármilyen nyelven megírt scriptet is, és máris nem kell nulláról kezdeni a dolgot.

Harmadjára amikor performancia gondom volt, de ekkor jött az ötlet, hogy több szálon dolgozzam fel a beérkező trágyát, és ez szépen megolotta a dolgot.

Most olyan számomra ez a rendszer, mint a Win7 a MS számára. Szeretne tőle szabadulni, mert nem jó irány, viszont olyan kiválóra sikerült már az évek során, hogy nem tudja elengedni, és időnként még kiad rá egy kis javítást. Én a két ünnep között foltoztam be egy hibát, és tettem egy kicsit robosztusabbá egyes részeit, de nagy alapvető fejlesztést már nem szívesen tennék benne. Plugint bármikor lehet beletenni, az nem probléma, de az alapvető dolgokat nagyon nehezen lehetne benne megváltoztatni, mert a kódjában sok olyan dirty egymásra támaszkodás van, amit nem jó piszkálni. 

Például, bash-ben elfogadott dolog, hogy fogok egy szöveges állománt, tr -el lecserélem a sorvége karaktereket mondjuk aláhúzásra, aztán mint string átadom egy másik parancsnak ami nem szereti a több soros bemenetet, nade visszafele az rárak egy sorvégét, ami miatt a tr amikor az utolsó aláhúzás jelet is visszalakítja sorvégére, akkor egyel több sorból fog állni a file. Ilyen baromság egy "normális" programnyelvben fel sem merül, mert nincs szükség ilyen grep | cut | awk | tr | sajatfuggveny | grep | tr | akármi csatakígyókra.

Ezt az ember valamikor valamiért ilyen gányul csinálta, és két modul így kommunikál, és jó lenne megszüntetni, mert nem elegáns, de aztán sosincs rá idő. És a kód nagyjából jó is, csak az a plusz enter a végén, és annak a workaround -je, na az egy rohadt taposóakna. Én ezt látom a bash nyelven történő programozás buktatójának, hogy nagyon könnyű ilyen egyszerű és hasznos, ámde "nem elegáns" kódot írni benne, amit jóval nehezebb emiatt karbantartani, mintha sima python lett volna, ami a saját eszközkészletében nem "sugallja" az efféle mellékhatásokkal járó megoldásokat.

Én is kaptam már örökölt bash kódot, mondván, hogy javítsam meg, - hát, inkább újraírtam, mert tele volt varázslásokkal, elenben mondjuk a logolás (ami nekem a személyi fétisem, hogy mindenem ír valamilyen szintű trace logot) na az nem volt benne, mert majd elhisszük, hogy minden úgy van ahogy reméljük. Hát nem. :-)

A bash hibakezelés elég trükkös tud lenni. Más nyelvek ezt sokkal szebben megvalósítják. Ez a hiányosság főleg akkor jön ki, amikor megváltozik a környezet. Nálam a következő történt. Volt egy load balancer elenőrzés, ahol vagy nem válaszolt a gép, vagy azt mondta, hogy "200 OK" vagy egy sorban röviden elmondta, hogy mi a kínja. Ezért a mérésben, hiba esetén én megjelenítettem, hogy mit mondott, hogy segítsem azt aki kijavítja a hibát. Ez sokáig jó is volt, majd egyszer egy deploy után válaszként kaptam egy jó kövér weblab komplett HTML forrását. Egy kicsit megrogyasztotta a dolgaimat, na. Nem erre készültem, a cut/awk nameg a regexp keresések egy kicsit nehezményezték a dolgot. Oké, más nyelven is megüti az ember a bokáját, ha nem ellenőrzi az inputot, de azért itt van egy nagyon nagy különbség!

Bash -ben olyan kicsi dolgokat írunk, többnyire "saját magunknak", ahol nincs rendes input ellenőrzés, mert tudjuk, hogy nagyjából mi jöhet be. Tipikus példa a for file in $(ls -1 /data/import); do

Aha, és ha megcsúszott az a script ami oda teszi a fileokat, és legenerált neked egymillió darab üres akármit? Akkor szívás van! De ilyenre az ember nem gondol amikor bash-an egy 5 soros vackot ír, ami bizonyos fileokat mondjuk scp -ve átlök valahova.

Egy komolyabb programnyelvben, egy komolyabb problémakört megoldva az ember hajlamosabb belerakni azokat  vizsgálatokat mitől stabilabb lesz a program.

De amikor egy bash kód kinövi magát, akkor egy belső workaroundoktól, és nem kezelt lehetőségektől, vagyis potenciális hibáktól hemzsegő kód fog hirtelen nagyon fontos munkát végezni.

Én ezt látom a legnagyobb problémának.

Szvsz a shell szkriptek első közelítésben inkább csak arra valók -- s emiatt nyugodtan vessetek a mókusok elé! --, hogy a feladat megoldását (megoldható voltát) bizonyíthassuk vele. A kód jobbá tétele (memória hatékonyság ill. sebesség növelés), a helyesen működő szkript egyes részeinek -- vagy a teljes szkriptnek -- az átírást jelentheti második lépésnként, valami hatékonyabb eszköz használatával (pl. Python, Perl, C, C++, s.í.t.).

"Share what you know. Learn what you don't."

Persze ebből adódóan nem kell teszt se...

 Nos, a nagyobbik förmedvényemen (300+ kilobyte bash kód) az automata teszt kicsit több mint két órát fut, mert élveboncolja benne az állapotgépet. :-)

Azt már csak halkan jegyzem meg, hogy az automata tesztet is bash -ban írtam, mert hát... Izé... $(max=$(cat kifogas.txt | wc -l); cat -n kifogas.txt | grep -E "^$( ((1+RANDOM%max)) ) " ) igaz?

Nem-nem! Ez élveboncolás!

A szerver oldal 5 percenként fut le, ezért a teszt program 5 percenként elhelyez egy teszt üzenetet, aztán megnézi, hogy mit lépett rá a feldolgozás, oda tette-e ahova kell. Ez nem szintetikus teszt, hanem a valós futó kód tevékenységét elenőrzi, illetve az 5 perces feldolgozások közötti állapotok helyes megtartását, illetve az állapot módosítások eredményét.

Ez lassabb ugyan, de legalább tutira a valóságot méri. :-)

Igen, nem. :-)

Valóban nincsenek unit tesztjeim, mivel hagyományos értelemben vett unitjaim sincsenek. A pluginek lehetnének unitok, de azok meg egy kivétellel olyan egyszerűek, hogy szerintem egyikkel sem volt gond miután elkészültek. A több plugin együttes futásakor már volt, hogy lábon lőttem magam, de azt meg már csak integrációs teszteléssel lehetett volna megfogni, ami messzire vezet.

Én erősen a szeretem a defenzív kódot, mert gyakran van olyan, hogy az egyedi környezet miatt az éles rendszeren kell fejlesztenem.
Tudom, ez elenjavalt, meg ne így csináljam, de ilyen az élet.

Erre nekem az az egyik megoldásom, hogy kirakom azt a kurva else ágat akkor is, ha nincs értelme, és belerakok egy trace logot, hogy na most estünk pofára. Egyébként is sokat logolok, mert a kicsit is nem triiális helyeken kiírom, hogy mi alapján döntött úgy a program ahogy. Ez hibakereséskor baromi jól jön.

Most direkt megnéztem, egy session 34k log írással jár, egy nap cirka 10 MB. A log struktúrált, követhető, hogy ki-kivel van, nem csak belehányom ami éppen jön. 10 napnyi logot tartok meg, a régebbi automatikusan törlődik. Így elpazarlok a lemezből cirka 100 MB-ot, de több mint egy hétre vissza lehet ciklikusságot vizsgálni a logokban.

Van olyan rész amit érdemes tesztelni, és van olyan amit nem. Nálam az állapotgép az ami nem triviális, sok mindentől függ az állapottere, és a "csillag-hold együttállások" esetén kijövő hibás döntéseket nehéz kihozni, pont a ritkaságuk miatt. Az automata teszt erre való, hogy végigzongorázza az összes kombinációt, így meg tudja fogni a regressziót. A többi rész tesztelése fejlesztés közben történik.

Szerencsére ez a kód nincs kitéve hülye felhasználóknak meg internetes baszkurálásnak, a bemenetekről szeretném azt hinni, hogy megbízható forrásból származik, lévén a 90% -át én állítom elő egy másik programmal. Volt és lesz is benne persze hiba, de több idő lenne mindenre is tesztet írni, mint időnként kijavítani, vagy felkészíteni valami új dologra amikor megváltozik a környezet.

"Erre nekem az az egyik megoldásom, hogy kirakom azt a kurva else ágat akkor is, ha nincs értelme, és belerakok egy trace logot, hogy na most estünk pofára."

Ott a pont. Erre szerintem bucko kollégának is lenne egy 1000+ alkalommal elsütött sztorija - igaz, ott ha jól emlékszem pont az összes hibaág volt kész, és a "minden hibátlan" ág hiányzott, és úgy működött a cucc hosszú ideig, mert soha nem kapott úgy inputokat, hogy a "minden jó" ágra futott volna :-)

Azért az erős túlzás, hogyha egy elágazás "szembe jön", akkor a bash már alkalmatlan - nem ezen múlik ugyanis.

Ontopic: láttam én olyat, hogy könyvtár tartalmát kellett szépen formázva/szűrve megjeleníteni egy webes felületen, elvárás volt, hogy php legyen. Kolléga megírta a parancssorokat, majd exec()-kel telef0sta a php-scriptet (gyakorlatilag egy rakat exec() volt a scriptje)... És csodálkozott, hogy nem tetszett a "megoldása".

( kantal | 2021. 01. 06., sze – 14:52 )

Már több, mint száz hozzászólás; az elolvasásukra fordított idő alatt már talán át is lehetett volna írni Pythonba a szkriptet:-)

eutlantis