[Unix] Gruwelijk grote file editen

[bartvb]

Heb een PostgreSQL dump staan van meer dan 1 GB waar echter een foutje in zit op regel 300.000 nogwat.

Ik moet daar dus 1 regeltje gaan wijzigen, probleem is alleen dat de server niet echt blij met me is als ik die file in vi of joe gooi

Weet er iemand een manier om die file te wijzigen zonder dat ik heel die file in het geheugen moet trekken en opnieuw weg moet schrijven?

De tekens kunnen trouwens gewoon veranderd worden, er hoeft niets gedelete of geinsert te worden..

[deadinspace]

Misschien dat je met

code:

sed 's/oudestring/nieuwestring/' oudefile > nieuwefile

wat kunt... merk wel op dat hij dan elk voorkomen van oudestring vervangt... Dat werkt dus alleen goed als oudestring uniek is in die file.

[bartvb]

En helaasch.. kans is _erg_ groot dat die string er nog een keer in voorkomt..

Maar het is wel een oplossing.. in theorie wel te proberen maar ik zoek eigenlijk iets universelers Handig voor later.. Moet toch ook handiger kunnen?

[odysseus]

Ik vrees dat hij dan alsnog het hele bestand in gaat lezen, hij moet tenslotte wel alle regels doorkijken om te zien of het patroon erin zit.

Ik bedenk nu een heel vreemde oplossing waarvan ik absoluut niet garandeer dat hij werkt of zelfs maar mogelijk is:
Kopieer het belangrijke deel van het bestand met dd, op de volgende manier: 'dd if=/mijn/bestand of=/mijn/tijdelijke/bestand skip=getal1 count=getal2' (je zult wat met de waarden voor getal1 en getal2 moeten experimenteren). Vervolgens wijzig je wat je moet wijzigen, iets wat nu geen probleem moet zijn. Tenslotte moet je de inhoud van het tijdelijke bestand weer in het originele bestand krijgen. Dat moet mogelijk zijn met iets als 'dd if=/mijn/tijdelijke/bestand of=/mijn/bestand seek=getal1, waarbij getal1 weer hetzelfde getal moet zijn dat je eerder ook gebruikt hebt.
Nogmaals: werking niet gegarandeerd, gewoon een hersenspinsel dan klinkt alsof het mogelijk is .

[E-Rick]

Running an vi editor on a file larger then 64 MB may cause the following error messages:

0602-103 file too large to place in /tmp

In this case, use the split command to split the large file into smaller files, then use vi on them:

code:

split -l <lines-in-each-file> <file-name>

Bron

[Platypussy]

Op dinsdag 23 april 2002 18:26 schreef E-Rick het volgende:
Running an vi editor on a file larger then 64 MB may cause the following error messages:

0602-103 file too large to place in /tmp

In this case, use the split command to split the large file into smaller files, then use vi on them:

code:

split -l <lines-in-each-file> <file-name>

Bron

//edit: lama

[_-= Erikje =-_]

't is 1 grote txt file?

kun je niet met head en tail spelen om 3 files te maken?

1 van regel 1-(3000nogwat-1)
1 met alleen de foute regel
1 met de rest van de txt file

en die weer aan elkaar plakken

[deadinspace]

Op dinsdag 23 april 2002 17:56 schreef odysseus het volgende:
Ik vrees dat hij dan alsnog het hele bestand in gaat lezen, hij moet tenslotte wel alle regels doorkijken om te zien of het patroon erin zit.

Uiteraard, maar dat is een kwestie van lezen; zoeken; outputten; repeat... telkens 1 regel ofzo. Dus heeft hij nooit de hele file in zijn RAM. Als je die file in een editor opent, dan moet hij in zijn geheel in het RAM.

Ik bedenk nu een heel vreemde oplossing waarvan ik absoluut niet garandeer dat hij werkt of zelfs maar mogelijk is:
Kopieer het belangrijke deel van het bestand met dd, op de volgende manier: 'dd if=/mijn/bestand of=/mijn/tijdelijke/bestand skip=getal1 count=getal2' (je zult wat met de waarden voor getal1 en getal2 moeten experimenteren). Vervolgens wijzig je wat je moet wijzigen, iets wat nu geen probleem moet zijn. Tenslotte moet je de inhoud van het tijdelijke bestand weer in het originele bestand krijgen. Dat moet mogelijk zijn met iets als 'dd if=/mijn/tijdelijke/bestand of=/mijn/bestand seek=getal1, waarbij getal1 weer hetzelfde getal moet zijn dat je eerder ook gebruikt hebt.
Nogmaals: werking niet gegarandeerd, gewoon een hersenspinsel dan klinkt alsof het mogelijk is .

Ehm, dat moet mogelijk zijn met dd ja... Je kunt ook direct in de file lopen pielen:

code:

echo 'Nieuwe tekst enzo' | cat of=fileinkwestie seek=1234567

Ook met split/tail/head (tail, head en sed alleen aan te raden als het een textfile is btw) zou je inderdaad iets moeten kunnen prakken...

Maar ik denk dat het in elk geval verstandig is om een backup te maken voor je iets probeert

[Verwijderd]

Op dinsdag 23 april 2002 17:46 schreef deadinspace het volgende:

code:

sed 's/oudestring/nieuwestring/' oudefile > nieuwefile

Het is toch sed -e s/..../..../? .

[blaataaps]

Op dinsdag 23 april 2002 19:57 schreef beelzebubu het volgende:

[..]

Het is toch sed -e s/..../..../? .

Uit man sed:

code:

 If  no  -e,-f,--expression, or --file options are given on
     the command-line, then the first  non-option  argument  on
     the command line is taken to be the script to be executed.

Als je over het ontbreken van "-e" valt, die is niet noodzakelijk.

[RG]

Ik zou handmatig een diff patch maken en die gewoon applyen net zoals een patch voor de kernel bijvoorbeeld. Moet lukken als je de regelnummers weet...

[Verwijderd]

/me zou toch echt sed gebruiken.

Ten eerste is dat een regeleditor, waarbij je dus ook op kan geven om welke regels (range) het gaat (zoals hier blijkbaar het geval is). Ten tweede heb je altijd een backup (namelijk het originele bestand)

[Verwijderd]

denk ook wel dat sed dermate in elkaar zit dat ie alleen een bepaalde string grote per keer leest..

[Verwijderd]

Op woensdag 24 april 2002 01:47 schreef Gila het volgende:
denk ook wel dat sed dermate in elkaar zit dat ie alleen een bepaalde string grote per keer leest..

sed werkt inderdaad regel voor regel

Het is een zogenaamde stream editor, waardoor niet meteen hele bestanden in 1 keer volledig ingelezen hoeven te worden

[it0]

sed lijkt me ook de oplossing anders zou ik zeggen fseek in c is je vriend.. of misschien een hexeditor die slim in elkaar zit.

[zomertje]

Ik heb voor de ook even gezocht op google(was nieuwschierig) Maar daar adviseren ze ook sed...

http://groups.google.com/groups?q=sed+edit+line+number&hl=nl&selm=666t9o%24doe%241%40gte1.gte.net&rnum=2

by line number or by contents of the line?

if by line number, then:
line_no=3
sed "${line_no}s/this/that" my_file


maar dan moet je dus wel de exacte regel weten

[Wirf]

Volgens mij moet dat ook gewoon met VI kunnen hoor, het opstarten duurt misschien lang, maar daarna kun je gewoon editen, zover ik weet (zolang je genoeg discspace over hebt)

misschien als je "nice 20 vi hetbestand" doet?

[yeadder]

Op woensdag 24 april 2002 10:47 schreef Wirf het volgende:
Volgens mij moet dat ook gewoon met VI kunnen hoor, het opstarten duurt misschien lang, maar daarna kun je gewoon editen, zover ik weet (zolang je genoeg discspace over hebt)

misschien als je "nice 20 vi hetbestand" doet?

het kan misschien ook wel maar het gaat er om dat het juist niet hoeft omdat hij anders te veel load op de server heeft

[Wirf]

Op woensdag 24 april 2002 10:57 schreef yeadder het volgende:

[..]

het kan misschien ook wel maar het gaat er om dat het juist niet hoeft omdat hij anders te veel load op de server heeft

maar volgens mij is het veel belastender op het systeem als je 10 keer een sed/tail/dd doet (10 keer, want met die methodes moet je de regel gokken)

[Wirf]

ow, wat ik trouwens net lees in de VI manual:

-F Don't copy the entire file when first starting to
edit. (The default is to make a copy in case some­
one else modifies the file during your edit ses­
sion.)

misschien is dat wat?

[PostbodeSiemen]

Ik weet dat er in ultraedit een optie zit om geen tmp file te openen. Dan ben je dus rechtstreeks in de file bezig. Ik heb het net ff getest met een file van 90MB(ik had niet groter) en mijn geheugen gebruik ging precies niks omhoog.

Ik neem aan dat als dat onder windows kan dat er dan zeker wel een editor voor unix moet zijn waarmee dit ook kan.

[deadinspace]

Op woensdag 24 april 2002 09:43 schreef zomer het volgende:
maar dan moet je dus wel de exacte regel weten

Op woensdag 24 april 2002 11:07 schreef Wirf het volgende:
(10 keer, want met die methodes moet je de regel gokken)

Je kunt met sed gewoon regel ranges opgeven hoor:

code:

sed '6,8s/mooh/blaat/'

Vervangt in de 6e t/m de 8e regel 'mooh' door 'blaat'.

[Wirf]

Op woensdag 24 april 2002 18:28 schreef deadinspace het volgende:

[..]


[..]

Je kunt met sed gewoon regel ranges opgeven hoor:

code:

sed '6,8s/mooh/blaat/'

Vervangt in de 6e t/m de 8e regel 'mooh' door 'blaat'.

Ja, maar het probleem is dat je van te voren niet precies weet welke regel het is..... of je zou het eerst moeten opzoeken in.... een editor

[odysseus]

Lees de originele post nog eens een keer en edit dan je reactie even ...hij weet al in welke regel het probleem zit.

[Aaargh!]

awk scriptje ?

[Wirf]

Op woensdag 24 april 2002 18:36 schreef odysseus het volgende:
Lees de originele post nog eens een keer en edit dan je reactie even ...hij weet al in welke regel het probleem zit.

300.000 nogwat

[Rukapul]

vim moet dat kunnen. Vim werkt met een zgn swapfile indien nodig en heeft ook nog andere manieren om niet alles in het geheugen te hoeven laden.

Ik heb op mijn windows systeem met vi(m) een mysql dump van meer dan 1 GB ge-edit. Alleen het opstarten duurde wat lang, maar dat kwam omdat ik de swap optie had aan laten staan.

[odysseus]

Op woensdag 24 april 2002 19:35 schreef Wirf een antwoord

Ik denk dat hij gewoon geen zin had om dat getal weer op te gaan zoeken en uit te schrijven .

[Wirf]

Op woensdag 24 april 2002 20:26 schreef odysseus het volgende:

[..]

Ik denk dat hij gewoon geen zin had om dat getal weer op te gaan zoeken en uit te schrijven .

nouja, laten we er maar over ophouden... allebei de methodes werken wel

[TD-er]

methode om alsnog de juiste regel te krijgen:
grep -n
voorbeeldje... (de regel waarin ik mijn firewallscriptje start)

code:

[@server]$ grep -i masquerade /etc/rc.local -n
46:/sbin/masquerade

Hoeft 'ie alleen maar te weten hoe je de foute regel onderscheidt van de rest

[Verwijderd]

Op woensdag 24 april 2002 23:20 schreef TD-er het volgende:
methode om alsnog de juiste regel te krijgen:
grep -n
voorbeeldje... (de regel waarin ik mijn firewallscriptje start)

code:

[@server]$ grep -i masquerade /etc/rc.local -n
46:/sbin/masquerade

Hoeft 'ie alleen maar te weten hoe je de foute regel onderscheidt van de rest

Gehehe, als je dat wil gaan doen, kan je net zo goed meteen sed gebruiken