- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Nincs leginkább. (bash/ansible/php)
- A hozzászóláshoz be kell jelentkezni
(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.
- A hozzászóláshoz be kell jelentkezni
Ilyen esetben te semmiben sem csinálod. Csak az "embered".
It is our choices that define us.
Thinkpad X1 Carbon | Arch linux
- A hozzászóláshoz be kell jelentkezni
Pontosan arra szavaztam.
Ja, a menüpontot ("Semmit, nem szkriptelek") is én adtam hozzá, volt is miért: második legnépszerűbb opció.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Most éppen nem tudunk fizetni, de kellene egy...
- A hozzászóláshoz be kell jelentkezni
Vagy a "robotom van rá"-opció
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Szegény Kotlin miért nincs a listában? Az a legjobb, amikor bash + kotlin + python + go van keverve :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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. :-)
- A hozzászóláshoz be kell jelentkezni
É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 :-) )
- A hozzászóláshoz be kell jelentkezni
Az csak organikusan fejlődött... :-D
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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. :-)
- A hozzászóláshoz be kell jelentkezni
A bash-sel inkább az a baj, hogy noha lehet benne jól olvasható kódot írni, de nem ez a jellemző. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Tudnál mondani egy példát? Úgy elkapott a kíváncsiság :) Lassan 25 éve üzemeltetek Linuxokat, érdekelne, mit nem szoktunk manapság használni, amit régen meg igen.
- A hozzászóláshoz be kell jelentkezni
> mit nem szoktunk manapság használni, amit régen meg igen
awk, perl :)
- A hozzászóláshoz be kell jelentkezni
Pedig az awk jó cucc! Perl-t nem ismerem közelebbről, arról ezért nem mondok semmit.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
jah, es errol mond meg ranezesre hogy mennyi az annyi! :D
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Timeout-nál van, hogy épp csak szubjektíven kell látni, ha kevés, kicsit tovább nyomod a hashmark-ot. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Azért időzíteni lehet viszonylag pontosan, lekérheted a date +%N értékét akár, szóval lehet ügyeskedni, ha jól akarod csinálni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Aztán megy a csodálkozás, hogy miért horpad Paks.
- A hozzászóláshoz be kell jelentkezni
Nem zárt ciklusban. Persze, egy while :; do :; done felfal egy CPU magot, ez világos. Nézd csak meg, az alábbi scriptemben hogyan oldottam meg, hogy noha sleep-pel időzítek, mégsem halmozódik fel a sleep-ek közötti futásidő, ugyanis ránézek arra, hogy az aktuális és a kívánt idő között mennyi a különbség, így ha kell, picit kevesebbet, vagy, ha épp elsiettem a dolgot, picit többet időzítek:
#!/bin/bash
LOCK="/tmp/timoff.$USER"
if read <"$LOCK"; then
kill "$REPLY"
fi
echo $$ >"$LOCK"
a="`zenity --title='Időzített kikapcsolás' --height=300 \
--list --text='Válaszd ki a kikapcsolási időt!' \
--column='Leállítási' --column='idő' --radiolist \
FALSE '0:15' \
TRUE '0:30' \
FALSE '0:45' \
FALSE '1:00' \
FALSE '1:15' \
FALSE '1:30' \
FALSE '1:45' \
FALSE '2:00'`"
if [ -z "$a" ]; then
zenity --title='Időzített kikapcsolás' --info --text='A számítógép nem áll le magától!'
rm -f "$LOCK"
exit 0
fi
BASE=`date '+%s'`
ifs_backup="$IFS"
IFS=':'
read h m <<<"$a"
IFS="$ifs_backup"
((m+=60*h))
while [ "$m" -gt 0 ]; do
level='normal'
[ "$m" -lt 6 ] && level='critical'
notify-send -u "$level" 'Automatikus leállítás' "$m perc múlva"
((BASE+=60))
CURRENT=`date '+%s'`
sleep $((BASE-CURRENT))
((--m == 0)) && pgrep '^dnf' &>/dev/null && ((m++))
done
rm -f "$LOCK"
sudo /sbin/poweroff
exit 0
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ez olyan vindóz-fan hozzászólás. ;) Mert ott vannak ilyenek.
- A hozzászóláshoz be kell jelentkezni
, a kódban is hosszként megjelenő bitkolbász
Ez benne a legszebb :D :D :D A brainfuck legalább tömör.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Amikor az ügyfél az élményért fizet, nem az eredményért. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
ennel mar csak az a jobb, amikor az ugyfel azert fizet neked, mert orakig nezed a progress bart :) (megtortent eset alapjan)
- A hozzászóláshoz be kell jelentkezni
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. :-)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Annyit tudok hozzátenni, hogy sok dolog csak életkor kérdése. :( Nálam 94 óta dühöng a soknevű script és bináris használata. Az apró programocskák ilyenkor nem is töltődnek újra. A unix háza táján az ilyen megoldás egyáltalán nem új, de ott a hardlink használata a divi.
Az flock-ot serényen használom. Shellben egy kicsit idegen az, hogy kvázi utasítászárójellel be kell keríteni az ojjektumot. Az eredeti megoldás a megelőző Lock és a lezáro Unlock volt, amely használatakor egyedi lockot hozott létre. Az flock használatával lehet hard-soft lockolni is.
Néha olybá tűnik, hogy nem használom ki a linux/shell/utils lehetőségeit, de csak azért, mert jópár dolgot 10-15 évvel korábban megírtam még AIX/ksh-ra és azóta is teszik a dolgukat.
- A hozzászóláshoz be kell jelentkezni
> amiben egy paraméter attól függött, hogy mi a script neve
hat ez azert eleg regi trukk. szakallas. hogy mast ne mondjak: munin es busybox
- A hozzászóláshoz be kell jelentkezni
Kicsit régebbi: pl. tar.
- A hozzászóláshoz be kell jelentkezni
Lehet ezt fokozni:
pack / unpack / pcat (avagy compress / uncompress / zcat )
ex / vi / view / .... (standardan 5 hardlinkje volt)
cp / mv / ln
- A hozzászóláshoz be kell jelentkezni
A trap azoknak mindenképp ismerős, akik a K&P könyvből kezdték az ismerkedést :-)
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Ugyanez, annyi módosítással, hogy ha gond a sebesség, akkor az adott műveletet megírom C-ben.
- A hozzászóláshoz be kell jelentkezni
Üzemeltetésben mi olyan feladat aminél ennyire lassú a Python?
- A hozzászóláshoz be kell jelentkezni
Semmi. Ugyanúgy csak a saját gépeimet "üzemeltetem", de azokon csinálok olyasmit szkriptekkel, aminél előjön a sebesség, mint probléma. (Egyébként kódgenerálás.)
- A hozzászóláshoz be kell jelentkezni
vagy pypy :) az mar kozel C sebesseg
- A hozzászóláshoz be kell jelentkezni
Eleg csak annyit irni, hogy "az mar kozel C", leven a C maga a fenysebesseg! :-)
- A hozzászóláshoz be kell jelentkezni
Feladatfüggő: bash / perl / php
- A hozzászóláshoz be kell jelentkezni
É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!
- A hozzászóláshoz be kell jelentkezni
Egy IBM-es kollégát idézve: Az IBM még nem csinált olyan szervert, amin a Java kielégítő sebességgel futna. :-D
- A hozzászóláshoz be kell jelentkezni
"az legalább működik"?
- A hozzászóláshoz be kell jelentkezni
Ha te írtad és tudod melyik Java verzióval mire kell vigyázni, akkor működhet :-)
- A hozzászóláshoz be kell jelentkezni
Akkor én is coming outolok, szintén Java-ban írok scripteket :D és valóban, volt olyan, hogy Windows alatt fejlesztettem és Debian alatt lett beütemezve, hibátlanul ment.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
Pont ezt akartam írni, időközben eszembe jutott a parallel, használtam már scriptemben. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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. :-)
- A hozzászóláshoz be kell jelentkezni
Jó tudni! Ezek azok, amiket nekem guglizgatni kellene, ellenben Javában összetákolom pár perc alatt.
Ez a HA cluster jó cuccnak hangzik, gratulálok hozzá!
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
Mikor miben tűnik egyszerűbbnek.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A fejlesztőket miért zártad ki? Nem szereted őket?
Egyébként awk és bash.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
fejlesztőként mit használok rendszerüzemeltetés közben? :D
amúgy nem akartam kizáró lenni, csak így láttam értelmét
- A hozzászóláshoz be kell jelentkezni
Á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
- A hozzászóláshoz be kell jelentkezni
Igeeen, a C egy tipikus táblázatíró nyelv. :-D Én inkább programot írok vele.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Te meg úgy jársz, mint a legtöbb nyelvtannáci, hogy a sarokban izzadsz a többé-kevésbé védhető keretrendszeredre, míg mindenki más bulizik és értette pontosan, hogy az elhangzott mondat mit jelentett. :)
- A hozzászóláshoz be kell jelentkezni
Nem értesz ehhez! locsemege a kedvenc piszkantyú partnerem - és ez kölcsönös. :-D
- A hozzászóláshoz be kell jelentkezni
:D ezesetben elnézést, kérem folytassák
- A hozzászóláshoz be kell jelentkezni
Legfeljebb egy adott táblázat elemeinek ábrázolása C szintaxis szerint.
Nyilván erre gondoltam. Egyébként C program sincs, csak az adott algoritmus megfogalmazása C szintaxis szerint.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Az adatbazis az egy tajszolas, valojaban minden felhasznalo egy sima Excelt ert alatta. :-)
- A hozzászóláshoz be kell jelentkezni
Vagy egy struktúra tömböt. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Na ugye! Akkor meg mit kötekszel? :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Mert jólesik! :-DDD
- A hozzászóláshoz be kell jelentkezni
Ez nem üzemeltetés
a kerdezo viszont az uzemeltetes kozbeni script hasznalatra kivancsi. ha te arra hogy a dev/tester/onemanshow mit hasznal, akkor arra tudsz feladni masik szavazast.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Azt hiszem, írok az etióp esélyegyenlőségi ombudszmannak... :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
É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é.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Hú, tényleg, calc, napi szinten használom. (És itt ugye nem a LibreOffice Calc-ról beszélünk.)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Látod, ezért is jó Javában szkriptelni.
- A hozzászóláshoz be kell jelentkezni
Vagy Pythonban :)
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ahogy a Raku-t elnézem, nem is baj, hogy nincs piszkálva az ötös...
- A hozzászóláshoz be kell jelentkezni
egyetértek :D
- A hozzászóláshoz be kell jelentkezni
Az igazi férfi sohasem sír,
Az igazi férfi bash scriptet ír. :D
- A hozzászóláshoz be kell jelentkezni
Annak aki nem szeret script nyelven scriptelni:
https://github.com/igor-petruk/scriptisto
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
rust -ban eleg gyorsan lehet python szeru kodot is ossze lokni, gyakran hasonlo szagu librarik is vannak.
Es a vicc az, hogy nem is lasabb fejleszteni foleg ha mindenfele python kod szepseg ellenorzes idejet is bele veszuk.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
> mindenfele python kod szepseg ellenorzes
wtf?
- A hozzászóláshoz be kell jelentkezni
Értem én, hogy nem csak C-hez jó, de azt pont fölösleges ilyen bonyolultul használni, helyette fel kell tenni a Fabrice Bellard-féle tcc-t és máris lehet she-banggal futtatni a C-kódot. :-)
- A hozzászóláshoz be kell jelentkezni
No ha már Ansible - "yaml", akkor belemehetünk a "legelterjedtebb DevOps Tool-ok" témakörébe is szerintem.
Tekintve hogy ezzel termékspecifikussá válik a kissé kakukktojás (ansible) mivel a gitlab-ci is "yaml"-t használ, de a "helm" is (bár azt hagyjuk hogy a helm-nél a values.yaml-ban egy értéknél mi történik ha épp az y a kulcs neve, pl. koordinátánál és ennek az értelmezése hirtelen mivé változik, ha meg escape-eljük akkor az is gyönyörű ha pythonnal akarjuk írni egy template készítés esetén) szóval innentől kezdve ha "Ansible YAML" akkor szerintem sokan használhatják a Jenkins Groovy-t, a Terraform, stb. ahogy emlíem, gitlab-ci "DSL"-eket.
S igen, ahogy sokan írják, "attól függ" - miért kellene Python hogy ha a parancsok legtöbbje OS subprocess - viszont dehogy bash, ha nem elég a $? / komolyabb kivételkezelésre vagy épp aszinkron megoldásokra (pl. aszinkron konténer-feltöltés) van szükség, stb.
- A hozzászóláshoz be kell jelentkezni
Aki a yamölt konfiguráció tárolására kitalálta, azt gyenge parázs fölött kéne pirítani addig, amíg puhára nem sül... Oké, gépi feldolgozásra (kreálás és felhasználás) rendben van, de bármit kézzel konfigurálni vele (és sajnos a jamöl-fanatikusok sokszor olyan helyen is használják, ahol nagyon nem kéne - mert ugye nekik kényelmes felolvasni és használni kódból) a hibalehetőségek sz@rosbödöne, ami - inkább előbb, mint utóbb - ráborul arra, akinek ezt használni kell.
- A hozzászóláshoz be kell jelentkezni
Ebben nem ertunk egyet. Sokkal jobb, mint minden egyes programhoz valami sajat konfigformatumot hasznalni (ld. Apache).
Ha egyszerubb, tudod kezzel szerkeszteni. Ha bonyolultabb, - mivel minden tamogatja a yaml-t - tetszoleges nyelven tudsz magadnak alkalmazas-specifikus konfigszerkesztot irni (vagy ha mar letezik ra, hasznalni). Illetve kodbol is egyszerubb modositani, ahol annyi fut, hogy ennek ertelme lenne.
A masik hasonlo a celra a JSON, ennel a YAML akkor mar konnyebben atlathato. A klasszikus INI-hez kepest meg jobb a strukturaja (ott elegge korlatos volt a szintek szama). XML-t is hasznalnak erre, de az meg kezzel nehezebben szerkesztheto.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
JSON is átlátható, ráadásul gyakorlatilag szabadon formázható. Ahogy az xml is. És sokkal inkább xml-ben írom át a paramétert, mint a kommentekkel telesz@rt, emiatt a struktúrájában nehezen átlátható jamölben teszem ugyanezt.
A whitespace kiemelt szerepet kapva nagyon csúnya dolgokra képes - sajnos láttam ilyen miatt hosszan fejvakarósan nézni egy jamölben konfigurálandó sz@rkupacot, ami az egyik környezetben jól működött, a másikban meg baromságokat csinált (sok kommentsor, a szintek egy-egy space-szel voltak eltolva). Nem a két yamöl-re a diff nem volt megoldás, mert nem csak néhány paraméter értéke volt eltérő...
Aztán kiderült, hogy egy helyen egy kommentből kivett paraméternél aki kommentbe rakta, az a szóköz _helyére_ rakta be a #-ot, aki meg visszaélesítette a paramétert, az meg csak simán kivette a "#"-ot... Mindjárt egy szinttel feljebb "ugrott" az adott paraméter, ami szerencsétlen módon ott is értelmezett volt...
- A hozzászóláshoz be kell jelentkezni