Új hozzászólás Aktív témák

• #1503 ddekany veterán dabadab #1478

  Új Válasz 2013-06-02 18:07:43 #1503

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz dabadab #1478 üzenetére

  Amúgy a tr -s ' ' |cut -f5 -d' ' helyett szebb oszlop kivágásra, hogy awk '{ print $5 }'. (Igazából egyben a tail -n +2 is kiváltható vele: { if (NR > 1) print $5 })

• #1497 ddekany veterán doc #1494

  Új Válasz 2013-05-31 12:55:55 #1497

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz doc #1494 üzenetére

  Jó, akkor: df .| jfilter usagePercentage gte 90. Mi van ezzel?

  Parsolással meg nem tudom mi bajod, bár tán tesem... Igen, bele kell rakni egy hívás valami shared library funkcióra, ami az egész mechanizmust "meghívja". Soha nem látott komplexitás szoftverfejlesztés területén...

  "meg mindig nem lattunk semmit ami igazolna hogy ez a vilagmegvalto ujitas valoban megsporolna szamottevo idot "

  Visszanézve a két példát, képes vagy ezt így kijelenteni. Valószínűleg direkt szórakozol... vagy van az a bizonyos határtalan dolog is elvégre, nem tudhatom.

• #1493 ddekany veterán doc #1492

  Új Válasz 2013-05-31 11:07:28 #1493

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz doc #1492 üzenetére

  "azzal, hogy nem valaszoltal"

  De akkor mi akart lenni a kérdés? Remélem nem az, hogy hogyan nézem meg, hol nagyobb 90%-nál a foglaltság...

  "az meg hogy minden egyes aprocska toolban legyen oda-vissza iranyu json parser es konverter"

  Kurva egyszerű lenne pedig a tool író szempontjából, mivel ezek lényegében rendszer funkciók... kb. regisztrálsz két callbackot a toolban, egyik a formázás, másik maga a lényegi feladat elvégzése, és majd az OS(/shell) eldönti, hogy melyiket hívja mikor. Az meg nem tudom leesett-e, hogy ha egy alacsonabb rétegben befektetsz X emberévet, azzal megtakarítasz összességében sokszor X emberévet. Pl. sokkal kevesebb idő megy el tool írásra, mint tool használatra.

• #1491 ddekany veterán doc #1490

  Új Válasz 2013-05-31 01:41:15 #1491

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz doc #1490 üzenetére

  Gondolom a felvetés itt az lenne, hogy de mi van, ha a JSON feldolgozások után mégis ki akarom írni a végeredményt a felhasználónak.

  Először is, mi van jelenleg. Kitéphetek sorokat egy táblázatból, a fejléc meg ugye elmarad (fejléc nélküli táblázat meg azért elég necces). Aztán a táblázat oszlopok szélessége nem a megjelenített, hanem az összes (kiszűrt) cuccokhoz van igazítva, ez sem a legszebb.

  Aztán mit lehetne a JSON (vagy ami) csodával... egy dictionary listából eleve lehet automatikusan táblázatot csinálni, aminek fejléce is van meg minden. Nyilván, ehhez az kell, hogy egy tool alapértelmezett kimeneti formátuma (JSON vagy plain text) jól dőljön el. Ezt megadhatnád kapcsolóban (--json VS --plain, mondjuk), vagy ha nem adod meg, akkor alapértelmezésben --plain lesz, kivéve ha egy speciális pipe szimbólumot adsz meg utána, mondjuk legyen .| vagy akármi, és akkor a --json lenne az alapértelmezés a bal oldalán. Aztán ha még csavarni akarsz azon, hogy hogy nézzen ki a táblázat, akkor erre is könnyű tool-okat írni, tehát pl. sokminden .| jtable egyikOszlopNeve=ígyformázva másikOszlopNeve=amúgyformázva ,és akkor ebbe belepipeolod amit akarsz. Sőt... egy másik érdekes lehetőség, hogy mivel a df ezen fiktív változata belül úgy is eleve JSON-ból (pontosabban annak AST-jéből, de most mindegy) formáztatja az embernek szánt kimenetet is, az is lehetne standard opció, hogy visszavezetem bele amit én kikapartam szűrt meg így-úgy rendezett akármicsinált JSON eredményt, hogy na akkor ezt formázd, mintha csak te termelted volna belül magadnak. Szóval elég sok hatékony dolgot lehet ezzel csinálni... Ha meg tényleg csak plain textet akarsz szűrni, azt is lehet, mert nem j-s kimenetet kérsz és kész...

• #1486 ddekany veterán doc #1483

  Új Válasz 2013-05-30 17:30:14 #1486

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz doc #1483 üzenetére

  "biztos en vagyok a hulye, de en nem szoktam space-t rakni a filenevbe"

  Legalábbis szerveren én sem... viszont nem is én állítom jellemzően elő a fájlokat, vagy nem olyan program amit én írtam, szóval a fölött nincs kontrollom (mint gondolom másnak sincs).

  "a peldad meg santit, mert a df nyilvan alapvetoen arra van, hogy EN megnezzem mennyi a szabad hely"

  Az van, hogy ott egy rakás tool a toolboxban, és nyilván azt lenne jó akkor használni scriptekben, szóval ezzel megint nincs mit kezdeni nagyon.

  Ha meg a példák után is szerinted a JSON-s (vagy akármilyen gépi fogyasztásra strukturált) kimenettel a bonyolultabb minden, vagy nem érné meg globálisan egy ilyen irány, azzal már nem tudok mit kezdeni...

  "ranezek a df outputjara, majd egyedul a "grep" parancsot hasznalva mar kesz is a megoldas"

  És ha ránézel a shell scripte, amit nem tegnap írtál, vagy nem te írtad, akkor meg nem látod mit csinál... A forráskódokat általában többször olvassák mint írják.

  "Alapvetoen nem rossz az otlet, hogy valamilyen szabvanyos feluleten kommunikaljanak egymassal a programok, de ezt rakenyszeriteni a felhasznaloi interakciora kitalalt programokra nagy butasag"

  De hát 2x megírni a programokat, egyszer így, egyszer úgy, meg még nagyobb képtelenség. Hiszen a kétféle kimenet generálásnál a forráskód java része közös lenne.

  De szóval mindegy... átadtam amire gondoltam ama másik topicban, aztán kész.

• #1481 ddekany veterán doc #1479

  Új Válasz 2013-05-30 15:48:14 #1481

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz doc #1479 üzenetére

  Hát ez meg a másik... de ez meg itt OFF. Na de mindegy, akkor ide írom be, hogy ezért lenne jobb a JSON-al mert akkor csak simán:

  df $dev | jget usagePercentage

  Ránézel, és látod mit csinál, nem kell megnézni a kimenetet hány oszlop stb, leszedni a %-ot... Amúgy eredetileg df | jfilter device in @$-re is gondoltam, de mondjuk itt pont gány lenne, mert feleslegesen kérdezne le X device-t. (Csak az erdeti feladat valójában az volt, hogy melyik device-t NE nézze, azt adjuk át... de mindegy, innentől látod mire gondoltam a JSON-os kimenet feldolgozás kapcsán. Jó, ott sem elegáns a filter, de... mindegy, látszik mire jó.)

  Ja, az ls meg úgy jeach file in `ls` kb. Ott nincs ez a kavar, mert a kimenet ["file név 1", "file név 2"].

• #1480 ddekany veterán doc #1477

  Új Válasz 2013-05-30 15:40:40 #1480

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz doc #1477 üzenetére

  for i in `ls -1`; do echo $i ; done

  Na, igen, aljas módon pont ezért kérdeztem... mert ez hibás. Az for szegény white-space-nél szeletel, nem csak sortörésnél, és ezért ha szóköz van egy fájlnévbe, akkor több fájlnak fogja nézni. Aljas egy csapda, és azért van, mert eléggé trükkös ahogy a dolgok több körben behelyettesítődnek meg értelmezve lesznek. Hát na, ilyenekre gondoltam ott a másik topicban...

Új hozzászólás Aktív témák