sed -- poznámky (nejen) pro mě (diskuse)

[kralyk z abclinuxu]

Pěkný, ale přidal bych ještě příkaz t [label] - skočí na label (nebo na konec, když label chybí), pokud byla poslední substituce úspěšná. To se hodí když např. chci ze souboru ostranit nějaké řádky podle nějakého regexpu:

sed -n 's/...//;t;p;'

[Begleiter]

Abych se přiznal, tak zrovna tenhle příkaz mi není moc jasný. Teprve až ho pochopím, tak ho určitě přidám. Jinak díky.

[Ondřej Kubečka]

Zde dochází na to, že sed toho vlastně umí více, než je často vidět ve skriptech. sed -ne 's/...//;t;p;' zrovna není štastný příklad, protože téhož asi raději dosáhneme čitelnějším: sed -e '/.../d'. Ale jsou situace, kdy se hodí. b je prostý skok, t skok podmíněný (nahrazení s proběhlo od začátku zpracování toho řádku). Do téhle kategorie patří i "hold space" (g, G, h, H, x) a možnost spojovat řádky na vstupu (N).

Pravdou nicméně je, že když na tyto prostředky dojde, možná je na čase zvážit jiný nástroj (třeba awk). sed sice mnoho dokáže, ale složitější konstrukce se dle mého špatně čtou. Takže pro pobavení/potěšení stojí za to zkusit čistě sed řešení problému, ale nemusí to být nutně řešení nejpraktičtější.

Čeho bych se raději vyvaroval (prostě je to nepěkná forma (a trochu plýtvání prostředky) jsou pekelné roury tak časté v mnoha skriptech: grep ... | awk ... | sed ... | grep -v ... | tr ... | ... v libovolných sekvencích a opakováních. Všechny tyto úkony je lépe svěřit jednomu sed nebo awk skriptu.

Pokud máte rád knihy a hezky utříděné informace: <http://oreilly.com/catalog/9781565922259>.

[Begleiter]

Díky

[xkucf03]

Čeho bych se raději vyvaroval (prostě je to nepěkná forma (a trochu plýtvání prostředky) jsou pekelné roury tak časté v mnoha skriptech: grep ... | awk ... | sed ... | grep -v ... | tr ... | ... v libovolných sekvencích a opakováních. Všechny tyto úkony je lépe svěřit jednomu sed nebo awk skriptu.

Z hlediska výkonu souhlas – ale co se týče přehlednosti, tak IMHO bude většinou vycházet líp, rozdělit to na víc menších srozumitelných částí, než jeden ultimátní skript. Jasně, dá se okomentovat, ale pokud to někdo píše na jednu řádku, tak mi přijdou přehlednější ty roury.

[Ondřej Kubečka]

Pravda, tohle jsem nenapsal zcela jasně. Mám na mysli skript, kde bych to měl obecně nalámat pro lepší čitelnost. Co si člověk napíše na řádku (a nikdo ani on sám to po sobě nebude muset louskat), je mnohem volnější žánr. :)

[Begleiter]

Hezká ukázka toho, jak může být sed užitečný (nastavení dynamického linkeru, který má gcc používat).

[anonym]

Hezke shrnuti. Musim ale rict, ze od doby co jsem se trochu naucil perl, mi uz sed prijde torchu zbytecny - musim si pamatovat dalsi prepinace, specificky druh regexpu atd.

No, mozna to stejne nekdy vyuziju, kdyz nebude nainstalovany perl.

[David Watzke]

sed nepoužívá specifický druh regexpů, to spíš Perl má svoje rozšíření

[CEST]

sed nepoužívá specifický druh regexpů, to spíš Perl má svoje rozšíření

Tak tak, ale PCRE ma "hezci" syntaxi. Obvykle musim v sedu psat spoustu zpetnych lomitek v regexpech. Navic, kdyz uz umim perl, da se pouzit jako grep, sed, awk a neco navic (ikdyz awk toho umi taky dost).

[Michal Kubeček]

Obvykle musim v sedu psat spoustu zpetnych lomitek v regexpech.

Protože z historických důvodů používá Basic RE. U GNU sedu to řeší přepínač -r

[Begleiter]

Děkuju za ocenění.

[jeleniste]

Príma

[jeleniste]

jo, šikovnej je taky přepínač -i, kterym se přepíše původní soubor.

[pavlix]

Používám téměř denně, mimojiné na zónové soubory DNS.

[David Watzke]

Jojo, já taky, ale poděl je, že zruší symlink a udělá z něj normální soubor. Řešením by mělo být --follow-symlinks.

[pavlix]

Jojo, já taky, ale poděl je, že zruší symlink a udělá z něj normální soubor. Řešením by mělo být --follow-symlinks.

To bych neviděl jako problém :), ale proti --follow-symlinks nic nemám.

[David Watzke]

Je to docela problém, když máš třeba vhosty apache v /etc/apache2/sites-available a v sites-enabled pouze odkazy na ty povolený a pak se rozhodneš in-place editovat soubor přes symlink... Podle mě by --follow-symlinks měla být implicitní volba. Ale důležitý je hlavně o tomto vědět, pak si na to člověk dá bacha.

[kralyk z abclinuxu]

To je imho kvůli standardu. Standard nic jako --follow-symlinks pochopitelně neobsahuje a gnu nástroje mají být (afaik) nadmnožinou standardu, takže odtud takovéhle podivnosti. Je bohužel mnohem jednoduší přidat si vlastní extension než snažit se pohnout se standardem, ačkoli by to bylo v tomhle i mnoha dalších případech lepší.

[pavlix]

Já na takovéhle věci (například grep --color) používám aliasy. Funguje to a neovlivňuje to skripty.

[Michal Kubeček]

To je imho kvůli standardu. Standard nic jako --follow-symlinks pochopitelně neobsahuje a gnu nástroje mají být (afaik) nadmnožinou standardu,

Požadavek, aby implementace byla nadmnožinou standardu, nijak nebrání tomu, aby si přidala další přepínače, které POSIX nepožaduje - což je ostatně i samotný -i (přesněji: všechny kromě -e, -f a -n).

[Michal Kubeček]

Aha, trefil jsem se vedle. Ale i tady: vzhledem k tomu, že už samotný přepínač -i je GNU rozšířením, nelze default vysvětlovat POSIXem, ale jen zpětnou kompatibilitou.

[kralyk z abclinuxu]

Aha, mi uniklo že i -i není posix, no tak to je potom ještě blbější výmluva...

[xkucf03]

V tom případě by se měly odkazy sledovat a opak by šlo nastavit přepínačem.

[pavlix]

Je to docela problém, když máš třeba vhosty apache v /etc/apache2/sites-available a v sites-enabled pouze odkazy na ty povolený a pak se rozhodneš in-place editovat soubor přes symlink...

Stačí nelézt, kam nemáš :).

Podle mě by --follow-symlinks měla být implicitní volba.

Podle mě spíše ne. Mám radši, když nástroje dělají přesně to, co jim řeknu.

Ale důležitý je hlavně o tomto vědět, pak si na to člověk dá bacha.

Tak.

[xkucf03]

Mám radši, když nástroje dělají přesně to, co jim řeknu.

No právě – proto bych tady spíš čekal, že dojde k úpravě souboru (ne navíc ke smazání odkazu a uložení obyčejného souboru místo něj). Argument s kompatibilitou beru – ale logičtější by to bylo takhle.

[pavlix]

o právě – proto bych tady spíš čekal, že dojde k úpravě souboru (ne navíc ke smazání odkazu a uložení obyčejného souboru místo něj). Argument s kompatibilitou beru – ale logičtější by to bylo takhle.

Mno mě to přijde logičtější naopak. Protože kdyby sed tu volbu neměl, soubor bych si přejmenoval, dal ho sedu na vstupu a výstupu dal jeho původní jméno. Měl bych tedy stejný výsledek, jako má sed -i, proto mi to přijde přirozenější.

[xkucf03]

Ale zase kdybys to otevřel v kterémkoli jiném editoru (vim, emacs, mcedit, kate, gedit, jedit…), jak by se to chovalo?

[pavlix]

Nesmíš se nechat zmást tím, že to má v názvu ed.

[xkucf03]

Jednou je to stream editor, tak je to stream editor

A nejde jenom o editory – ty symbolické odkazy respektuje prakticky každý program – nebo když do toho odkazu nasměruji standardní výstup (třeba příkazu echo ahoj), tak se taky zapíše skrze odkaz do cílového souboru – nepřepíše se ten odkaz obyčejným souborem.

Navíc sed zachovává přístupová práva – taky proto bych čekal, že zachová symbolický odkaz.

Zajímavě se to chová taky při použití pevných odkazů:

$ echo 111 > soubor1.txt
$ ln soubor1.txt soubor2.txt 
$ sed -i s/1/2/g soubor2.txt 
$ cat soubor2.txt
222
$ cat soubor1.txt
111

Opět to původní soubor smaže a vytvoří úplně nový – místo aby to editoval „na místě“ v tom stejném souboru.

Beru to prostě jako záludnost, na kterou je potřeba si dávat pozor, nějakou logiku v tom ale nevidím (kromě té snahy o kompatibilitu, což už jsem tu psal).

[pavlix]

Jo, jenže ty se zaměřuješ na slovo editor, které je spíše nadsázkou, zatímco já si plně uvědomuju slovo stream.

Navíc sed zachovává přístupová práva – taky proto bych čekal, že zachová symbolický odkaz.

Navrácení přístupových práv je bezpečné, u toho následování linků si tak jistý nejsem.

Opět to původní soubor smaže a vytvoří úplně nový – místo aby to editoval „na místě“ v tom stejném souboru.

On sed je proudový, takže by bylo dost zvláštní, kdyby něco editoval opravdu na místě.

Beru to prostě jako záludnost, na kterou je potřeba si dávat pozor, nějakou logiku v tom ale nevidím (kromě té snahy o kompatibilitu, což už jsem tu psal).

Kompatibilita je pouze zachvávání určitého stavu, ne jeho vytváření :).

[kralyk z abclinuxu]

Jednou je to stream editor, tak je to stream editor

Tak tak, nikoli file editor :p

Nadruhou stranu souhasím, že když in-place, tak teda in-place, čili jako každá jiná slušná utilita...

[pavlix]

Já to in-place nikdy nebral tak úplně in-place vzhledem k souboru, jako spíš vzhledem k aktuálnímu adresáři, kde hromadnou editaci provádím. Záleží na úhlu pohledu.

[Ondřej Kubečka]

Jojo, já taky, ale poděl je, že zruší symlink a udělá z něj normální soubor. Řešením by mělo být --follow-symlinks.

Nebo použít ed. Poštvat ho na daný soubor k editaci a instrukce mu nakrmit na standardní vstup (třeba pomocí here documents) ;)

[Aleš Kapica]

Jo. Právě na tohle ed používám. Viz můj postarší manuálek pro ed na wikibooks. Zrovna se mi nedávno hodil.

[Begleiter]

Díky

[CEST]

zajimave prikazy jsou take "h"/"H' a "g"/"G" - kopirovani textu mezi pattern space a hold space

[Begleiter]

Díky