Re: opening large files (few hundred meg)

[Tim X]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Jason Rumney <jasonrumney@gmail.com> writes:
>
>> On 28 Jan, 20:36, Andreas Röhler <andreas.roeh...@online.de> wrote:
>>
>>> What about a large-text-mode: sed reads chunks of text
>>> in, one by one, letting Emacs forget the rest. Than
>>> only the line-no matters, sent to sed.
>>
>> Such solutions have been proposed before, but the likely way that a
>> user will navigate through such a huge file is by searching, so just
>> paging parts of the file in and out is only part of the solution, it
>> must also offer searching to be useful.
>
> It's possible to do paging and searching with screen (copy-mode ==> C-a [)
> In this mode you can mark/copy/paste and search (C-r C-s)
> It's possible to tweak commands emacslike  in screenrc:
>
> markkeys "h=^B:l=^F:$=^E:0=^A" 
>
> screen work in ansi-term/term.
> But how a text file can become so big ?
>
> -- 
> A + Thierry
> Pub key: http://pgp.mit.edu
>
>

Its not that uncommon to encounter text files over half a gig in size. A
place I worked had systems that would generate logs in excess of 1Gb per
day (and that was with minimal logging). When I worked with Oracle,
there were some operations which involved multi Gb files that you needed
to edit (which I did using sed rather than a text editor). 

However, it seems rediculous to attempt to open a text file of the size
Xah is talking about inside an editor. Like others, I have to wonder
why his log file isn't rotated more often so that it is in manageable
chunks. Its obvious that nobody would read all of a text file that was
that large (especially not every week). More than likely, you would use
existing tools to select 'interesting' parts of the log and then deal
with them. Personally, I'd use something like Perl or one of the many
other scripting languages that are ideal for (and largely designed for)
this sort of problem.

Tim



-- 
tcross (at) rapttech dot com dot au