Üzemeltetőként feladataimhoz leginkább ... -t használok scriptezési/programozási feladatokra

Egyéb

Üzemeltetőként/rendszergazdaként (nem fejlesztőként), operációs rendszerekhez, alkalmazásokhoz, adatbázisokhoz, szolgáltatásokhoz, amolyan ragasztóeszközként leggyakrabban használt (script)nyelvem.

( n.balazs v | 2024. 09. 16., h – 13:48 )

Szerkesztve: 2024. 09. 16., h – 13:51

(x) Egyéb, leírom, mert többféle rendszerrel is szoktam dolgozni

Unix / Linux: Bash / Ksh
Windows: Powershell / batch (bár ez utóbbit nagyon ritkán)

Ha rendes automatizáció kell, akkor pedig Ansible.

Ha pedig egy adott termékről van szó, aminek saját nyelve van, akkor azt használom.

( trey | 2024. 09. 16., h – 14:23 )

Hiányolom az "emberem van rá" opciót.

trey @ gépház

( DirtY_iCE | 2024. 09. 16., h – 14:38 )

Bash, amig el nem erem azt a szintet amit shellben megirni nagyon maceras/lehetetlen, mert akkor ruby. Bar az mar sokszor inkabb fejlesztes mint rendszergazdaskodas.

I hate myself, because I'm not open-source.

( YleGreg | 2024. 09. 16., h – 15:40 )

A bash azért jó, mert aki tud linuxul, az tud bashul.

Lehet, hogy nem perfektül beszéli, de ha megtanulja a for -t és az if -et, akkor már mindenre is képessé válik vele. :-)

És az ilyenekből lesznek azok a több oldalas scriptek, amit hozzáértő 15 perc böngészéssel simán lerövidít fél oldalasra. (Kevencem volt egy banki valami, amit az egyik scripting tanfolyamra hoztak a kedves hallgatók, és mint kiderült sok éve használják nagy megelégedéssel. Igaz, valahol az első oldalon volt egy soha nem teljesülő feltétel, amihez viszont 3 oldal kód tartozott :-) )

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

Egyszer elég jó helyerzést érem el az IT megmérettetésen, ráadásul a két témakör közül az egyikhez nem is értettem. Automatikusan felmerül a kérdés, hogy mihez értett a többi? :-D Éppen emiatt többé nem indultam.

Állítólag valódi cégek állították össze a feladatsort. No, ott voltak olyan scriptek, hogy az írójának kapcsiból eltöröm a kezét! Pedig semmi szószátyárság, jól működött a logika is, de asszem assemblerben is egyszerűbben fogalmaztam volna.

Nem ilyenekből lesznek, hiszen bármilyen nyelven lehet halott kódot írni, én konkrétan egy Windowsos C# projekten dobtam ki egyszer a forrás kétharmadát, azonos funkcionalitás mellett. Szóval ennek a jelenségnek nincs köze a bash-hoz.

Ha a nem szakértő által írt kód minőségre céloztál, akkor elfelejted, hogy mindenki kezdőként kezdi.

A bash pont ezért jó, mert rettentő könnyen tanulható, és az egyszerű problémákat nagyon szépen meg lehet benne oldani, ráadásul elegánsan, jól olvashatóan, és megfelelő performanciával.

Az persze egy tipikus dolog, hogy az eredeti egyszerű probléma/feladat az évek alatt megváltozik és egy rettentő komplex elvárás-halmazzá változik, amit a bash megoldás ugyan szépen (vagy slendriánul) követ, de ezzel együtt elburjánzik.

Ilyenkor szokás úgy refaktorálni a bash kódot, hogy átírják pythonba. :-)

Neha belefutok abba, hogy egy olyan ember kodjait kell lekovetnem, aki nalam sokkal melyebben erti a linux mukodeset. Emiatt olyan nem trivialis es nem mainstream megoldasokat hasznal, hogy csak pislogok. Nem is annyira az idegen, ismeretlen parancsok a kerdesesek (az egy man vagy google es kesz) hanem a program gondolatisaga, az adott problemara kitalalt megoldasi terv az ami neha nagyon furmanyos, mert olyan dolgokra epit, amiket manapsag nem szoktunk hasznalni.

De igazabol elvezem, mert mindig tanulok belole, szoval ez nem hatrany, csak fura. 

Ugyan nem a kérdésedre válasz, de láttam scriptben olyan megoldást, hogy egy timeout így volt definiálva:

timeout='###########################'

Majd a scriptben tizedmásodpercenként lenyírtak egy karaktert belőle - például a második karaktertől a végéig lévő részstringet vették -, és akkor telt le a timeout, amikor a string üressé vált. Ötletes, mert nem egy szám, hanem egy szemléletes, a kódban is hosszként megjelenő bitkolbász lett a timeout kifejezője, ráadásul azt nem is konvertálták számmá egy hossz függvénnyel, hanem meghagyták annak eredeti alakjában.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tényleg szép megoldás. Kár, hogy az a "tizedmásodpercenként lenyír" rohadtul környezetfüggő. szóval objektíven kb arra jó, hogy valamennyit várjanak. Függ a gép teljesítményétől, az aktuális terheléstől, a használt parancsértelmezőtől, sőt még attól is, hogy azt a bizonyos "levágást" milyen módon csinálod. Nem egy igazán definit időzítés.

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

Ennel otletesebb idozitest iGO-bol ismerek.

Nehany kutyun navigaciokor a hangos bemondas tul keson tortenne (vagy tul koran, nem emlekszem mar), ezt lehet egy configfile parameterevel allitani, hogy hany masodperccel legyen korabban. Aztan valaki kitalalta, hogy ez nem igazan jo, mert igy nem lehet masodperc ala menni vagy pontosabban idoziteni, ugyhogy atirta millisec-re (igy 500ms vagy 1500ms is lehetseges). A kompatibilitas jegyeben persze megtartotta a korabbi mukodest: szoval adott threshold felett millisec-kent ertelmezi ugyanazt az intet, alatta meg masodperckent. Ez a threshold ertek pedig - hogy a zsenialitasa soha ne menjen feledesbe - verziorol verziora valtozik. Talan meg olyan is van, ahol ugyanazt az erteket Androidon a native C++ kod es a Java kod is olvassa, es eltero kuszobbel ertelmezi.

Ilyen stringhosszal aranyos megkozelites meg neki sem jutott eszebe. Like!

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

Annyira a mikrokontrollerek világa felől jövök, hogy legtöbb esetben kényszeresn optimalizálok, szóval ezt a stringhossz megoldást memória- és futásidő-pazarlónak érzem, de van zamata, meg kell hagyni. PC-n már lényegtelen, elhanyagolható a költsége.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kicsit off, de a csik hosszarol meg az idozitesrol eszembe jutott egy anekdota, talan van, akinek ujdonsag lesz.

Regen sok papir alapu kerdoiv volt, par ceg ezekkel - es a kiertekelesevel - foglalkozott. A tortenetunk szereploi meg ezeknek a cegeknek irt programot. Ha jol emlekszem ilyen kerdoivet tudott generalni, es - ami fontosabb - feldolgozni. Volt egy scanner, azzal beolvasta a kerdoives papirt, aztan a papiron elhelyezett plusz jelek alapjan feldolgozta, es eltette valahova. A feldolgozas kozben - ahogy az kell - kitett egy progress bart a kepernyore.

Aztan rajottek, hogy a scanner mechanikaja lassabb, es feleslegesen lassitjak a dolgot a feldolgozassal: az adatokat streamelve scanneles kozben meg tudja oldani a rakotott PC a feldolgozast, ugyhogy ez - a progress barral egyutt - megszunt. Ennek persze nagyon orultek az ugyfelek - egyet kiveve. Ok panaszkodtak, hogy "nem megy a feldolgozas". Nem megy? Megkapjuk az adatot, de nincs progress bar, szoval nem megy!

Nem volt mit tenni, ennek az ugyfelnek letrehoztak egy kulon valtozatot: az uj architektura maradt, de utana kitett egy progress bart, ahol egy timer szamolta a masodperceket, es igy "mar mukodott a feldolgozas" is.

Kesobb ugyanez az ugyfel ujra jelentkezett: vettek egy joval gyorsabb gepet, es panaszkodtak, hogy a feldolgozas ugyanolyan lassu maradt, ugyhogy - gondolom jo penzert - lecsokkentettek a "######" jelek szamat. :)

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

Például ki gondol bash scriptben destruktor funkcionalitásra?

Ha valami gebasz van, az ember ugyan takarít maga után egy megfelelő if után, de mi van, ha nyekken a script?

én így tanultam meg a trap parancsot, ami remek megoldás arra, hogy nem várt hibák esetén is tehessünk dolgokat, például takarítsunk magunk után.

Egy másik érdekesség amikor volt egy script, amiben egy paraméter attól függött, hogy mi a script neve. Ez így elég idiótán hangzik, de mivel volt egy csomó symlink ami erre a scriptre mutatott, máris a symlink file neve vált a paraméter értékévé, anélkül, hogy át kellett volna adni egy paramétert, vagy hogy duplikálni kellett volna a kódot.

Linux ad-hoc telepítő készítés, egy bash kód aminek az utolsó sora egy fix string, a kód pedig a string mögötti hexa szemetet, ami egy tömörített tar file, kinyitja és oda teszi ahova kell, plusz előtte-utána parancsokat hajt végre. Lehetne két file is, de ez így kompaktabb.

Illetve van egy szintén ritkán használt módszer, amit én is szeretek, hogy van egy gép ahova egy kulccsal kéne bemenni, de root -ként, viszont aggódok, hogy mi van, ha megszerzik a privát kulcsot (mondjuk mentésből) aminek ugye nincs jelszava (mert automata használja), és ezzel root jogot nyernek a szerveren?

Ebben az esetben az a root kulcshooz tartozó sorba a kulcs előtt megadom shellként azt a parancsot amit az automata futtatgat, és kalap kabát, ha valaki megszerzi a privát kulcsot, akkor sem tud mást tenni, mint amit szabad. Tudom, van erre más mód is, de minden megoldásnak megvannak a maga előnyei és hátrányai, ez pedig egy elég minimalista megoldás, ami szerintem jó irány. Ez annyira nem szokványos, hogy egy-két éve talán valami balfasz feldobta security hole -nak, hogy az sshd végrehajtja azt, ami a kulcs elé van írva... Valószínűleg nem tudta, hogy ez direkt van. :-) 

Egyedi megoldásokról jut eszembe, egy időben úgy csináltam saját live Linuxot, hogy az ugyanazon pendrive-on lévő adat filerendszer nem szerepelt a partíciós táblában, nemes egyszerűséggel egy offsettel fel tudtam mount-olni az fs-t. :) Ez így jó volt, mert új image esetén csak az image-et kellett a pendrive-ra másolnom, az adatok maradtak a senki földjére tett fs-en.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azt kell mondjam, hogy megnyugodtam, eléggé vén vagyok ahhoz, hogy ezek nekem ne legyenek újdonságok vagy különlegességek :)

Van egy lowercase nevű szkriptem, amelyre uppercase néven van szoftlink. A szoftlink 2008. március 21-én készült :) Maga a szkript 2014. január 25-én módosult legutóbb :)

Az utolsóhoz annyit, hogy "man authorized_keys", és láthatod, hogy egy csomó mindent meg lehet adni egy kulcshoz, nem csak "command"-ot. A 2009-ben írt könyvemben is megemlékeztem (a 40. oldalon) az ssh kulcsok korlátozási lehetőségeiről :)

Mondok én is egy példát, amit ritkán szoktam látni használni, pedig - szerintem - mindenki gépén ott van, tekintve, hogy az util-linux csomag része (Debian alatt legalábbis): flock.

( Nyosigomboc v | 2024. 09. 16., h – 15:44 )

Nem vagyok uzemelteto, de csinalok ilyet is (pl. a sajat gepemen).

Alapvetoen ami egyszerubb, arra bash, ami bonyolultabb, arra Python.

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

( asch v | 2024. 09. 16., h – 17:55 )

Én a szkripteket is Javában írom. Ha a változó behelyettesítésnél több logika kell, akkor Java. Még sose nem bántam meg, az legalább működik és értelmes szemantikája van. Hogy mennyit fogyaszt az meg tökmindegy. Ha nem lenne mindegy, akkor pláne Javában írnám, gyorsabb mint a szkriptnyelvek!

Egyszer gondoltam egyet, hogy mégis Bash-ezek, mert mindek ide Java. Mikor párhuzamosan akartam futtatni taszkokat úgy, hogy eseményvezérelten amikor vége a taszknak induljon a következő, de legyen timeout is: akkor mondtam, hogy jó, inkább maradok a Javánál, mert mire ezt kiguglizom, addigra lemegy a hajam.

Másszor meg volt egy grep-pel megvalósított logfeldolgozásom. Az eredetit is én követtem el, de nem volt elég hatékony. XML logokból kellett kivenni az oxigént, de sok volt és mind jó nagy. Aztán rájöttem, hogy a lényeg mindig az elején van a fájloknak, megírtam Javában, hogy csak addig olvassa ameddig megvan amit akar (és antipattern módon Exceptiönnel hagytam el a süllyedő hajót, mert a SAX API-n nincs lehetőség félbehagyni az olvasást), és sokszorosa lett a sebesség. És mellesleg korrekt szemantikus XML elemzés lett grep helyett, ami korrektebb is. Nyilván ezt is lehet valahogy parancssori toolokkal, de Javában triviális volt nekem, Bash-ben meg ez is fogós kérdés lett volna.

Az XML-re nyilván az a jó megoldás, a background task-ra nem kell Google, kitalálható. Például kiírod file-ba a PID-jét a background task-nak, befejezéskor törlöd, vagy pgrep-pel keresel a nevére, vagy mindkettő, szóval meg lehet ezt csinálni Goggle nélkül is, ha nem valami előregyártott vackot keresel.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az XML-re nyilván az a jó megoldás

Hát, arra pont van xmlstarlet, amivel viszonylag kultúráltan lehet xmlt feldolgozni (már amennyire ez a szó értelmezhető az xml kontextusában). Az más kérdés, hogy valószínűleg pont az említett dolgot, hogy hagyja abba a feldolgozást ~első találatnál nem biztos, hogy ki lehet belőle csavarni, de ilyen xpathos matatásokra jó. Ellenben ...

Például kiírod file-ba a PID-jét a background task-nak, befejezéskor törlöd, vagy pgrep-pel keresel a nevére, vagy mindkettő, szóval meg lehet ezt csinálni Goggle nélkül is, ha nem valami előregyártott vackot keresel.

normális párhuzamosítást csinálni rohadtul nem triviális, messze sokkal több ennél, mint amit írsz. És nyilván a lehet szopni google meg doksi olvasás nélkül is, de minek? Úgy is elég masszív összerakni egy ilyet alapoktól, ha nincs különösebb oka, teljesen jók az "előre gyártott vackok", mint az eredeti problémánál n-szer hosszabban írni futtató keretrendszert, ami a végére csak 48 corner caseben fog szarabbul működni, mint a konzerv.. Az más kérdés, hogy itt viszont a konkrét példát valószínűleg a parallel (kvázi a cli előre gyártott vacak) pont megoldotta volna :)

grep -m X ahol az X jelenti, hogy hanyadik talalatnal hagyja abba a file olvasasat.

Bash -ban irtam HA es terheleselosztasos cuccot ket szerverre, mindegyik tobb szalon dolgozik, gebasz esetwn atveszik a melot egymastol. Evek ota hiba nelkul mukodik, neha jon az SMS, hogy HA esemeny tortent, ugyhogy tenyleg mukodik, eddig megmentette a seggemet az adatvesztestol. :-)

( zeller | 2024. 09. 16., h – 18:22 )

Kár, hogy olyan válasz nincs, hogy "így, ebben a sorrendben..." :-D Bár Ruby-ban biztosan kevesebb scriptet követtem el, mint PowerShell-ben - GO-t meg csak játszottam korábban, az Ansible-huszároktól meg elég konnyű heveny lábrázást kapni...

( Vamp | 2024. 09. 16., h – 20:30 )

Szerkesztve: 2024. 09. 16., h – 20:56

windowsban powershell (foleg AD query) Linux alatt bash, ujabban Ansible/Salt.

 

Joparszor elhataroztam h megtanulom a pythont de annyira meg soha nem volt ra szukseg uzemeltetesben, h nekiveselkedjek.

( locsemege v | 2024. 09. 16., h – 22:28 )

A fejlesztőket miért zártad ki? Nem szereted őket?

Egyébként awk és bash.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Átfogalmazom. Van egy rakás olyan pillanat, amikro egy nagy, C-ben írt táblázathoz hozzá kell nyúlni automatizáltan. Ez nem üzemeltetés, de scriptelés, jellemzően színtisztán awk. Vagy valamilyen segédprogramot kell írni, amelyik egy adott szabály alapján generál egy táblázatot.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Beagyazott eszkozoknel C meg ASM forrasba eleg gyakran kerul valami elore kiszamolt tablazat - mint azt gondolom tudod, csak trollkodsz.

Pl. egyik ismerosom egy keveropultot javitott, de nem talalt megfelelo meretu es karakterisztikaju potmetereket. A gyariban volt logaritmikusnak nevezett poti, meg ami az egyik oldalrol a masikra kevert at valami fura gorbe alapjan, plusz ugye voltak normalis linearisak is. Viszont a kutyu dobozan a vagas kisebb volt, mint a beszerzett/kaphato potik, szoval itt sem volt jo 1:1-ben. Azt talalta ki, hogy egy PIC-cel meri a poti helyzetet, es a kivant karakterisztikat egy digitalis potmeterrel oldja meg. Nem valami jo matekbol, azon szenvedett, hogy hogy oldja meg a 8 bites mikrokontrolleren a szamolast minel pontosabban. Vegul kicsit segitettem neki, kapott egy par soros python scriptet, ami a megfelelo fuggvenyeket kitette neki egy tablazatba - 256 szam ugye - soronkent asszem 16 hexa ertekkel, az elejen meg a db mnemoniccal (a vegen talan automatikus komment is volt, hogy melyik tartomany az adott sor). Meg ki is rajzolta matplotlibbel, hogy melyik tablazat hogy fog viselkedni. A tablazatot mar egyszeruen megcimezte az ADC eredmenyevel, es a kapott szamot elkuldte a digitalis potinak.

Ha trigonometrikus fuggvenyek kellenek, azt is gyakran oldjak meg hasonloan, tablazatbol.

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

Nem, ez nem trollkodás, hanem nyelvtannácizmus. ;) A táblázat létező fogalom, ami az adat(összefüggés)ábrázolás egyik módja. Mint olyan, általában nyelvüggetlen, tehát "C táblázat" nem létezik. Legfeljebb egy adott táblázat elemeinek ábrázolása C szintaxis szerint.

Úgy jártál mint a pongyola IT-s, mert neki az adatbázis mindig relációs adatbáziskezelő rendszert jelent. Mutatom a példát: Felhívott a haver haverja fejvadász, hogy szükség lenne rám egy projektben. Megkértem írja körül. Na, mondom ez X cég és Oracle DB - ott ezt szeretik, de nem értek hozzá. Dehát ott van az önéletrajzomban, hogy milyen sok adattal és adatbázissal dolgoztam...

Pedig az alábbi is adatbázis/vektor/táblázat. Egy rittyentéssel be lehet tölteni pl. BerkeleyDB-be (key-value típusú adatbázis), vagy egy kulcs táblázat birtokában némi pfozgatás után 4-5 Oraclae DB táblába. Én meg egy C-ben írt toolkit segítségével ksh/bash scriptből használom. Néha C-ből is. Tehát az adat nem nyelvspecifikus!

a|1
B|3
c.x|2:4:6
d.y|alma:körte

Jó neked, ha nincs olyanod, hogy egyetlen file csak egy konstans táblázat, egy struktúra tömb, amelynek van tagja, amely egy újabb tömb, amelynek egy másik típusú struktúra az elemei.

Ha egy ilyenbe bele kell javítani, mondjuk mind a kb. 112 elembe be kell szúrni még egy sort, akkor nem nagyon van kedved kézzel csinálni, mert lemegy a Nap, mire elkészülsz, és egészen biztos, hogy még el is rontod.

Ilyenkor szoktem egy awk scripttel hozzányúlni.
 

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Bizony, mindenki másképp csinálja. Ismerek néhány embert, aki C# programmal sql-be töltené, mert annak van adatbázis interfésze, meg a Json (Statham) is megy neki. :-D Egy öreg matematikus szerint az awk egy szuper tool, mert az sql-hez képest képes vagy az indexet is adatként kezelni.

Egy algoritmust gyakran awk-ban tesztelek, majd beemelem az asm forrásba és átírom. Hasonlóan pl. FIR filtert generálom egy programmal, tesztelem, majd három makróval asm kódot  generálok belőle.

Értelek. Ha automatizlás, vagy ilyen segédprogramos terület, az nekem ugyanaz (mint amit kérdezni szerettem volna). Lehet, hogy szerencsésebb lett volna úgy fogalmaznom, hogy üzemeltetési feladatra, ragasztóeszközként ... -t használok. Attól te még lehetsz fejlesztő pl, aki egyébként épp most csak szkriptet ír két szoftver közé.

Igen, tehát fejlesztés közben is van rengeteg ragtapaszolás, ideiglenes mókolás, munkát megkönnyítő scriptelés.

Tehát bash, awk, calc. Az utóbbit az előbb lefelejtettem. Ez nem a LO Calc, hanem a konzolos cucc, amelyik helyből tudja a komplex aritmetikát.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( bazso | 2024. 09. 16., h – 22:38 )

English. Minden másra ott a ChatGPT ;)

Amúgy amit a feladat megkövetel, ha nincs kötöttség, akkor egyszerű esetben Shell szkript, bonyolultabb esetben Python.

( Raynes v | 2024. 09. 17., k – 00:27 )

Szerkesztve: 2024. 09. 17., k – 00:30

Nem vagyok üzemeltető, de saját rendszereimen általában POSIX shell a fő szkriptelési eszköz (Linux alatt dash-t, BSD-ken ksh-t használok ehhez). Ritkábban Bash (ha kell valami hasznos extra funkcióhoz, ami Bash specifikus), Python és Perl, még ritkábban calc script, de azt csak matekozáshoz (Pythont is csak ahhoz használom, Numpy és Sympy miatt), illetve Lua. Nagyon kicsit, távolról ugatom az awk-ot és Octave-ot is.

Régen, míg belső webes rendszert kalapáltam, akkor PHP és Perl, de az se üzemeltetés volt. Windowson míg azt használtam, anno, azon Batch ment, meg egy kis AutoHotKey szkript, sőt, egy kis VBS is ment még XP-n.

Mondjuk, aki üzemeltet, és nem szkriptel, az nem tudom hogy csinálja. Én nem tudok olyan üzemeltetést elképzelni, hogy legalább egy systemd service-t vagy cron jobot, vagy valami rc service-t nem kell hegeszteni, vagy valami karbantartást, vagy gyakran ismétlődő feladatsort beszkriptelni.

Nem üzemeltetőként a saját rendszereimen is szinte minden script. Már mikor indul a rendszer Linuxon, ott a systemd-boot config fájlja lényegében egy script, több include-olt elemből, aztán saját systemd service is indít saját szkriptet, ha ez lefutott, akkor loginkor a rendszer futtatja a ~/.bashrc-t, az is egy script, ami ha megfelelő tty-okon belépést észlel, egyben login managerként is működik, és indítja automatikusan az adott tty-hoz tartozó wm-et indító xinit-szriptet startx-szel, ami szintén egy shell script, ami tölti az ablakkezelőt (bspwm), aminek a konfigja szintén shell script, és a használt programjaimnak a nagyja is saját script, frissítés, AUR-os csomagok frissítése, jelszókezelés, különböző formátumokba konvertálás, tömörítés, dokumentumok gyors megnyitása fzf-fel, nyomtatás, szkennelés, erőforrások monitorozása, okoségő vezérlése, billentyűzet háttérvilágításának állítása, Wi-Fi kapcsolat kezelése, meg sok más. Eleve a számológépnek használt calc is saját rc scripttel indul, meg a neovim is saját Lua script (init.lua) futásával kezd, abban van a konfig. Szinte minden saját gyártású script a rendszeren. Nyilván ezeket nem egyszerre írtam, hanem az évek során apránként jött össze, állt össze. A legtöbb elég primitív, pár soros, 3-5 sor környéke elég gyakori, de a bonyolultabbak sem haladják meg a 100 sort nagyon.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( dejo v | 2024. 09. 17., k – 06:32 )

Szerintem aki egyáltalán, az mindenki többet használ.
Már csak azért is, mert a többségünk több operációs rendszert is használ.

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( hnsz2002 v | 2024. 09. 17., k – 07:01 )

Szerkesztve: 2024. 09. 17., k – 07:01

bash és php

Nem feltétlen a script egyszerűsége vagy bonyolultsága miatt, hanem hogy hol mit könnyű megcsinálni. Fájlműveletekhez, OS piszkálásához, telepítéshez, konfighoz tuti hogy bash (+ nyilván sed, awk és egyéb toolok), nagy méretben is. De pl. egy mysql kapcsolathoz hiába csak egy select/insert, inkább php. Vagy egy json, xml parse-oláshoz, kigeneráláshoz is, akkor ha 10 sor az egész.

"Sose a gép a hülye."

( Smokey2k | 2024. 09. 17., k – 08:53 )

Nincs ilyen hogy leginkább, a feladat adja hogy ha kell miben scripteljek. Mondjuk nem tartom magam üzemeltetőnek de néha kell avval is foglalkoznom.

( kl3on v | 2024. 09. 17., k – 09:37 )

A Perl a Unix világ Cobolja, azt hiszem. A kutya nem nyúl már hozzá magától, de a háttérben ott van és működtet 1000 fontos dolgot.

( x-daemon | 2024. 09. 17., k – 15:40 )

bash, tsql

neked aztan fura humorod van...

( aszijg v | 2024. 09. 17., k – 16:30 )

Szerkesztve: 2024. 09. 17., k – 16:30

Az igazi férfi sohasem sír,

Az igazi férfi bash scriptet ír. :D

Tetszik! Nagyon otletes.

Mondjuk aki nem tud programozni, azon nem segit, meg scriptnyelven jellemzoen konnyebben meg lehet tanulni, es gyorsabban/konnyebben lehet kodolni, szoval erre a feladatra pont kevesbe alkalmas. De egyebkent jo.

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