[megoldva] szövegfájl kigyomlálása

Egyszerű szövegfájl szerkesztéséhez kéne egy kis segítség bash-ben.
A minta szöveg:
575a785c00000005003cf675
d46c775c0000000500ab41c5
....

ilyen 24 random számos-betűs ID stringekből van pár ezer sor, enterrel elválasztva.

A probléma: a program ami generálja, bele-beleszór az ID stringeken kívül tetszőleges helyeken más információkat is.
Ezeket valahogy ki kéne gyomlálni a fáljból.

Arra gondoltam, hogy mindent kidobnék a fájlból ami nem 24 karakter hosszú.
Biztos marha egyszerű, de sajnos nem sokszor írok shellscriptet, elakadtam.
wc-vel lépnék egy ciklusban sorról sorra, és ami nem 24 karakteres sor, azt törölném.
De hátha van erre jobb módszer is, ki hogyan csinálná?

Hozzászólások


cat in.txt |egrep '^.{24}$' > out.txt

semminek, megszokás. a 'grep pattern file'-nak nem a végén van a pattern, nehezebb javítani, amíg nézem, hogy mit kell írni: ugye a 'cat file|grep pattern' esetén meg csak felfele nyíl, aztán lehet javítani. Meg egyébként is, akármit akarok egy fileal kezdeni, a cat jó az elejére. Képes vagyok catot lessbe pipeolni, ha arról van szó :)

Így van, antipattern. ZHban nem is írtam ilyet, sőt, scriptbe sem teszek ilyet (mondjuk ha ilyenért nullázol pontot, hááát szóval izé, ott nem a diákkal van a legnagyobb baj). ZHn kívül meg egész őszintén kilométeres magasságokból teszek rá, hogy valakinek nem tetszik. Az az én shellem, azt és úgy gépelek bele, ahogy nekem kényelmes, és normális tempóban tudom végezni a munkámat. Én se pofázok bele más vegetatív idegrendszerébe. Ha kicatolok egy filet, aztán rájövök, hogy hosszú, akkor a fel,|,less,enter számomra a legkényelmesebb módja kapni egy pagert, és pont nem érdekel, hogy úristen, hogy néz ez ki.

Hátránya egyébként nincs. Igen, tudom, hogy felesleges invokáció, meg tök felesleges pipe, meg emiatt pl kellhet pipefail, de ez, ahol, és ahogyan használom, a gyakorlatban teljesen mindegy.

--
Ja, és ha meg már, akkor file-al, nem rövidült semmi, csak kimaradt a kötőjel. Vagy akkor indokold is meg, hogy te ragaszkodsz a hivatalos magyar írásmódjához :)

> "file-al"??? Ne tetézd... file+val=? Nos? Mi lesz a ragban a "v"-vel? A magyar nyelv- és irodalom tanárod fájlalja ezt, de nagyon. :-P

Így reggel már én is :) Mea maxima culpa.

> Azért nulláz, mert megmagyarázza, hogy bashizm-mal (fölfelé nyíl) milyen jó így. :-P

Ezt viszont neked lenne érdemes fájlalni (igen, látom a simleyt). A felfele nyíl nem bashizm, hanem akármelyik nem kétbetűs shellizm. És előadod felsőoktatásunk jó szokását, hogy büntet, mert mikor még az előadó is a csattogós lepkét tologatta, akkor másképp volt. Biztos van ma olyan munkaállomás féle, ahol nem megy a shellben a felfele gomb.

Ja, és ezek szerint nem csak scriptet íratsz ZHn, tehát akkor interaktív shellből is papíron kell nálad vizsgázni? De jó lehet, előremutató ám :P

Klasszik ksh-ban (3-betűs shell, és nem a ksh93-ról beszélek, tehát arról, ami van Solarisban, AIX-ben HP-UX-ben, Tru64 UNIX alatt, stb) is megy a kurzor fel. De csak akkor fogadom el ezt érvként és a Zeller-féle pontnullázás helyett pontfelezésnek, ha leírod, hogy mit kell hozzá csinálni, hogy menjen, és MEG IS TUDOD MAGYARÁZNI, hogy mit csináltál, és miért.

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

Szóval a munkaerőpiacon már se Solaris, se HP-UX, se AIX admin nincs. Mint ahogy nyilván olyan rendszerek se, ahol csak ksh van (a klasszik, általam is emlegetett ksh88), és még bash-t se telepíthetsz.

(Amúgy szerintem rohadtul félreértetted. Fenti kereskedelmi rendszerekben pont az általam említett ksh88 van, amiben trükközni kell, és a ksh93 nem érhető el egyáltalán, vagy némelyiken csak módolás után.)

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

De, nyilván vannak. Hogy szignifikáns-e? Nem igazán. Beszédes, hogy pont a solarissal kezdted, ami gyak kihalt. Közvetlen közelről néztem végig, hogy mikor megvette az orákulum, hogy az egyébként nem a hirtelen váltásairól híres Ericsson (ami igencsak sok helyen használta, kb mindenben, ami nem axe-n futott) ijedtében 2-3 év alatt gyakorlatilag teljesen lejött róla. A ZHban érintett hallgatóid jó része nem nagyon fog ilyeneket látni, vagy ha igen, akkor sem nap mint nap, hogy erre kelljen optimalizálni.

Szóval persze, vannak ezek. Igen, érdemes tudni azt, hogy nem csak a bash van a világon. De az igazság az, hogy ha szerinted normális dolog, hogy nulla pontot ér egy ZHn, ha valaki használná a felfele nyilat, és nem tudja mellé megmagyarázni, hogy hogyan kell beberhelni egy ezer éves ksh-ba, akkor érdemes volna hátralépni egy párat, kidugni a fejed a buborékodból, mert erősen elszakadtál a realitások talajától. És ezt viccen kívül a legnagyobb jóindulattal mondom, mert nagyon tisztelem egyébként az ilyen irányú tudásod és elhivatottságod, csak láthatólag beleestél a specializálódott emberek szokásos hibájába.

(jep, lehet hogy félreértettem, őszintén szólva nem követem, hogy ezekben épp mi van)

;-)
Amikor percenként 100 EUR kötbérvel is erőst megraknak ha nem vagy kész 10 percen belül... akkor érdemes catvel kezdeni majd |grepvel folytatni a dump/logfile gyomlálást, s kifejezetten azért így hogy felfelé nyíl majd 2-3 backspace leütésvel s kevés átírásval meglegyen a tuti s jól működő regexp. Mihamarabb lesz erőst jó az output, annál es több idő jut a teamvel megoldani a többi részproblémát. A teamvel amely fonákra fordított új-angolul írogat neked egy nagyon távoli és keleti országból, szavanként olyan hibákkal amely felezés lenne egy nyelvvizsgán, egy teljes mondatjuk meg már benullázás, na de a rögvalóság meg az hogy deal-with-it.
;-)

Bash alatt az M-. szerintem még kényelmesebb, beszúrja a historyból az előző sor utolsó szavát. Egy cat hosszu.txt enter után csak ennyit kell gépelni: less M-. enter. Baromi sok helyen lehet használni, érdemes megjegyezni.

Pl.:

vi foo.sh
chmod +x M-.
./M-.

vagy

useradd ... izebigyó
passwd M-.

vagy

cp valami /path/to/helye
cd M-.

--
$ grep -c egy$ word.list
100

a 'grep pattern file'-nak nem a végén van a pattern, nehezebb javítani
Gondolom, ezt még nem ismerted :)
(azaz egy M-b-t is nyomsz, és ott vagy, mint a cat ... | grep ...-pel - miközben a cat négy leütés, az M-b viszont kettő, tehát a harmadik javítástól lesz csak összesítve jobb a cat)

De, képzeld ismerem.

Viszont figyelmes olvasónak feltűnhet, hogy egy szóval nem mondtam, hogy azért jobb a cat, mert kevesebbet kell leütni. Azért jobb, mert nekem így kényelmesebb. Nem értem, miért érzitek szükségét, hogy megmagyarázzátok, hogy hogy lesz nekem jó.

Nem értem, miért érzitek szükségét, hogy megmagyarázzátok, hogy hogy lesz nekem jó.
Nem érzem én semminek szükségét, szerintem más sem. Egysoros kommentekre írtál rengeteg szubjektív tartalmat - már azt hittem, poliverzum vagy (még a stílus is hasonló volt).

Egyébként csak arra szerettem volna a figyelmedet felhívni, hogy a bash-ban van hotkey arra, hogy egy szóval (azaz jelen esetben a fájlnévvel) visszalépjen, így pont megkapod azt, amit szeretnél, miszerint rögtön tudod a regexpet szerkeszteni.

Most már poli is vagyok, csodálatos. :)

Ja, mikor valaki kérdezte, hogy minek, elmondtam, hogy semminek, meg hogy miért szoktam meg így. Erre jön zeller az ez bizony nulla ponttal, Zahy meg a kshval.

Azt meg nem tudtam, hogy nem lehet szubjektív dolgokat leírni.

Az igyekezetedet köszönöm, hidd el, hogy ismerem a shell működését, egyszerűen nekem így kényelmes, és nem látok benne benefitet, hogy leszoktassam róla magam.

Az az én shellem, azt és úgy gépelek bele, ahogy nekem kényelmes

csodálkozom azon hogy régi unixosok a unix filozófia ellen beszélnek, miszerint a user úgy használja a rendszert ahogy neki tetszik/egy feladatot több módon is meg lehet oldani. főleg aki BSD-s, amit eleve úgy adnak oda hogy csinálj vele amit akarsz.

a zh-n lehet nullázni, de való életben vagy nem számít (nyilván amíg erőforrás/hatékonyság gátja nem lesz) hogy oldod meg csak meg legyen oldva, vagy az sem érdekes ha elsőre nem tudsz megoldani valamit: akkor nem megállunk hogy nulla pont, hanem addig kell csinálni míg kész nem lesz.

és a való életben szintén huszadrangú, hogy milyen vezérlő karaktereket kell megadni, a lényeg hogy a kurzor vezérlő billentyűk megkönnyítsék a munkát. annyit írtam be gugliba hogy ksh arro, mire az első találatban ott van mi kell ehhez. ilyen tudást számonkérni felesleges, nem életszerű. egyébként az, hogy egy shellben a kurzor billentyűket használni lehessen annyira alap mint hogy az Entert is lehet, nem CTRL-J-ket nyomogatunk. az meg ma pont nem érdekel, hogy régen nem volt kurzor billentyű, legalább 30 éve mindenhol van. még az openbsdsek is megcsinálták hogy default megy cshban, nem kell bűvészkedni hozzá.

régi unixok: ha 100 egységsugarú usernek kell barátságtalan shellt használnia és ebből 98 azt jelzi vissza a managernek hogy nem jó használni, akkor lehet a következő beszerzésnél olyat vesznek amire nem panaszkodnak a felhasználók, akikért lenne ugye a rendszer. persze a valós ok nem ez, hanem az áruk és az x86 szerverek teljesítmény- és funkcióbeli fejlődése. a nagy vasak nagy oprendszerei megmaradnak egy szűk területre ami egyre fogy.

ps.: én is mindig berzenkedek a cat ilyetén módon való használata ellen, de pont emiatt (tesztelés) én is szoktam így használni. persze a véglegesben nem hagyom így és ha másnál meglátom szólok neki. aztán vagy átírja vagy nem és legtöbbször nem számít.

kroozo: Ne aggódj, csak az énjüket (ego) akarták fényezni. Mindenkivel előfordul. Vagy gondolkozzak pozitívan és gondoljam azt, hogy csak segíteni akartak? Mindegy.

Én is szeretem cat fajl | parancs szerkezetet, pedig én is tudom, hogy a parancsok általában tudnak paraméterből, vagy átirányításból fájlt olvasni. Szóval +1 a cat-nak. :)

Én nem haragszom, a cat nyilván fölösleges oda, csak leírtam, hogy miért maradt ott. (Ami valószínűleg nettó tovább tartott, mint kipróbálni).

Ráadásul nem is valami jó, mert csak a hosszra szűr. gazsiazasz lentebb írta, hogy lehet valóban csak mondjuk hexára szűrni (bár beware, nincs az elején-végén ^-$, szóval nem lesz jó), csak nem voltam benne biztos, hogy milyen karakterek lehetnek ott benne, de így azért lehet benne fals pozitív a szemeteléstől függően.

sub
--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-