AkelPad

Skif_off
У sed-а и прочих, есть лимит на длину строки, вряд ли который к длине файле отношения не имеет. У grep-а будет скорее всего лимит по больше, ибо он тупо по строчный фильтр(sed - полноценный редактор с промежуточными буферами и т.п.)

maki
For such tasks it is recommended to use other technologies. For instance, you can use grep or sed utility to seek entries of specific word, and then use other. maybe specially crafted progs to edit it.
In any case it will tale a lot of time, even if you have RAM enough to keep whole 110G file in memory. Non optimized algorithms will be ineffective(for instance, for Galois fields math for processing usual CD image(600MB) optimized algorithm 10000 more effective than direct one; for text we shall have the same issues).

FeyFre

Example:

EmEditor

Open 226 GB (!)TXT file = 49 MB RAM !!! superfast and stable

EmEditor easily opens up to 248 GB or 2100000000000 lines

maki
1. Open 226GB TXT file using EmEditor
2. Delete that TXT file
3. Do your editing tasks

I bet, you shall be unable to do (2). Well, if you do, than you will get a lot of error message for (3). Because *stupid*(IMHO) EmEditor load text partialy and load more portions when needed, so it LOCK file on filesystem, which is fail because most of usecase expect file not to be locked, for instance log files, network filesystems.
AkelPad loads whole file into memory, and file itself can be removed, storage itself can be removed, or storage fails itself. Moreover, if file loaded from network filesytem, AkelPad will continue work flawlessly even if network fails. EmEditor and others who lock files going to hang, maybe crash, and all your editorial work going to be lost. Well, if you accept that risk, that is your choice. I shall not, and AP works for me 100%.

PS: TEXT FILE 226GB. As I said, you going to have a lot of problems while processing such files using common text editors. I MUST use special tools for that purpose. Or you MUST split your VERY IMPORTANT database into smaller clusters. On your desire.

Multithreaded design

The key to EmEditor’s large file capabilities is its single-process, multithreaded design, which allows EmEditor to execute powerful functionality without compromising speed or taking up too much memory.

Не то, чтобы интересно, но, всё-таки, что можно редактировать (не искать/смотреть, а именно редактировать) в файле такого размера?

Serge Yolkin
Дамп базы данных, больше ничего в голову не приходит.

TEST:

Open TEXT 2,16 GB (25,246,452 lines):shock:
Maximum Number of Files to Replace if Kept Open: 32768

Use: Amazing 2 MB RAM (Idle) (Please believe me!)

Skif_off
Угу. Закат солнца вручную...

maki
OK. You've found The_Best_Editor_for_You. Are you happy?
I have no files of this size and I don't need the tool for editing it.

I'm not happy !!!!!

I do not know where they are similar options in PSPad:

PSPad -> Find -> BUTTON [COPY] (Find and Open resultat New Window) e a s y !!!

EmEditor -> ???????Where are these options. It's really very important. Please answer.


AkelPad -> similar option ???? [COPY]

maki
SearchReplace.js & Log plugin?

maki
About the PSPad or EmEditor, you can ask on the PSPad or EmEditor forums... Why do you need AkelPad?

Serge Yolkin - Because did not reply to my messages (other forum)

maki
It seems to me that for you would be suitable hex editor eg. HxD: http://mh-nexus.de/en/hxd/

Instant opening regardless of file-size
Up to 8EB; opening and editing is very fast

KDJ wrote:maki
It seems to me that for you would be suitable hex editor eg. HxD: http://mh-nexus.de/en/hxd/

Instant opening regardless of file-size
Up to 8EB; opening and editing is very fast

It has the same options as PSPad?