Most egy olyan problémával állok szemben, hogy egy szöveget kell tükröznöm a középvonalára függőlegesen. Ezzel nem is lenne gond, csak a sor eleji sorközöket valamiért nem kezeli külön karakternek. Próbáltam awk-val és egyszerűen while read-del is , de a sor eleji szóközöket nem akarja tükrözni egyik sem. Valakinek valami ötlet?
Most egy olyan problémám lenne, hogy egy szövegben a szöveg eleji, illetve a szöveg végi (több) helyközt kellene törölnem. A szöveg eleji megy is seddel, de a végit nem tudom. Valakinek lenne valamilyen ötlete?
Akkor sajnos kétszer kell végigolvasni a file-t, hiszen nem tudod előre a leghosszabb sor hosszát... Van még valamilyen feltétel azon kívül, hogy "nem C"? Tehét mondjuk Fortran vagy FORTH vagy bármi?
A feladat lényege, hogy egy szövegben a rövidebb sorokat úgy kell egyenlő hosszúvá tenni, hogy a sorvégekre megfelelő szóközt írunk. az n a soronként változik. Mindig a leghosszabb sorhosszból kivonom az aktuális sorhosszát.
Az a kérdésem, hogy a subprocesszen belüli echo által az stdout-ra küldött adatot az echo-t követő read miért nem olvassa fel? Bár igaz, ebben az esetben ez sem működne:
while read a; do echo "xx$axx"; done </etc/fstab
hiszen az echo elrontaná a következő alkalommal futó read számára az adatot. Azért egy kis homálytizedelést tarthatnál erről. Persze jó, hogy így működik, csak nem teljesen világos, hogy miért.
echo -e 'aa\nbb' | ( (read x; echo $x); read y; echo $y) Egészen pontosan mi ezzel a gond? Az össes "read" stdin-je az lesz, amit az "echo"-tól kap... ezen a zárójelek nem változtatnak, pl echo -e 'aa\nbb' | { read x; echo $x; read y; echo $y; } ugyanazt eredményezi
Ez ugyan jól hangzik, csak az a baj, hogy ha a külső ciklus elindul a pipe miatt egy önálló processzben - és ennek valóban így kell lennie -, a belső ciklusnak nincs oka önállósodni. De ha igen, még akkor is zavaros számomra, mert a belső ciklus read-je - jelen esetben éppen a feladatnak megfelelően ugyan - ugyanabból az stdinből szedi fel az adatot, ahonnan a külső ciklus read-je. Viszont a két ciklus között az echo-val az stdout-ra piszkítottam, s azt vártam, hogy a belső read-je ezt néha visszaszedi, és ezért hibás lesz a működés. Azonkívül az stdin-t, stdout-ot és stderr-t nem szokta meghatni a különprocessz.
Példa:
echo a | (read x; echo $x) a
echo b | (sleep 1; (read x; echo $x); ) b
Az echo a | read x; echo $x nem működik "jól", de ez azért van, mert a read a pipe miatt subshell-ben futva ott hozza létre az x változót, amely a programra nézve lokális, a subshellből való kilépéskor annak memóriaterülete az x értékével együtt felszámolódik. Ez világos.
válaszon sem, hiszen az az echo $x aa-ját a read y akár fel is szedhetné. Kipróbáltam még ezt is:
echo -e 'aa\nbb' | ( (read x; echo $x); read y z; echo $y $z) aa bb
de szó sincs arról, hogy csak a sorrend miatt van így, s a pipe-on maradt volna az aa. Bár ez nem túl meglepő, mert akkor nem íródott volna ki a terminálra az első sorban. Ingoványos ez nekem, tényleg nem tiszta teljesen. :(
Mert a pipe miatt a ciklusod al-shell-ben - magyarul masik shell-ben - fut. (Ha esetleg utanakeresel, akkor megtalalhato, hogy az echo a | read x ; echo "$x" legtobb shellben "jol" mukodik (kiveve pl. pdksh), de ha ciklus van, akkor mar nem. Explicite persze nem sok helyen irjak le.)
Kérdés mindenkihez: az echo által stdout-ra küldötteket miért nem szedi fel a belső while-ban lévő read? Ez attól függ, hogy futásidőben hogy jön ki, tehát esetleges? Vagy?
Megy, ha kijavítod, mert kissé bugos volt. Nézd ezt a változatot:
n=2 seq 20 |\ while read do echo "$REPLY" i=1 while ((i++<n)) && read do : done done
Az egyik hiba az i kezdőértéke volt, a másik, hogy nem növeltem a ciklusváltozót, a harmadik, hogy a read-et kell a ciklusváltozó vizsgálata után rakni, különben akkor is eldobja a sort, amikor már nem kéne. A seq 20 |\ csak a teszteléshez kell, ez állítja elő a sorokat. Egyébként az egy érdekes probléma, hogy az echo által stdout-ra küldötteket miért nem szedi fel a belső while-ban lévő read, de ha ez mégis bekövetkezne, érdemes az echo kimenetét pl. a standard errorra küldeni:
