Vettig texteditor, som funkar med stora filer, Vilken?

[Purre]

Word? Wordpad brukar jag annars öppna större textfiler i men om det klarar 2GB vet jag inte.

[danielr112]

Han menar nog att lagra filerna i mindre storlekar.

Men filer som kan vara svåra att lagra i mindre är t ex databasdumpar från MySql och liknande. Där man kanske vill sätta andra variabler vid inläsning.

Logfiler ska man helt klart rotera lite oftare.

[TomasL]

Visst, hade man haft nåt val, så hade mindre filer varit trevligare, men nu är filerna så stora, och det är inget att göra åt det.

[sodjan]

> Sodjan, hurdå, och vadå tänka om?

Alltså, det beror ju lite på vad som ska "göras" med filerna. Det
som du har angivit är :

> Den måste kunna söka och ersätta både med "Regular Expressions" och ren text.

Jag tolkar det som att du redan från början vet vilka sök/ersätt operationer
som det gäller och att det inte är en traditionell "redigering" av filen utan mer
en "processering" från rad 1 till sista raden. Jag skulle i så fall tittat på något
verktyg för att göra just det. Det kan vara perl, Python, awk eller något liknande
beroende på vad som råkar finnas i "verktygslådan" för tillfället. På så sätt blir
inte filstorleken alls avgörande för om det går eller inte, det kommer bara att
linjärt påverka tiden det tar att köra igenom filen.

En annan intressant fråga för teknikvalet är om det är en engångsoperation
eller om detta kommer att återkomma regelbundet.

Om nu de aktuella operationerna i alla fall måste göras från en traditionell "editor",
och det är svårt att hitta en editor som fixar så pass stora filer, så kan ett
alternativ vara att först köra filen genom något verktyg för att dela upp den
i mindre för editorn hanterbara bitar. Det kan också vara ett de ovan nämnda
eller något liknande.

[TomasL]

Jo, jag "vet" vad som måste bytas ut/raderas ur filerna, men det förutsätter förstås att jag kikat på dem först, så jag får veta vad som skall fixas till.

Ordet "texteditor" kanske är lite fel ord, men å andra sidan, allt som på ett eller annat sätt "editerar" en text är ju en texteditor, sedan om den då hämtar en rad i taget och processar denna eller läser in hela filen i en buffert, är ju iofs tämligen ointressant sas.

I nuläget är det en operation som behöver göras med jämna mellanrum, om jag inte kan hitta på nått sätt att fixa en "rotering" på filerna.

Problemet som jag har är att realterm mig veterligen inte klarar att rotera filer. (Man kanske skall skriva ett eget terminalprogram)

Dessutom är CSV exporten från ett antal andra program inget jag kan styra egentligen.
Därför tenderar filerna att bli lite stora.

Nästa problem blir att på nått sätt omvandla binärdata som finns i vissa loggfiler till hex, men det klarar sannolikt inga "text-editorer" av, utan det får nog bli nån specialskriven parcer, gissar jag.

[sodjan]

> eller läser in hela filen i en buffert, är ju iofs tämligen ointressant sas.

Tja, det verkar ju inte vara helt ointressant i just *detta* fall p.g.a filstorleken.
Om det hade varit ointressant så hade ju inte dina editorer kraschat...

Så om jag förstår rätt så har du RealTerm (http://realterm.sourceforge.net/)
igång som loggar trafik som kommer in på en serie (COM) port till en fil ? Och denna
fil behöver behandlas lite efteråt ?

Jag skulle fundera på att fixa ihop något med något enkelt verktyg (perl, python
eller liknande) som läser direkt från samma port, gör det som ska "göras" med
datat och sedan loggar det på lämpliga filer. Då för du loggning och bearbetning
på samma gång, så att säga.

> Problemet som jag har är att realterm mig veterligen inte klarar att rotera filer.

Det verkar kunna "fjärstyras" via ett ActiveX API. Jag har inte kollat i detalj, bara
snabb-browsat siten, men det verkar kunna gå att så loggning av/på via API't.

Kolla även "Controlling a Running Instance" där det också ser ut att kunna gå
att öppna en ny "capture" fil on-the-fly.

[danielr112]

cp fil.log old.log
>fil.log
gzip old.log

och vips har man flyttat innehållet till en ny fil och den gamle är trunkerad under drift Dock kommer man få lite dubletter av rader men man kan åtminstående rotera loggar under drift. (föutsätter att man kör nix baserat men kan tänka mig man kan rotera i windows på liknande sätt)

[TomasL]

Problemet är ju att man inte vill ha en "rotate" mitt i en skrivning.
Det går naturligtvis att göra nått liknande i win, under förutsättning att filerna ej är låsta.

Jo jag har funderat på att fixa till nått annat som läser av portarna och skriver till loggfilerna, istället för realterm, får väl bli nästa projekt gissar jag.
Därefter återstår de csv-filerna som exporteras från andra applikationer, vilket jag inte kan styra.

[danielr112]

Om man inte vill ha den lilla rotate som blir i filen kan man ju alltid parsa direkt till ett program som sedan tar hand om och lagrar i loggar. Har dålig koll hur man gör det i windows också

[xxargs]

Misstänker att emacs i 64-bitars linux kan käka väldigt stora filer - skall kolla det i morron.

32-bitars så är det ca 150 MB för gnu emacs och 1 GB för Xemacs om jag mins rätt - har själv varit irriterad på detta när jag slagit i 150 MB-taket, men vet att i 64-bit linux så har det slickat i sig lätt 250 MB utan problem.

Räkna inte med att det finns motsvarande för windows - även om xemacs teoretiskt kan kompileras för 64 bit även här så är förmodligen inte cygwin-paketet som editorn rider på mer än 32-bit i windows och begränsar.

---

Det här att filerna låses i windows är rent idiotiskt och en dum rest från DOS-tiden - varför tex. låser acrobat reader en pdf-fil om den bara skall läsa den - varför gör den inte en egen kopia eller kolla filen då och då om den är nyare och läs in den igen och uppdatera vyerna vid behov precis som det sker i linux-världen!?

Det är högst irriterande när man skall kompilera tex. Latexfiler då och då under arbetet och utfilen är låst och stoppar kompileringen pga. en pdf-viewer håller på resultatfilen och man man vet att motsvarande process är hur smidigt som helst i Linux-världen

[Maalobs]

Behöver nån form av "texteditor" som kan hantera stora filer, 2GB och uppåt.
Den måste kunna söka och ersätta både med "Regular Expressions" och ren text.

Kan du visa urklipp ur filen, och ge exempel på vilka redigeringar du vill kunna göra?
Jag och flera andra kan säkert ge dig exempel på olika one-liners du kan köra i Perl eller motsvarande, kanske färdiga script också om det är möjligt i ditt fall.

Här är förresten en gratis, open source port-logger för Windows:
http://www.com-port-monitoring.com/datalogger.html

[xxargs]

Förstår varför man behöver editor med sökmöjligheter - oftast måste man titta väldigt långt in i jättefilen för att hitta dom exemplen man senare kanske vill skripta...

Emacs har ju ofta bra sök och regexp-kapabilitet sas. men gäller att få till 64-bit miljön där den kan hantera stora filer och för en del är det också viktigt att vara på 'rätt' OS-plattform och då ser det lite surt ut för win-användarna just för tillfället när det gäller emacs.

[TomasL]

Här är förresten en gratis, open source port-logger för Windows:
http://www.com-port-monitoring.com/datalogger.html

Får kika på den, frågan är om den Tidsstämplar de mottagna datapaketen

Förstår varför man behöver editor med sökmöjligheter - oftast måste man titta väldigt långt in i jättefilen för att hitta dom exemplen man senare kanske vill skripta

Det är ett av problemen, då ett av programmen exporterar en massa beskrivande text på flera ställen mitt i csv-filen.

[mri]

Räkna inte med att det finns motsvarande för windows

Varför inte det? För ganska länge sen sökte jag efter en editor i windows som kunde hantera STORA textfiler (loggfiler). Hittade nog flera editorer som kunde "ladda" en STOR fil på en sekund, och därefter direkt tillät att man scrollade runt och gjorde fritextsökning etc...

Edit: Och när jag säger STOR så var det i mitt fall en bit över 1 GByte loggfiler. Den editor jag valde (minns inte mera namnet) hade egentligen ingen över gräns, förutom då vad filsystemet gav.

Som jag skrev tidigare; editorn måste jobba mot disken och inte försöka ladda in hela filen i minnet. Det är en lite annan kategori av editorer var man tänkt till lite när det gäller datamängder. Det enda som krävs av OS-et är 64-bit disk I/O, vilket Windows givetvis har, liksom t.ex. Linux och andra UNIX'ar.

[TomasL]

Har också konstaterat att det är en diskbaserad editor jag söker, som inte laddar filen helt, utan delar sekventiellt.

Det verkar som att det stora problemet är att de flesta editorer, förutom att hela filen läses in i arbetsminnet, även håller "undo" informationen i minnet också, därav problem med accessen.
Såg när jag testade notepad ++ och notepad2 (vilka enligt uppgift skall hantera dessa filer) att när filen var helt inläst (1GB) var minnesförbrukningen ca 2GB, och när den började söka och ersätta steg minnesförbrukningen snabbt till runt 6GB, varefter bägge editorer kraschade.