jq a xmlstarlet - utility pro zpracování strukturovaných dat (diskuse)

[Kalašnikov]

U shellových skriptů, si většinou vystačíte s jednoduchým textovým souborem

Se souborem si vystačíme všude tam, kde nám stačí jednoduchá struktura typu seznam a jsme ochotni obětovat jeden znak jako oddělovač. Se shellem to nijak nesouvisí, nebo jo?

[Aleš Kapica]

Když píšu o nástrojích, které lze využít ke zpracování konfigurace ve strukturovaném formátu v rámci shellových skriptů, tak asi jo.

[Kalašnikov]

A co myslíte tou složitější konfigurací v shellu? Nestačilo by prostě source initfile nebo v shellu jen tečka pro inklůdnutí kousku kódu s init nastavením?

[Aleš Kapica]

Třeba něco takového:

[WRAPPER_B]
socket = /tmp/xnbd_wrapper.B.ctl
port = 8250
volumes = ['/testovaci/disc.img' ,'/testovaci/cd.iso']
address = localhost

[WRAPPER_A]
socket = /tmp/xnbd_wrapper.A.ctl
port = 777
volumes = ['/next/disc.img' ,'/next/cd.iso']
address = 10.0.0.1

Podotýkám, že v tomto případě nejde o konfiguraci shellového skriptu, nýbrž pouze o ukázku toho co považuji za složitější konfiguraci.

[Kalašnikov]

A co je špatného na takovém konfiguráku?

socket_A = '/tmp/xnbd_wrapper.B.ctl'
port_A = 8250
volumes_A = ('/testovaci/disc.img' ,'/testovaci/cd.iso')
address_A = localhost

socket_B = '/tmp/xnbd_wrapper.A.ctl'
port_B = 777
volumes_B = ('/next/disc.img' ,'/next/cd.iso')
address_B = '10.0.0.1'

, který se pak inklůdne (v shellu) a mám hned inicializované proměnné k dispozici bez jakéhokoliv potřebného parsovacího modulu.

[Aleš Kapica]

Kupř. názvy proměnných. Každopádně se ale rozebíráním téhle marginálie dostáváme úplně jinam, než kam mířil blogpost. Ten není o tom, jak optimálně řešit konfigurační soubor, ale o nástrojích, které lze s výhodou využívat pro zpracování XML a JSON formátu v shellovém prostředí.

[Kalašnikov]

Názvy proměnných vám udělám stejné, jaké vám je udělá ten parser, když budete chtít. Při nějakém zpracování v cyklu se pak nechají vytvářet dynamicky prostě příkazem eval a tedy takových nastavení může být v konfiguráků od A-Z. Jedinou slabinou může být bezpečnost, aby vám do toho někdo nevložitl nějaký, ošklivý příkaz, ale to stačí před inklůdnutím projet nějakým regulárním výrazem a případně vyhodit chybu. - Co takhle přiznat, že ty první dva odstavce jste psal, aniž byste věděl vo co go. Proti druhé půlce - třetímu a čtvrtému odstavci - už v zásadě nic nemám. Programování není politika. Nazdar!

[Aleš Kapica]

A co takhle si uvědomit, že jste tématicky mimo mísu? V poradně tady každou chvíli někdo řeší, jak pomocí shellu zpracovat XML, JSON, nebo něco podobného. A tohle jsou právě ty nástroje, které jsou k tomu třeba.

[Bedňa]

Nech mi Franta odpustí, ale XML je formát kde v reále sú hrôzy aka toto:

<category>
	<sub page_id="74823" parent_page_id="20331">
		<![CDATA[PowerBanky]]>
	</sub>
	<sub page_id="75681" parent_page_id="20338">
		<![CDATA[Nabíjačky]]>
	</sub>
	<sub page_id="71290" parent_page_id="20338">
		<![CDATA[Univerzálne nabíjačky]]>
	</sub>
	<sub page_id="72975" parent_page_id="">
		<![CDATA[]]>
	</sub>
	<sub page_id="74824" parent_page_id="">
		<![CDATA[]]>
	</sub>
	<sub page_id="75676" parent_page_id="20338">
		<![CDATA[Mobilné a telefónne príslušenstvo]]>
	</sub>
	<sub page_id="76162" parent_page_id="20331">
		<![CDATA[Energia na cesty]]>
	</sub>
</category>

Nechcelo sa mi hľadať tie najhošie, kde sú niektoré suby prázdne a inak posraté, nepoznám parser ktorý by to rozchodil, preto používam svoj vlastný.

Tie parseri nevedia rozchodiť rovnaký tag z/bez atributov a ešte keď sa tam opakujú rovnaké hodnoty atribútov a tagov. Samozrejme je tam niekedy jeden sub a pri ďalšej položke 15 subov.

Je pravda, že teoreticky by to šlo vyexportovať do XML aj cez tagy a hodnoty, ale proste také XML v reále od nikoho nedostaneš, takže môj parser tie suby čísluje 1,2,3 ... inak to proste do ničoho neskonvertuješ a ani tabuľkové procesory to nerozchodia, teda už z podstaty nemajú ako.

Každé väčšie XML má proste nejaký skurwený formát, entity a ja neviem čo. Jako momentálne dokážem vyťahať údaje hádam z každého XML, ale chvíľu mi trvalo než som nad tým vyhral.

Ono väčšina tých úplných parserov je ľahko hacknutelných, pretože je tam ešte podpora ťahania dát z externých súborov.

[ehm]

XML je formát kde v reále sú hrôzy aka toto

S dovolením bych to přeformuloval: V XML je možné vytvořit dokument, který není well-formed.

[Martin Mareš]

Račte prominout, ale XML i JSON jsou pro ručně editovanou konfiguraci naprosto nevhodné. Editují se dost nepříjemně: v XML je spousta balastu, JSON pro změnu neumí tak základní věci jako komentáře, 64-bitová celá čísla a čárky za poslední položkou seznamu.

YAML, ačli nechutně složitý, je proti tomu hvězdou první velikosti.

[JS1]

Napsal jsi to strucne a naprosto pravdive. A YAML je opravdu slozity, vzdycky, kdyz koukam na nejaky konfigurak v nem, tak je velmi tezke uhodnout, jaka syntaxe se vlastne pouziva (na to abych si to pamatoval ho pouzivam prilis malo).

Je neco cemu bys ty osobne dal prednost?

[little-drunk-jesus]

JSON je v podstate podmnozinou YAMLu a parser to zvladne, takze muzes psat vse v JSON syntax a pouzivat casti YAMLu, ktere zrovna potrebujes.

[Martin Mareš]

Je neco cemu bys ty osobne dal prednost?

Bohužel je to bída s nouzí...

Pro své projekty psané v Céčku používám konfigurační mechanismus z LibUCW, ale nikdy jsem se nedostal k napsání slušných bindingů pro jiné jazyky, mimo jiné proto, že je to celé snad až příliš ukotvené v typovém systému Céčka.

Jinak používám různé omezené podmnožiny YAMLu, ale skřípu nad tím zuby od doby, kdy jsem si zkoušel napsat vlastní YAMLový parser :)

[Aleš Kapica]

A já snad někde psal, že se taková konfigurace musí nutně zpracovávat ručně?

Stačí se podívat kupř. na takový pacemaker. Ten sám o sobě udržuje konfiguraci v XML, ale pro práci s ní se používají hned dva nástroje pcs a crmsh, které ji překládají z a do human friendly podoby.

[Kalašnikov]

Možná bysme tedy mohli rovnou přejít na binárky.

[GeoRW]

no mozes kludne pouzit sqlite

[trekker.dk]

Jo, přesně o tomhle o diskuzi vedle mluvil Heron - je úplně jedno, jak si program uchovává konfiguraci, když poskytuje nástroje, jak ji snadno editovat.

[Aleš Kapica]

U svých skriptů se složitější konfigurací pracuji jednak s konfigurací v /etc/default, přes kterou lze měnit výchozí hodnoty globálních proměnných a pak (pokud je to nutné) s dílčí konfigurací která se může spravovat přímo skriptem.

Zrovna teď si píšu tool, který umožňuje řídit virtuály v situaci, kdy potřebuji mít z nějakého důvodu odstavený pacemaker. Na jejich řízení (pokud je pacemaker aktivován a služba ve stavu managed) mám svého agenta, který pracuje přímo s QEMU. Nepotřebuji tedy žádný libvirt ani omáčku kolem. Psal jsem o tom před časem v blogpostu o parametru utilization v konfiguraci pacemakeru. Ten tool tedy pracuje se zcela identickou výchozí konfigurací, ale protože nabízí i další možnosti, které původní kvm agent nemá, uvažuji o její paralelní interpretaci v JSON formátu, která by se využívala kupř. při uspání stroje, modifikaci konfigurace VM za běhu, nebo při live migraci. Před šesti lety jsem si už jeden takový tool napsal, možná by byl i použitelný, ale byl závislý i na aplikacích které nejsou běžnou součástí standardní instalace, takže bych ho stejně musel téměř celý přepsat.

[Martin Mareš]

Slušná textová konfigurace má tu výhodu, že na ni nepotřebuji speciální nástroj šitý na míru konkrétní aplikaci, ale mohu využívat bohatství nástrojů pro práci s textem, které mi každý unixový systém nabízí.

Typický případ, kdy se to projeví, je udržování konfigurace na více strojích, přičemž některé z nich mají různé lokální změny. Se slušnými textovými konfiguráky řešitelné vcelku snadno třeba Gitem. S méně slušnými je to řešitelné také, ale řešení konfliktů mezi různými verzemi souboru v XML není zrovná má oblíbená kratochvíle. A muset se ke konfigurákům různých programů chovat úplně jinak, to už by bylo vyslovené peklo.

[trekker.dk]

Tak v té diskuzi šlo zrovna o Postfix a postconf - kde je konfigurace textová a postconf umožňuje vypsat jenom ta nastavení, která se odlišují od výchozích hodnot.

A je to obráceně - ne o tom, že bych potřeboval specifální nástroj šitý na míru aplikaci, ale že aplikace sama umožní manipulovat se svojí konfigurací. Pacemaker zmíněný o kousek výš je ukázkový příklad. Je mi jedno, že je konfigurace uložená v XML, pomocí crm si ji můžu vypsat v textové podobě a - pro mě za mě - prohnat skrz diff, například.

[Aleš Kapica]

Co takhle vyzkoušet augeas?

[Josef Kufner]

JSON na konfiguraci není zas až tak špatný. Sice chybějící komentáře jsou opravdu velký nedostatek, ale pokud je potřeba uložit pár hodnot a neočekává se moc častá ruční editace, je to docela dobře použitelné. Obzvlášť, pokud jazyk už ve „standardní“ knihovně obsahuje nástroje na práci s ním (např. PHP).

YAML už vyžaduje knihovnu a je docela složitý. (A XML je ještě horší hrůza.) Ale i tak se YAML docela chytil a na webu (PHP) se hojně používá.

Kdyby JSON měl komentáře, toleroval čárku a nepožadoval uvozovky kolem klíčů v objektech, bylo by to docela dobře použitelné i na konfiguraci. Na druhou stranu, právě absence komentářů umožňuje JSON snadno načíst a uložit bez ztráty dat (komentářů) a bez komplikací se zachováváním takových dat (viz asi 15 typů uzlů v XML), což ho činí skvělým na čistě strojové zpracování.

[RM]

což ho činí skvělým na čistě strojové zpracování

Tak jasně, pokud dojde k tomu, že si musíme někam odkládat složitější datové struktury, pak se JSON (případně jiné vhodnější) pro to může hodit. Pokud to není konfigurák, pak si data může každý uložit sám, jak uzná za vhodné. Já bych třeba v Perlu použil jednoduchý modul 'Storable', který se mi o to postará. Soubor je pak texťák, ale takový, aby byl co nejlépe a nejrychleji zpracovatelný strojově, takže je pro "čtenáře" skoro nečitelný. I takto optimalizovaný formát se mi ale zdá být při načítání/ukládání nějakého rozsáhlejšího rozvětveného slovníku pomalý.

Zkrátka je asi na pováženou, jestli takové odkládání složitějších datových struktur je vůbec dobře odvedená práce programátora ;). A pokud se jedná jen o něco plochého, pak je zase na pováženou, jestli nebude podstatně rychlejší načíst/uložit seznam (z/do souboru nebo databáze) a udělat si parser (v Perlu to pravděpodobně vyjde jen na pár řádek kódu s regulárním výrazem). -- Případně pro odložení jen pár hodnot bych použil k sestavení formát jazyka a prostě pak ten soubor includnul. Takže já zatím nevidim pro JSON a jiné v této oblasti rozumné využití.

[trekker.dk]

Já bych třeba v Perlu použil jednoduchý modul 'Storable', který se mi o to postará. Soubor je pak texťák, ale takový, aby byl co nejlépe a nejrychleji zpracovatelný strojově, takže je pro "čtenáře" skoro nečitelný.

<rejp>Neplatí tohle náhodou i pro zdrojáky v tom perlu?</rejp>

[RM]

Rozdíly tam jsou, pokud rejpnutí dobře rozumim. Použití modulu 'Storable' bude minimálně bezpečnější.

[RM]

ok, ten druhý význam, kdy nejde o include, tedy beru s humorem

[Martin Mareš]

Tak jasně, pokud dojde k tomu, že si musíme někam odkládat složitější datové struktury, pak se JSON (případně jiné vhodnější) pro to může hodit.

Mimochodem, docela zajímavý je k těmto účelům CBOR. Sémantika podobná jako JSON, ale je binární a mnohem efektivnější jak časově, tak prostorově.

[JS1]

CBOR je skvely format, bohuzel ho (z moji zkusenosti) temer nikdo nezna..

[Aleš Kapica]

Chybějící komentáře? JSON nabízí X možností jak ten problém řešit. Teda, pokud si sám navrhuji jak má vypadat.

[Martin Mareš]

Myslíte X poměrně ošklivých obezliček? ;)

[Aleš Kapica]

Absolutně netuším kam tím míříte. Pokud potřebuji komentáře, k obsahu konfigurace, přidám si potřebný element. Pokud chcete komentovat JSON jako takový, pak nechápu proč.

[Kalašnikov]

Hele di už do politiky!

[Martin Mareš]

Třeba takto: v konfiguraci je pole IP adres, na kterých má server poslouchat. Já si k jedné z nich chci připsat komentář, že je dočasná a že ji mám časem zrušit. Jak to udělám?

[Aleš Kapica]

Třeba takhle?:

[
  {
    "interfaces": [
      {
        "device": "eth1",
        "ipv4": "10.0.0.12",
        "timestamp": 1500558336,
        "note": "Odstavit až vyprší čas"
      },
      {
        "device": "eth2"
      }
    ]
  }
]

[RM]

Jé, to je super. Já tedy JSON moc neznam, ale tohle se mi líbí. To bych mohl třeba v C psát další typ komentáře takhle:

array[0]="hrušky\0";
array[1]="jablka\0"
array[2]="#nějaký komentář\0"

[Kate]

Ano, rozhodně je to úplně to samé. Proboha…

[RM]

Co je na tom špatně? Já bych si ten element se znakem # parserem před použitím odfiltroval nebo bych poslední prvek pole nepoužíval a odečítal 1 při určování velikosti. Časem bych si udělal své API a třeba by se to pak i chytlo. Tak se tu nad tím hned nekřižujte :).

[Martin Mareš]

Psal jsem, že v konfiguraci je pole IP adres, nikoliv pole složitých objektů obsahujících IP adresy.

[Aleš Kapica]

A já jsem zase psal pokud si sám navrhuji jak má vypadat. A v blogu jsem hovořil o složitější konfiguraci. Na konfiguraci, která si vystačí s jednoduchým seznamem adres nebudu používat JSON, to dá rozum.

[Martin Mareš]

Složitá konfigurace často obsahuje spoustu jednoduchých částí. Myslím, že je hloupost pro každou z nich definovat zvláštní způsob, jak ukládat komentáře. Síla rozumných konfiguračních formátů tkví právě v tom, že autor aplikace se nemusí o komentáře a podobné věci starat a ony fungují samy od sebe.

[Aleš Kapica]

Mám dojem, že se tady míchají jabka s hruškama. Je totiž rozdíl, chci-li komentovat konfigurační soubor jako takový, nebo jednotlivé položky konfigurace. Polemizovat o tom, jestli je či není rozumný formát konfiguračního souboru mi přijde totálně mimo mísu, pokud plní svůj účel a je "opracovatelný" pomocí textového editoru.

Mým záměrem rozhodně není se dohadovat co je či není lepší. Každý ať si použije co chce. Do téhle slepé uličky jsme se dostali díky zcela banální větě, kterou jsem nastínil jednu z možných situací, při které se můžeme setkat s JSON formátem a nabídnout informaci o nástroji, který umožňuje jeho výstup nějak rozumně opracovat – toť vše.

Ale když už zde padlo několik názorů na to co je lepší, tak já kupř. upřednostňuji na systémové úrovni výhradně konfiguraci, kterou lze upravovat pomocí běžného texťáku. Tj. žádné databáze, žádné binární formáty. A mám pro to své dobré důvody.

[Martin Mareš]

Pro mě je zásadním problémem JSONu ještě to, že se v něm nedá přímo zapsat 64-bitové číslo. (A obecně to, že všechna čísla jsou floaty, takže když člověk napíše příliš velké číslo, dojde obvykle k tiché ztrátě přesnosti.)

[ehm]

AFAIK JSON tohle vůbec neřeší a specifikace se zaobírá jen textovou reprezentací čísla. Do jakého typu ti to načte parser už je záležitost implementace.

[JS1]

To je dobra poznamka - a poprve jsem si ji vsiml uz v tvem puvodnim prispevku, nikde driv jsem o tomto problemu neslysel. IMHO textovy format, ktery umi netypova cisla by mel zvladat libovolnou presnost (jinak receno, dekodovani a opetovne zakodovani by nemelo vest ke zmene informace).

[Martin Mareš]

Problém je, že specifikace JSONu (ono jich je různých "specifikací" víc, nejblíže tomuto pojmu je nejspíš RFC 7159) říká, že implementace má právo stanovit libovolná omezení na rozsah a přesnost čísel. Implementace si to vesměs vykládají tak, že čísla interpretují jako 64-bitové binární floaty dle IEEE 754.

[ehm]

Aha. Nevím, jak jsou na tom implementace třeba v C, ale referenční implementace pro Javu to má vyřešené dobře. Desetinná čísla to vždy ukládá jako double (což je v Javě taky 64-bit IEEE 754), celá čísla nejprve jako long, a pokud se to vleze do integeru, tak jako int. Viz #stringToValue.

Úplně správně bych si to tedy představoval tak, že pokud se to ani do jednoho z těchto typů nevleze, uloží se to jako BigInteger, resp. BigDecimal.

[Martin Mareš]

to má vyřešené dobře. Desetinná čísla to vždy ukládá jako double

... což mimochodem také může vést ke ztrátě přesnosti.

Úplně správně bych si to tedy představoval tak, že pokud se to ani do jednoho z těchto typů nevleze, uloží se to jako BigInteger, resp. BigDecimal.

No to já také, ale takovou implementaci jsem nejspíš ještě nepotkal.

Problém tkví právě v tom, že chování čísel je specifické pro implementaci, takže se na něj prakticky nemůžete spolehnout.

[Bedňa]

Komentáre idú v pohode všade. Proste si to dopíšeš do toho skriptu odkiaľ to odosielaš, načo ich posielať?

[ehm]

Wut? Jak to souvisí se zápisem konfigurace?

[Bedňa]

Jéj, tak som si spojil s diskusiou na inom servery,fail.

[ehm]

OK.

[Heron]

Možná jste i vy někdy řešili otázku, jaký formát použít pro uložení výchozí konfigurace vašeho skriptu či aplikace.

Ani ne. Vzhledem k tomu, že všechny moje bastly používají db, tak jediný konfigurák je connstring. Někdy ani to ne, pokud to běží lokálně, tak se to připojí na unix socket s auth pomocí ident. Veškeré další nastavení stejně jako data jsou potom v db.

Pokud už se vyloženě něco musí nastavovat, tak je konf soubor v syntaxe daného jazyka (python, bash), který se prostě includuje.