awk bináris I/O

Szkriptek: Python, Perl, Bash, ...

Azon tűnődöm, hogy jó ugyan az awk, de bináris állományok feldolgozására nem optimális, mégpedig azért, mert ő maga zero terminated stringeket ábrázol. Így az az elképzelésem alakult ki, hogy marad a base64-ben való kommunikáció. Tehát van mondjuk egy függvényem, aminek inputja egy szám 0..255 tartományban - ha úgy tetszik, ez string csak számként értelmeződik -, ebből csinál base64-et - persze az átcsorduló biteket kezeli, a stream végére kell egy másik függvény, amelyik lezárja ezt. Kiírja stdout-ra a base64 kimenetet, a base64 -d felszedi ezt, s előállítja a bináris kimenetet.

C-ben írnám, de nem sok kedvem van feltenni a gépemre az OpenWrt SDK-t, majd mips_24kc processzor architektúrára fordítani. Bár az lenne a szép és egyben gyors megoldás. Meg egyszerű is.

Pythonhoz, Perlhez nem értek. Awk, [[b]a]sh, C jöhet.

  • 634 megtekintés

( tttaaa | 2020. 12. 06., v – 13:47 )

Szerkesztve: 2020. 12. 06., v – 13:53

xxd

Tetszőlegesen konfigolható hexdump-ot csinál, oda-vissza.

( uid_6201 v | 2020. 12. 06., v – 14:11 )

Pedig Python-t javasoltam volna AWK helyett. OpenWRT és egyéb kicsi erőforrások esetén pedig még képbe jöhet a Lua.
Egyik sem ördögtől való, csak mint mindenbe, bele kell merülni picit.

#!/usr/bin/python3

rdlen = 0
for s in open("/bin/awk", "rb"):
    print (s[0], len(s))
    rdlen += len(s)

print("Teljes hossz:", rdlen)

 

#!/usr/bin/lua

local rdlen = 0
local f = io.open("/bin/awk", "rb")

while true
do
    local s = f:read(1)
    if not s then break end
    -- print (s, #s) -- vedd ki a -- jelet a sor elejerol
    rdlen = rdlen + #s
end
f:close()
print ("Teljes hossz:", rdlen)

 #/usr/bin/luajit ha van, az sokkal gyorsabb.

( Nyosigomboc v | 2020. 12. 06., v – 16:13 )

Mondjuk nem ertem miert kell ilyesmire awk-ot hasznalni, de bucko is elegge fura dolgokra szokta, ugy tunik, ilyen a hardware-fejlesztes. A Python eleg sok rendszeren alapbol ott van, rengeteg beepitett fuggvenye meg modulja van, bar nem a sebessegre mentek ra a tervezesekor, erdemes megtanulni.

A base64 helyett meg a sima hexat ajanlom, mert akkor nem kell atcsordulo bitekkel szenvedni, ugyis byte-onkent praktikus feldolgozni.

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

"gyors" ... annó csináltam jó kis teszteket, hogy maga a nyelv milyen tempót tud, ha például abban szedem szét a spécin elkódolt adatot:

   - Python3   14 sec
   - PyPy3        0,76 sec
   - Lua          27 sec
   - LuaJit        0,95 sec
   - AWK        95 sec
 

Ilyen összehasonlítást nem végeztem, de volt, amit bash-ben írtam meg, aztán awk-ban, és ez utóbbi igen jelentősen gyorsabb volt. Talán 10-szeresnél is nagyobb volt az arány. Ha sebesség kell, akkor meg kell írni C-ben, aztán nincs semmi baj. Különösképpen, ha segít az ember a fordítónak, és nem align-olunk addr % 4 != 0 címre 32 bites változót, ami miatt még a 32 bites CPU is úgy legózná azt össze több gépi ciklusból, és effélék.

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

Közben eszembe jutott még valami. Nem lehet, hogy az adott script nyelven azért volt gyors a feladat, mert az kész, gépi kódra fordított modulként már létezett, s te felhasználtad azt? Mondjuk fft-t csinálni úgy, ha van egy fft lib-ed, nyilván gyors lesz, miközben, ha ezt leprogramozod awk-ban, s az is a scriptben fut, akkor meg lassú.

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

Amikor FFT tesztet írtam, akkor a nyelvet hasonlítottam össze, az adott nyelven írtam meg mindent. Python esetén például nem nyúltam a

import numpy
a = [10, 11, 11, 10];
numpy.fft.fft(a)

módszerhez, hiszen ezek a háttérben futó modulok C-ben vannak megírva, sőt a libfftw3-at használják ami még SIMD-re is frankók ráhajt.
Egyébként a lefordítot programnyelvek, például a C vagy a Rust a SIMD-en nyer további tempószorzót a szkriptnyelvekhez képest. Rust esetén mondjuk az iterátorokkal furmányos dolgozni, de ez is szépen fordul AVX-re.
Apropó a példa kapcsán érdemes elgondolkozni azon, hogy az autovektorizáció miért unsafe a számítási eredményt tekintve...

Ha viszont a SIMD és hasonlóktól eltekintünk, szkriptnyelvek terén meglepően jó tempót hoz a LuaJit és a PyPy3 futtatókörnyezet egyaránt, C-hez képest átlagosan kb. 4..5-ször lassabb csak. Lua-val mellesleg az OpenWRT webes adminjának routerbeli oldalán találkozol. Igen takarékos a futtatókörnyezete. A Python pedig ... svájcibicska.

azért volt gyors a feladat, mert az kész, gépi kódra fordított modulként már létezett, s te felhasználtad azt?

De. De a szövegfeldolgozások zöme Perlben és Pythonban is megoldható a beépített regexp támogatással, ami C libraryt használ. Ergó gyors. Szóval ha valaki nekiáll karakterenként baszkódni egy sztringgel, az C kivételével minden nyelvben kibaszott lassú lesz. Ezzel szemben ugyanez regexppel meg teljesen használható.

Ez nem szerelem kérdése, az awk nem erre való. Plain text adatok feldolgozására, abból is olyanokéra, ahol a stringek bizonyos karakterrel vannak elválasztva, és azokból kell bizonyos adatcsoportokat kinyerni, újrarendezni. Meg nem tömeges fedolgozásra, hanem esetire, scriptből hívogatva. Amire te akarod használni, tömeges, bináris adatfeldolgozás, ahol még az I/O teljesítmény is fontos, oda nagyon nem lesz jó. Ha annyira szereted a C-szerű szintaxist, írd C-ben, az is ott van minden rendszeren szinte, gcc, clang, stb. formájában, vagy ott se kell lennie, mert lefordítod binárissá. Erre is érvényes a cipőt a cipőboltból elv.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Meg nem tömeges fedolgozásra

Pedig arra épp alkalmas, hiszen a végtelenségig nyeli a rekordokat. A teljesítmény nem kritikus, mert csak akkor fut, amikor update-elődik a GeoIP, tehát mondjuk naponta egyszer. Utána úgyis újra kell indítani a tűzfalat, hogy érvényre is jusson. Attól, hogy ott lesz az új file, még nem történik semmi.

Különben megírtam már awk-ban. C-ben egyszerűbb és gyorsabb is lenne, csak prüszkölök az SDK telepítésétől.

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

Itt pont arról van szó, hogy plain text - pontosabban sor- és egy vagy több mezőszeparátorral jellemezhető - rekordszerkezetet kell feldolgozni. Az I/O teljesítmény nem lehet rossz, mert a diszkről "tömörített" (bináris) adat az input és ugyanilyen az output. A feldolgozás egy pipeline, ami a *NIX rendszereken optimalizált. Ugyan veszítünk 7x sebességet a futásidőnél - bár ez itt nem érdekes, de ennek az aránynak a nagyon sokszorosát nyerhetjük a fejlesztési idővel.

Tömeges feldolgozás.

Még a 90-es évek végén írtam egy 1,2M rekordot feldolgozó programot, ami 2012-ig üzemelt. Ez idő alatt több projekt sem merte lecserélni, mert nem volt teljesen világos, mit is csinálok. Pedig nem volt bonyolult. Egy kevés mezőből álló adatformátumot kellett egy 50 mezős bonyolultabb rekorddá alakítani soronként. A műveletek - eléggé kivonatosan:

  • név -> titulus, vezetéknév, keresztnév szétválasztása (az MTA ajánlása szerint)
  • irányítószám -> formáumellenőrzés, szótár ellenőrzés
  • helységnév+településrész név -> szétbontás, szótár ellenőrzés, hiánypótlás, helyesírás
  • komplex cím(*) -> szétbontás: közterület név, közterület fajta név+helyesírás (hibajavító szótár), házszám leválasztás, emelet +ajtó + stb. szétválasztás
  • telefonszám -> formátumellenőrzés és korrekció

Ennek a futásideje 30 perc körül volt. Úgy 2004-től pedig 6 perc. A fejlesztési idő 2-3 hét, mert adattiszításnál a sok típushibát is fel kell tárni.

(*) Egy példa: "Május 1 üTCe 17.. 1/em 12"

És ebből lesz: Május 1+utca+17+1+emelet+12"

Az awk eszközkészletével ez 30-40 sor. Vajon melyik nyelven hogyan írnád meg? ;)

"Az awk eszközkészletével ez 30-40 sor. Vajon melyik nyelven hogyan írnád meg? ;)" - Anno én lex-et vettem elő adatpucoláshoz (telefonszámok szétszedése körzetszám - telefonszám - mellék (ha van) részekre, egységes formátumra hozással), igaz, a c-forrás amit generált belőle, az maga volt a borzalom - de működött :)

Nekem mondod? ;)

Még a nevemet is elírták '95-ben (pedig nyomtatott nagybetűkkel volt írva), de 2010-ben visszamagyarosítottam! Azóta hamis a TAJ kártyám. :-D

A közös képviselőnk tavaly jelentette be, hogy a mi házunk közös képviselője. NAV: Nincs ilyen utca. (Bár már 2001-ben megkapta ezt a nevet.) Ügyvéd fél évet dolgozott rajta.

Most íratok jogász lányommal egy levelet az ELMŰ-nek. Az ok ugyanaz, de a felelősséget hárítom. Vagy leütöm az órát a falról és átviszem arra a címre, ahol szerintük tartózkodik. :-D

Úgy látszik, az adatkezeléshez felsőfokú végzettség kell, de nem árthat némi művészi hajlam sem.

Mondjuk nem ertem miert kell ilyesmire awk-ot hasznalni, de bucko is elegge fura dolgokra szokta, ugy tunik, ilyen a hardware-fejlesztes.

Ezért csuklok már órák óta! ;)

Az awk segítségével villámgyorsan lehet algoritmust írni és tesztelni. Kisebb mennyiségű adatnál meg pont tökmindegy a sebesség. (Mondjuk a mai gépeken milliós nagyságrendű sor feldolgozásakor sem komoly a futásidő.)

A hardverhez köze nincs, mindössze az egyszerű algoritmusokat könnyen át lehet rakni assemblerbe (és nem assemblybe ;).

Így írtam pl. FIR filtert, vagy primitív többcsatornás meredekség figyelőt. A mért adatot feldolgozom az awk kóddal, belövés után meg átírom másik nyelvre. A nyelv meg lehet akármi, mert már írtam ilyet AIX/xlc-ben, de sed-ben ;) is. Persze van olyan feladat+mcu, amit harverrel is meg lehet csinálni.

Vagy nem erre gondoltál?

Múltkor megzavartak, de most nem hagyom magam. ;)

Vegyük például ASSUME direktívát:

- MPASM (==assembler) - nincs ilyen

- gpasm (==assembler) - van ilyen (én tetettem bele)

- MASM - van ilyen

Tehát egyik assembler != másik assembler.

OK, akkor legyen ez egy gpasm specifikus assembly kód, amely a következő gépi kódra fordul le: (ide tetszőleges processzor gépi kódját helyettesítheted) :-D

Hasonló lehet a helyzet a REPT/IRP/IRPC "utasításokkal" is.

Így lesz az assembly+macro assembler entitásokból rövidítve macro assembler kód, még rövidebben assembler kód. Ebből is gépi kód fog készülni, amit esetleg más assembler fordítóval nem tudsz lefordítani (főként azokkal nem, amik C szitaxisra épülnek) , csak az adott macro assemblerrel.

Persze akár körül is írhatod, hogy a két assembler "nem kompatibilis"...az assembly kóddal? Nem.

Orulok, hogy szereztem par vidam orat! Emlekeztem ra, es irtad is, hogy algoritmusok felskiccelesere hasznalod mielott atirnad PIC-es ASM-re. Valoszinuleg az awk tervezesekor ez a felhasznalasi mod volt kb. az utolso, amire gondoltak, de veguli Turing-teljes, szoval mukodik.

Amugy az elso komolyabb munkahelyemen volt parszor parancssoros szovegfeldolgozasos feladat, amire a bash mar keves lett volna. Kerdeztem a fonokomtol, hogy mi legyen, megtanuljam a Perl-t, ami kb. erre van, vagy legyen PHP-ban, ha mar a webfejleszto csapatunkbol talan a grafikuslany meg a CEO az, aki nem ert hozza profi szinten (igy barki mar is bele tud nyulni, ha kell). Aztan az utobbi mellett dontottunk, es kesobb is tobbszor hasznaltam a PHP-t parancssoros programokhoz, mint webre. Az sem pont erre kitalalt nyelv, de teljesen jol mukodott. (Ma mar inkabb Pythonhoz nyulok.)

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

Örülök, hogy örülünk! :-D

Valoszinuleg az awk tervezesekor ez a felhasznalasi mod volt kb. az utolso, amire gondoltak

No, azért nem fogod teljesen az én helyzetemet. Itt ülök egy WINDOWS előtt, hát mi a lóf-ban programozzak? ;) Marad a cygwin, vagy átlépek valamelyi szerverre és már tolom is.

Aztán az awk->C vagy awk->ASM is mindegy, mert a problémát egyszerűen leírva akár ASM utasításokká is át lehet alakítani. A 32 TAP-os FIR filter végül "inline" kód lett. A 32-es for ciklus megvizsgálja az együtthatókat, majd a pozitív és negatív esetekre a pozitív és negatív értékkel szorzó makrókat írja, nulla esetén meg csak a pointer léptetést.

parancssoros szovegfeldolgozasos feladat, amire a bash mar keves lett volna

Háát. A bash tényleg nem alkalmas nagyobb mennyiségű szöveg feldolgozására. Én még akkor kezdtem el szövegfeldolgozó programokat írni, amikor a bash legfejletteb funkciója a Commandline Editing volt. ;) Azóta rengeteg dolgot beleraktak, de attól még nem lett szövegfeldolgozó nyelv.

A fentiekből következik, hogy az ősi std programokhoz vagyok hozzászokva. Néha elképedek a késhegyre menő vitákon, miszerint a (g)awk galaxiskutatásra optimalizát funkcióival mi mindent lehet megvalósítani. ;) A szövegfeldolgozás egyszerű: input -> feldolgozás -> print. Persze lehet cicomázni, de ennél soha nem több. Nem szükséges pl. parancssori könyvelőprogramot írni. ;)

Ebből következik, hogy még nem is használtam se Perl-t, se Python-t. Ha pl. hálózat vagy adatbázis elérésre van szükségem, az biztosan a program másik pontján helyezkedik el. De volt már arra is példa, hogy a hálózati/lokális adatbázis elérését belefordítottam a C szövegfeldolgozásba - mind a 10 sort, mert 8M rekordnál nem lehetett másképp csinálni.

Hasonlóan vélekedek a PHP és JavaScript nyelvekről. Nagyon minimális ismereteim vannak róluk, de rossz tapasztalatok is. Egyrészt néha definiáltan pongyola az alapfüggvények implementációja. Másrészt a magasszintűeké is. ;) Kedvencem a pfSense: tűzfal PHP-ban. Bár azok a PHP guruk is inkább a man-t olvasgatták volna, akkor nem kellet volna belenyúlnom. :(

Írtam már 6 weboldalt kiszolgáló és hálózati adatbázist lekérdező  cgi-t 120 sor C-ben. (persze volt egy header meg egy css is) Elvégre a cgi==parancssor. ;)

Viszont alapvetően 100%-ban nem írok sem olyan programot, aminek képernyője van, sem parancssori programot. Amit írok, azt végesállapotú gép futtatja. (Nnnna, most jön a hencegés.) Ebben a témakörben a hattyúdalom egy 12 éve működő backup rendszer. A hálózaton 125 irányban kommunikál, átlagosan 2 másodpercenként épít fel egy kapcsolatot, és közben kapcsolatonként 1kB..5GB adatot mozgat. Naponta >80M processzt futtat és teljesen automatikusan működik. Jelenleg 36.968.224 mentést kezel nettó 30TB mennyiségben. Nem, nem ASM ;), hanem shell script és társai meg C.

( asch v | 2020. 12. 07., h – 00:27 )

Van aki sajtreszelővel szereti...

Mit futtatsz a rútereden? Úgy értem mit akarsz futtatni rajta?

OpenWrt/LEDE az oprendszer, kicsi szappantartó router-en fut. GeoIP adatbázis frissítés a cél. Mondjuk egy 1.2.3.4/22 formából kell előállítani azt, hogy 01 02 00 00 01 02 03 ff, már feltéve, ha most fejben jól számoltam. Az input ASCII text, az output már binárisan értendő. Aztán ugyanez ipv6-ra. Tehát a cím/mask_length párosból kell alsó és felső címet mondani, azaz intervallumot.

C-ben nagyon egyszerű, de semmi kedvem OpenWrt SDK-t telepíteni, és mips_24kc-re fordítani. Az awk-t ismerem, C-szerű a szintaxisa. Ez nem gawk egyébként, hanem annál butább szerkezet, például nem ismeri a switch case szerkezetet.

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

Én szeretek programozni, megírom, meg aztán elég sok megoldási lehetőség van. Az egyik, hogy megtanulom a Python-t, Lua-t, akármit, a másik, hogy ASCII hex dump-ot generálok awk-val, majd azt xxd-vel binárissá alakítom. Vagy megírom C-ben, de előbb felteszem az OpenWrt/LEDE SDK-t a gépemre. Vagy virtuális gépre.

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

Erre pedig ideális a Lua. Fel van telepítve, hiszen a Luci (OpenWRT webes adminfelülete) is Lua-ban van írva.

És hogy ne kelljen sokat tökölni, itt van egy majdnem tökéletes, csak picit kell átalakítani: https://github.com/Fizzadar/Lua-Bits/blob/master/ipv4.lua
Lásd a fene jó szívemet :)
       http://hg2ecz.ham.hu/tmp/ipv4-locsemege.lua
Bináris kiíráshoz pedig: io.write( string.format("%c%c%c%c%c%c%c%c", ...
(io.write ... mert a print hozzáad még egy sorvégjelet is.)

( bucko | 2020. 12. 07., h – 01:22 )

Bevallom, minél többet olvasgatom, annál jobban nem értem. ;)

Gondolom, a bináris adatoknak van valamilyen formátuma. Ebben az esetben:

C és egy db printf() (rekordtípusonként) | awk - kész.

A gawk kiválóan ír bináris adatokat a printf() segítségével.

( locsemege v | 2020. 12. 07., h – 17:10 )

Hogy lehet ilyen rosszul megcsinálni egy programnyelvet?

awk 'BEGIN {for (i = 0; i < 256; i++) printf("%c", i);}' | hexdump -C

00000000  01 02 03 04 05 06 07 08  09 0a 0b 0c 0d 0e 0f 10  |................|
00000010  11 12 13 14 15 16 17 18  19 1a 1b 1c 1d 1e 1f 20  |............... |
00000020  21 22 23 24 25 26 27 28  29 2a 2b 2c 2d 2e 2f 30  |!"#$%&'()*+,-./0|
00000030  31 32 33 34 35 36 37 38  39 3a 3b 3c 3d 3e 3f 40  |123456789:;<=>?@|
00000040  41 42 43 44 45 46 47 48  49 4a 4b 4c 4d 4e 4f 50  |ABCDEFGHIJKLMNOP|
00000050  51 52 53 54 55 56 57 58  59 5a 5b 5c 5d 5e 5f 60  |QRSTUVWXYZ[\]^_`|
00000060  61 62 63 64 65 66 67 68  69 6a 6b 6c 6d 6e 6f 70  |abcdefghijklmnop|
00000070  71 72 73 74 75 76 77 78  79 7a 7b 7c 7d 7e 7f 80  |qrstuvwxyz{|}~..|
00000080  81 82 83 84 85 86 87 88  89 8a 8b 8c 8d 8e 8f 90  |................|
00000090  91 92 93 94 95 96 97 98  99 9a 9b 9c 9d 9e 9f a0  |................|
000000a0  a1 a2 a3 a4 a5 a6 a7 a8  a9 aa ab ac ad ae af b0  |................|
000000b0  b1 b2 b3 b4 b5 b6 b7 b8  b9 ba bb bc bd be bf c0  |................|
000000c0  c1 c2 c3 c4 c5 c6 c7 c8  c9 ca cb cc cd ce cf d0  |................|
000000d0  d1 d2 d3 d4 d5 d6 d7 d8  d9 da db dc dd de df e0  |................|
000000e0  e1 e2 e3 e4 e5 e6 e7 e8  e9 ea eb ec ed ee ef f0  |................|
000000f0  f1 f2 f3 f4 f5 f6 f7 f8  f9 fa fb fc fd fe ff     |...............|
000000ff

Nem túl meglepő módon a 0 hiányzik belőle. Ez a Busybox-féle awk.

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

Gawk? Öhöm ... Ubuntu:

$ /usr/bin/gawk 'BEGIN {for (i = 0; i < 256; i++) printf("%c", i);}' | hexdump -C
00000000  00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|
00000010  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  |................|
00000020  20 21 22 23 24 25 26 27  28 29 2a 2b 2c 2d 2e 2f  | !"#$%&'()*+,-./|
00000030  30 31 32 33 34 35 36 37  38 39 3a 3b 3c 3d 3e 3f  |0123456789:;<=>?|
00000040  40 41 42 43 44 45 46 47  48 49 4a 4b 4c 4d 4e 4f  |@ABCDEFGHIJKLMNO|
00000050  50 51 52 53 54 55 56 57  58 59 5a 5b 5c 5d 5e 5f  |PQRSTUVWXYZ[\]^_|
00000060  60 61 62 63 64 65 66 67  68 69 6a 6b 6c 6d 6e 6f  |`abcdefghijklmno|
00000070  70 71 72 73 74 75 76 77  78 79 7a 7b 7c 7d 7e 7f  |pqrstuvwxyz{|}~.|
00000080  c2 80 c2 81 c2 82 c2 83  c2 84 c2 85 c2 86 c2 87  |................|
00000090  c2 88 c2 89 c2 8a c2 8b  c2 8c c2 8d c2 8e c2 8f  |................|
000000a0  c2 90 c2 91 c2 92 c2 93  c2 94 c2 95 c2 96 c2 97  |................|
000000b0  c2 98 c2 99 c2 9a c2 9b  c2 9c c2 9d c2 9e c2 9f  |................|
000000c0  c2 a0 c2 a1 c2 a2 c2 a3  c2 a4 c2 a5 c2 a6 c2 a7  |................|
000000d0  c2 a8 c2 a9 c2 aa c2 ab  c2 ac c2 ad c2 ae c2 af  |................|
000000e0  c2 b0 c2 b1 c2 b2 c2 b3  c2 b4 c2 b5 c2 b6 c2 b7  |................|
000000f0  c2 b8 c2 b9 c2 ba c2 bb  c2 bc c2 bd c2 be c2 bf  |................|
00000100  c3 80 c3 81 c3 82 c3 83  c3 84 c3 85 c3 86 c3 87  |................|
00000110  c3 88 c3 89 c3 8a c3 8b  c3 8c c3 8d c3 8e c3 8f  |................|
00000120  c3 90 c3 91 c3 92 c3 93  c3 94 c3 95 c3 96 c3 97  |................|
00000130  c3 98 c3 99 c3 9a c3 9b  c3 9c c3 9d c3 9e c3 9f  |................|
00000140  c3 a0 c3 a1 c3 a2 c3 a3  c3 a4 c3 a5 c3 a6 c3 a7  |................|
00000150  c3 a8 c3 a9 c3 aa c3 ab  c3 ac c3 ad c3 ae c3 af  |................|
00000160  c3 b0 c3 b1 c3 b2 c3 b3  c3 b4 c3 b5 c3 b6 c3 b7  |................|
00000170  c3 b8 c3 b9 c3 ba c3 bb  c3 bc c3 bd c3 be c3 bf  |................|
00000180

( zeller | 2020. 12. 07., h – 17:25 )

A busybox-os awk-ból hiányzik, ez igaz. De nem az awk-ból magából.

Leteszteltem FreeBSD-n:

gawk: GNU Awk 5.1.0, API: 3.0

mawk: Version        : 1.3.4.20190203

nawk: awk version 20121220 (FreeBSD)

goawk: v1.6.1

Ezek mindegyike jól működik (a Gnu-féle igényli a LANG beállítást.)

biziboxom nincs a FreeBSD-n

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

( locsemege v | 2020. 12. 12., szo – 12:03 )

Közben azt is megranultam, hogy az xxd -r valami ilyesmit vár:

00000000: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
00000010: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f

Szóval az elejére kell cím és kettőspont. Sebaj, awk-ból semmiből sem áll előállítani ezt így.

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

Köszönöm, ki fogom javítani, mert noha most jó, de felesleges a bonyolítás. Most épp azzal küzdök, hogy OpenWrt service-t faragjak belőle - már nagyjából megvan -, viszont valamiért IPV6-ra nulla hosszúságú file generálódik, pedig a korábbi tesztemben még jó volt.

Szerk.: Bár lehet, meghagyom a mostani formátumot, mert debugoláshoz ez sokkal szebb.

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

( locsemege v | 2020. 12. 12., szo – 15:44 )

Szerkesztve: 2020. 12. 12., szo – 15:48

Ez lett belőle.

Szerk.: A végén a status() függvényben el van rontva az indentálás, de ez már így marad.

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