Názory k článku
Vydán GNU Sed 4.6, zapisuje rychleji
-
Miloslav Ponkrác (neregistrovaný)
Bude to dělat bordel v rourách. Pokud zdroj/cíl bude pracovat interaktivně, a nebude očekávat, že mu nějaký proces uvnitř roury bude zadržovat více řádků, tak se bude hodně divit.
Také nejsem nadšený z tohoto nového chování sedu. Myslím, že výchozí chování sedu mělo zůstat zpětně kompatibilní, a pro vylepšený režim mít parametr. Případně mít nový příkaz ised (improved sed).
-
V jednom skriptu mám
sed --unbuffereda co si pamatuji, tak jsem právě řešil, že se mi data nezpracovávala interaktivně po řádcích ale zasekávalo se to.Doporučuji si zkusit rozdíl mezi těmito dvěma příkazy:
cat | sed 's/a/b/g' | cat cat | sed --unbuffered 's/a/b/g' | cat
A to mám verzi 4.4. Tzn. tyhle problémy bylo potřeba řešit už před 4.6. I když dřív se to zřejmě zasekávalo jen na vstupu, ale výsledek je stejný (pokud se výrazně neliší objem dat na vstupu a výstupu).
-
Může, ale bylo by to k ničemu. Ono se schválně nezapisuje po každém řádku a data se nejdřív plní do mezipaměti a zapisují se až po větších kusech. Totéž pro čtení.
Víc procesů by mělo smysl leda pro samotné nahrazování -- načíst třeba sto řádků, udělat deset vláken, každému hodit deset řádků, a pak to posbírat a poslat na výstup.
-
rowos (neregistrovaný)
Jo, kolega si taky stezoval, ze u GNU zmeni z jedne verze na jinou chovani a nikomu to nevadi, tenkrat si stezoval, ze nejak zmenili recursive u grepu, ze to byl -r a zmenili to na -R (nebo obracene), protoze bud chteli na -r jinou akci nebo chteli to recursive mit stejne jako u jineho prikazu.
Ja posledni dobou resim akorat dilema u mailx. Default je v debu bsd-mailx, ale heirloom mailx ma lepsi features (IMHO) a pak existuje jeste gnu-mailx. Dost parametru je stejnych, ale nektere relativne dulezite jsou jine, napr. adresa odesilatele from se u heirloom dela -r, ale v bsd se musi dat -a 'From:...', ale -a je u heirloom zase priloha. Ale to je jine tema.
Osobne si myslim, ze na venek by se nemelo nic menit, API po zvyseni verze, u programu asi taky jen s major zmena. Na druhou stranu, jak funguje program nebo API uvnitr je celkem jedno, takze kdyby to zrychlili bez vlivu na okoli, tak urcite super. Tahle bude mozna spousta skriptu fungovat "jinak". Na druhou stranu, taky uz jsem pri hrani s rourama zjistil, ze neni moc dobre se spolehat na to, ze z roury data prijdou.
-
mb (neregistrovaný)
paralelne spracovanie v sede (v lahu) sice mozne je, ale vysledok by beztak nemal byt prehadzany, takze vlakna budu musiet na seba cakat... to uz nech si "zvlacni" uzivatel sam
pride mi to ako zjednotenie spravania s (e|z|)grep-om, kde sa to tiez spracovava po blokoch a pre riadkove bufrovanie sa musi pouzit --line-buffered opsna
za zmienku stoji pouzitie stdbuf, porovnajte si vystup:stdbuf -o0 -i0 bash -c '( { date; sleep 1; date; } | grep . | cat )' bash -c '( { date; sleep 1; date; } | grep . | cat )' -
Clock (neregistrovaný)
Ja sem v sedu napsal generator IPA vyslovnosti pro Khmerstinu ktery je dle meho nazoru asi tak 5x lepsi nez ta vyslovnost u Google Translate. Ma to asi 290 prepisovacich prikazu.
Bezi to strasne dlouho, a to jsem se snazil ty prikazy optimalizovat slucovanim.
Muzete si to zkusit, zkopirujte si nejaky Khmersky clanek z Koh Santepheap Daily
https://kohsantepheapdaily.com.kh/ a pastnete ho do meho prekladace na http://ronja.twibright.com/daemtnaot.php
ČLÁNKY DO MAILU