substitutie sed in script

[zezke]

Ik ben bezig met een script te schrijven dat als oa als functie heeft dat een bepaald woord vervangen wordt in een tekst door dat woord en het argument dat de gebruiker opgeeft.

cat stapel.html | sed 's/\(<ol>\)/\1$1/'

Dit werkt dus niet, maar wat dan wel

[Verwijderd]

sed -e "s@\(<ol>\)@&$1@g" stapel.html

cat abuse

[ Voor 45% gewijzigd door Verwijderd op 27-11-2007 20:11 ]

[zezke]

Hartelijk bedankt,

en ook bedankt voor het wijzen op m'n overdreven gebruik van pipeline. Zal wel liggen aan de hartstocht waarmee het me ingestampt is.

[zezke]

Nu is er nog een probleem:

sed -e "s@\(<ol>\)@&<li>$1</li>@" stapel.html > stapel.html

levert een lege file op? Heeft dit iets te maken met de manier waarop sed leest en schrijft? En hoe valt dit op te lossen zonder nr een andere file te beginnen schrijven.

[blaataaps]

Kijk eens in de manpage van sed zou ik zeggen

[CyBeR]

zezke schreef op dinsdag 27 november 2007 @ 21:30:
Nu is er nog een probleem:

sed -e "s@\(<ol>\)@&<li>$1</li>@" stapel.html > stapel.html

levert een lege file op?

Klopt.

Heeft dit iets te maken met de manier waarop sed leest en schrijft?

Yep.

En hoe valt dit op te lossen zonder nr een andere file te beginnen schrijven.

Niet.

[zomertje]

Je eerste (input) file renamen en dan naar de oorspronkelijke naam schrijven?

[Verwijderd]

zezke schreef op dinsdag 27 november 2007 @ 21:30:
En hoe valt dit op te lossen zonder nr een andere file te beginnen schrijven.

Met de '-i' optie, voor 'in place' editing.

sed -i -e "s@\(<ol>\)@&<li>$1</li>@" stapel.html

Geen idee of dat overal werkt, maar het staat in ieder geval in de man pages en het werkt prima op mijn Linux machines

[deadinspace]

zezke schreef op dinsdag 27 november 2007 @ 21:30:

sed -e "s@\(<ol>\)@&<li>$1</li>@" stapel.html > stapel.html

levert een lege file op? Heeft dit iets te maken met de manier waarop sed leest en schrijft?

Nee, dit heeft te maken met hoe redirection werkt.

Sed schrijft zijn output weg naar stdout. Met > zorg je dat stdout geredirect wordt naar een file, maar dit gebeurt niet door sed, maar door je shell (waarschijnlijk bash). Als je shell het volgende ziet:

foo > bar

Dan opent je shell de file bar, knoopt stdout aan die file, en start foo. Foo denkt dat hij naar stdout schrijft en hoeft dus niks speciaals te doen. Maar, de shell moet de redirection opzetten (en dus een lege file bar aanmaken) voordat foo gestart wordt.

In jouw geval wordt stapel.html dus geleegd door je shell, nog voordat sed gestart wordt.

Overigens zijn er goede redenen voor een dergelijke aanpak, in het volgende commando

sed foo > bar

kan sed telkens een beetje lezen van foo, bewerken, en dan wegschrijven naar stdout/bar. Daardoor hoeft niet de hele inhoud van foo in één keer in het geheugen te staan, wat wel zo prettig is bij grote files

Verwijderd schreef op dinsdag 27 november 2007 @ 23:08:
Met de '-i' optie, voor 'in place' editing.
...
Geen idee of dat overal werkt, maar het staat in ieder geval in de man pages en het werkt prima op mijn Linux machines

Ik weet niks zeker, maar het klinkt mij in de oren als een GNU extensie. Als dat klopt, dan loop je het risico dat het op andere Unices niet werkt. Hoe erg dat is mag de TS zelf bepalen voor zijn situatie

[Boudewijn]

die -i werkt idd niet op oa BSD meen ik.
heb ik iig al gedoe mee gehad. zou ik dus niet gebruiken als je scripts op wat meer moeten draaien dan GNU.

[Verwijderd]

Boudewijn schreef op woensdag 28 november 2007 @ 01:48:
die -i werkt idd niet op oa BSD meen ik.
heb ik iig al gedoe mee gehad. zou ik dus niet gebruiken als je scripts op wat meer moeten draaien dan GNU.

-i komt oorspronkelijk van FreeBSD, dus daarop zou het moeten werken, maar ik merk nog wel eens dat het net niet lekker werkt op andere BSD's of OS X, alhoewel ik soms ook niet snap waarom niet; het meest portable is dus renamen (op zich is dat ergens ook wat fijner als je schijf bijna vol is, want met inplace editen kan het zijn dat je nieuwe bestand net niet meer te schrijven is, en je iets 'halfs' overhoudt; terwijl als je renamet en naar een nieuw bestand schrijft, dat weliswaar fout kan gaan, maar je dan in ieder geval je origineel nog hebt.)

[zomertje]

Waarom zou het perse naar hetzelfde bestand moeten? Dan kun je ook niet meer even terugkijken/opnieuw uitvoeren?

Ik dacht trouwens weer in AIX vorm dit keer, geen -i optie

[blaataaps]

Volgens strace doet -i ook niks anders dan naar een tijdelijk bestand schrijven, en dat dan renamen naar je doelbestand.

[Verwijderd]

Dat is ook de standaard manier van universele scripts. Eerst kopieer je het originele bestand, vervolgens voer je de sed uit op de kopie waarbij je de output schrijft naar het origineel. En tot slot verwijder je de kopie.

-i werkt wel op GNU/Linux, maar ga er niet vanuit dat het elders exact hetzelfde werkt. Hetzelfde geldt voor allerlei andere commando's, waaronder bijvoorbeeld du.

[ Voor 27% gewijzigd door Verwijderd op 28-11-2007 09:42 ]

[blaataaps]

sed uitvoeren op het origineel naar een tijdelijk bestand en dat dan renamen is een factor sneller dan dat, beginnen met kopieren is niet zo zinvol

[sparks]

Als je dezelfde file wilt editten kun je natuurlijk ook ed icm een here document gebruiken.

[xzenor]

als je nou -i .bak doet in plaats van gewoon -i, dan wordt het origineel met een .bak extensie opgeslagen. Misschien handig als je aan het testen bent zodat je niet steeds je origineel kwijt bent als het fout gaat

[jpm.lensen]

ik liep hier laatst ook een keer tegen aan, en heb het toen als volgt "opgelost":

sed -e'blacommandos' $L1 > 2_$L1
mv 2_$L1 $L1

niet super netjes, maar werkt wel...
$L1 is dan dus de stapel.html uit je voorbeeld
Het zat bij ook nog in een loopje....

[Boudewijn]

Verwijderd schreef op woensdag 28 november 2007 @ 07:58:
[...]


-i komt oorspronkelijk van FreeBSD, dus daarop zou het moeten werken, maar ik merk nog wel eens dat het net niet lekker werkt op andere BSD's of OS X, alhoewel ik soms ook niet snap waarom niet; het meest portable is dus renamen (op zich is dat ergens ook wat fijner als je schijf bijna vol is, want met inplace editen kan het zijn dat je nieuwe bestand net niet meer te schrijven is, en je iets 'halfs' overhoudt; terwijl als je renamet en naar een nieuw bestand schrijft, dat weliswaar fout kan gaan, maar je dan in ieder geval je origineel nog hebt.)

offtopic:
je hebt gelijk, ik liep hier met OpenBSD tegenaan.
* Boudewijn heeft dus niets gezegd

[Borromini]

zezke schreef op dinsdag 27 november 2007 @ 21:30:
Nu is er nog een probleem:

sed -e "s@\(<ol>\)@&<li>$1</li>@" stapel.html > stapel.html

levert een lege file op? Heeft dit iets te maken met de manier waarop sed leest en schrijft? En hoe valt dit op te lossen zonder nr een andere file te beginnen schrijven.

Erm... Je wil dus bestand A overschrijven met de output van bestand A? Wat denk je dat dat oplevert?

Juist... Een leeg bestand. Je wist je gegevens gewoon .

Gebruik -i om het bestand te parsen en tegelijk op te slaan, zo heb je geen redirection nodig. Je hebt -e in dat geval ook niet meer nodig, tenzij je meerdere sed sequences gebruikt achter mekaar.

[ Voor 0% gewijzigd door Borromini op 28-11-2007 17:54 . Reden: OK... Big time spuit 11 ]

[u_nix_we_all]

Dit is te grappig:

Wat gebeurt er als je eerst je bestand cat, dan een pipe gebruikt naar sed om de substitution te doen en de output redirect naar het bestand waar je mee begon ?

Krijg ik nu een "useful use of cat award" ?


nevermind, ik ging er ten onrechte vanuit dat de pipe eerst gelezen werd voordat het bestand herschreven werd, maar zo werkt het niet.

Ik moet er nog even over nadenken of ik snap waarom .....

Als je append ( >> ) zie je wel beide datasets in de file verschijnen ....

[ Voor 37% gewijzigd door u_nix_we_all op 28-11-2007 18:08 ]

[zezke]

Ok, bedankt voor de hulp, jullie zijn allemaal schatten.

Hier werkt de -i optie inderdaad, maar aangezien het ook op een ander systeem moet werken zal ik nog even de manpages op dat systeem moeten controleren of het i-vlaggetje wordt ondersteund.

Nogmaals bedankt iedereen.