Dotaz: Prohození řádků

[he]

Prohození řádků. Potřebuji prohodit řádky, a to tak že první má být předposlední, druhý poslední, třetí -> čtvrtý od konce, čtvrtý -> třetí od konce, .., až předposlední -> první a poslední -> druhý. Studiem z tohoto odkazu http://sed.sourceforge.net/sed1line_cz.html jsem se dostal do stadia, že si dokážu pomoci pospojováním dvojic řádků (i s odmazáním počátečních mezer) a pak je jen přehodím příkazem tac, ale není to přesně ono: cat soubor | sed 's/^[ \t]*//' | sed '$!N;s/\n/ /' | tac. Nejsem v regulárních výrazech moc zběhlý a nevím, dá-li se to napsat jedním-dvěma příkazy. Budu vděčný za jakoukoli radu.

Odpovědi

[nettezzaumana]

#!/usr/bin/perl

use strict;
use warnings;

my @foo;
my @bar;

while(<>) {
push @foo, $_;
do { unshift @bar, @foo; @foo = (); } if @foo == 2;
};

print foreach @bar;

[nettezzaumana]

.. pokud jsem to teda pochopil spravne a melo to delat tohle:

> seq 1 6 | ./hehe
5
6
3
4
1
2
 

[he]

Ano, přesně toto. Ale jak to spustím? Ten skript jsem uložil jako hehe, ale když ho spustím jako cat soubor | ./hehe, tak mi to vyhodí bash: ./hehe: Permission denied. Nedám to ani přes sudo ani jako sudo cat soubor | seq 1 6 | ./hehe

[nettezzaumana]

hehe .. netreba ukladat jako hehe, ale proti gustu zadnej disputat .. hehe

co se tyce permissions denied, tak to tipuju na opomenute `chmod +x hehe` .. hehe ;)

 

.. aneb. musis tomu priradit executable flag :D .. muehehe

[he]

Jede to! Mám se ještě co učit, a hlavně základy. Tady je vidět, že v Perlu je skryt obrovský potenciál. Díky

[nettezzaumana]

np, urw

[salam]

hehe

[FooBar]

seq 1 6 | sed 'N;s/\([^\n]*\)\n\(.*\)/\2\n\1/' | tac

[nettezzaumana]

shell brainfucks Vs perl brainpetting?

nemam rad kod, u kteryho musim za tejde badat, *jak *jsem *to *k *certu *tenkrat *myslel ..

[Ash]

Pokud umíte perl, nemusíte u něj po týdnu bádat "jak jsem to k čertu myslel", prostě si to přečtete. Pokud umíte sed, nemusíte u něj po týdnu bádat "jak jsem to k čertu myslel", prostě si to přečtete.

Takže váš výlev říká jen prosté "buď mám krátkou paměť, nebo sed, nebo oboje, nebo 'nepíši do zdrojáků komentáře'". Ale se vším se dá něco dělat, pokud člověk chce, paměť se dá trénovat, sed se dá naučit a komentáře se dá naučit a zvyknout psát :)

[nettezzaumana]

muehehe .. nevim jake jsou Vase zkusenosti s programovanim, ale imho vetsina programatoru ma zpetne problem po urcite dobe *vratit se z5 do projektu, kterej napsali. alespon ja urcite, pac vetu ::

".. wtf, jak jsem to tenkrat myslel" si v duchu rikam pomerne casto .. ;)

btw. *se *svym sedovskym nebo perlovskym RE brainfuckem mam temer chronicke problemy

btw2. co se tyce tohodle konkretniho prikladu tak me by trvalo dat dohromady zadanou ulohu pomoci RE dele, nez nadatlit behem 30s (v zavislosti na rychlosti psani) z logickeho hlediska tuto elementarni ulohu v perlu ..

[he]

Poněvadž jsem svým dotazem rozpoutal diskusi zastánců dvou rozdílných táborů, rozhodl jsem se, že provedu malý test. Vzal jsem reálný textový soubor o velikosti ~3 MB a ~54 tisíc řádků a prohnal jej pokaždé třikrát sedem a perlem. Výstupem byla konzole v GUI. Zde jsou výsledky:

sed.time: 8.329s, 9.58s a 8.942s. avg.time=8.95033333s

perl.time: 8.59s, 8.44s a 7.94s. avg.time=8.32333333s

Porovnáním průměrných hodnot časů lze vypozorovat, že perl dává o 7% rychlejší odpověď.

Spustil jsem tedy ještě jeden test, tentokrát syntetický, s výstupem do /dev/null. time seq 1 1000000 | sed 'N;s/\([^\n]*\)\n\(.*\)/\2\n\1/' | tac > /dev/null: 7.161s, 7.277s a 7.201s. avg.time=7.213s

time seq 1 1000000 | ./hehe > /dev/null: 2.803s, 2.828s, 2.914s. avg.time=2.8483333333s

Zde si vedl perl o 60% lépe a to už nelze přehlédnout.

[Ash]

No ono vždy záleží na tom, jak moc "blbě" se to napíše. Takže začneme optimalizovat?

Mně zatím vychází lépe sed, předpokládám že to je tím, že ho umím lépe než perl, který jsem se tedy optimalizovat nesnažil ;)

bash$ time seq 1 1000000 | ./hehe > /dev/null

real    0m1.189s
user    0m1.764s
sys     0m0.056s

bash$ time seq 1 1000000 | sed -n 'h;n;p;g;p' | tac > /dev/null

real    0m0.862s
user    0m0.964s
sys     0m0.048s

[Ash]

Co do počtu znaků vede sed samozřejmě také, ale to asi už zůstane.

bash$ wc -c hehe
166 hehe

bash$ wc -c <<<"sed -n 'h;n;p;g;p' | tac"
25

[FooBar]

Sakra, hodit to do hold bufferu mne nejak vubec nenapadlo, dobry a elegantni!

[Petr]

Dobrý řešení, tady je ještě o 2 znaky kratší (a možná i rychlejší, ale neměřil jsem to), s vypuštěním mezer okolo svislítka dokonce o 4 znaky :)

$ wc -c <<<"sed -n 'h;n;G;p'|tac"
21
$

[Ash]

Ještě o znak sed 'x;n;$G' | tac pokud bych se povznesl nad prázdné řádky na konci :)

[Ash]

Vlastně to bylo o 4 znaky díky absenci -n

[Ash]

Jen škoda že je to pořád o jeden znak delší než perl ;)

sed 'x;n;$G'|tac 
#!/usr/bin/perl

[Ash]

Stále zůstáváme u toho, že umíte lépe perl než sed. Já umím lépe sed, takže bych tuto elementární úlohl napsal v sedu, vy umíte lépe perl, tak byste tuto elementární úlohu nadatlil v perlu. Pokud by nám záleželo na výkonu, tak bychom to oba nadatlili v tom, co by bylo výkonnější.

Vracet se k staršímu projektu je vždycky trochu náročné a programátor, který se má rád, asi programuje tak, aby to po sobě i po delší době přečetl, a nesnaží se o nějakou optimalizaci algoritmů hraničící s kryptografií (vyjma kritických míst samozřejmě, tam pak nastupují dekryptovací komentáře :D)

[Ash]

No ono vždy záleží na tom, jak moc "blbě" se to napíše. Takže začneme optimalizovat?

Mně zatím vychází lépe sed, předpokládám že to je tím, že ho umím lépe než perl, který jsem se tedy optimalizovat nesnažil ;)

bash$ time seq 1 1000000 | ./hehe > /dev/null

real    0m1.189s
user    0m1.764s
sys     0m0.056s

bash$ time seq 1 1000000 | sed -n 'h;n;p;g;p' | tac > /dev/null

real    0m0.862s
user    0m0.964s
sys     0m0.048s

[nettezzaumana]

ad.1) vase reseni aka  'h;n;p;g;p' je moc hezke .. neznal jsem.

 

ad.2) obe reseni maji presto jednu nevyhodu .. na skutecnem unixovem systemu se v lepsim pripade chovaji jinak nez na Linuxu (rozumej nepredvidatelne) .. v horsim nefungujou vubec :D .. ps. je to 1:1 (neprevidatelne:nefungujou .. a to neni dobra bilance ..)

testovano na:

SunOS t5240-s10u7 5.10 Generic_139555-08 sun4v sparc SUNW,T5240

FreeBSD 7.2-RELEASE

 

[Ash]

Souhlasím s tím, že používat jiný sed než GNU sed je nesmyslné sebemrskačství :D asi jako snažit se skriptovat na HP-UX. Na kvalitní práci je potřeba kvalitní nástroj (perl, GNU sed, C...).

[Ash]

Aby nebylo špatně pochopeno, i GNU sed může být posix compliant (--posix), ale musí to být GNU sed, ne nějaký nedodělek na UNIXu.

[nettezzaumana]

mistre :D .. ok, pokud chceme *nekde *zustavat tak si ujasneme pojmy ::

a) neskromne si myslim, ze sed umim stejne jako perl a ne-li lepe .. sed == REs a ty jsou vsude stejne

 

b) to co vy zovete sed je v pravem slova smyslu GNU-sed .. me hlavni zamereni se netyka paznechtu jmenem GNU ale POSIX compliant systemu (jako napr unixove systemy, neplest s Linuxem ktery je unix-like) .. vas kod bohuzel nefunguje jinde nez na Linuxu (osobne jsem zkousel bsd a solaris) .. mozna proto pristupuju k sedu a obecne ke GNU optimalizacim pomerne podezrivave a skepticky ..

 

c) tato uloha nema podle me co docineni s REs. to, ze to lze pomoci REs resit *take snad jeste neznamena, ze se tady budeme hadat a osocovat co kdo umi lepe a co je ciste .. to dle meho skromneho nazoru GNU-sed rozhodne neni.

cela tato diskuse zacala moji nevinnou poznamkou o brainfucku pomoci REs .. nemyslel jsem tim, ze vas brainfuck je spatne napsanej, pomalej nebo nedejboze *necistej. myslel jsem tim, ze v tomto pripade jste sice zvolil funkcni, nicmene brute-force metodu .. aneb jak by se to chovalo, kdyby to melo parsovat radky s nestandartni delkou

 

toto je primitivni operace ktera se sklada z jednoduche direktivy :: "kazde dva radky co jdou za sebou vem a umisti je *pred dvojku radku co byla predchozi .." .. jakekoliv dalsi laborovani a nebo manipulovani je *pointless ;)

 

nemyslim to nijak konfrontacne, ale pobavil jste me vasi neskryvanou znalosti GNU-sedu a zejmena receptem pro vsechny programatory, jak se stale udrzet v projektu .. obavam se, ze vase metoda mozna pomaha v jednodussich shellovych skriptech, nikoliv vsak v pripadech, kdy se brainfuck neskryva v necem tak mrzkem jako jednotlivy RE/algoritmus, ale v komplexnosti a provazani pouzitych metod :D

 

zdravim

[Ash]

Moc nechápu smysl příspěvku a proto jen upřesním že vámi zmiňovaný kód v sedu s RE jsem nepsal já, já napsal optimalizovaný kód sed -n 'h;n;p;g;p' | tac, myslím že je POSIX compliant.

Můžete si povšimnout, že tam není žádná RE, on sed je více než jen RE, je to hlavně o streamovém editování, ale nechci zacházet do hloubky, abyste to třeba zase nebral mylně jako nějaké poučování podobně, jako jste mylně interpretoval mou prostou úvahu o programátorech :D

[nettezzaumana]

viz. prispevky vyse ..

 

prvni prispevek jsem dopsal az pote co jsem si *vsiml, jak jste optimalizoval .. a to se mi libi, hezky jste to udelal

thx, good to know it

[FooBar]

Ja se omlouvam, ale co si mam predstavit (rikejte mi vojin Kefalin) pod takym pojmom "radky s nestandartni delkou"?:)

[Ash]

Kolega se zaměřuje i na ne-gnu nástroje běžící na všelijakých platformách jako Sun, BSD, takže tam mohou přijít v potaz různá omezení, jako třeba 4OKB max. délka řádky u sedu, 3000 znaků u awk a podobně, popřípadě to můžete chtít použít na nějaké mašině běžící ještě od 70. let bez aktualizace... ;) ;) ;)

[FooBar]

Ah, uz chapu co chce rict... ackoliv bych se mozna v tom pripade branil formulaci "standarDni delka radku" :)

[FooBar]

Troufl bych si rict, ze to je tim, ze umis dobre perl a neumis dobre sed:) Moje situace je presne obracena, Perlem nevladnu a na tvuj kod jsem se musel soustredit,... rekl bych, ze neni zadny X vs Y, je to vec zcela subjektivnich preferenci

[Ash]

+1, sed rulez, jednoduché, čitelné, přímočaré, žádné velké programování ;)