Подскажите текстовый редактор под онтопик, который умеет открывать текстовые файлы...

самой собой, сабж должен быть опенсорсным

vim довольно шустро открывал файл весом 1.6 гиг. >10 не пробовал, но думаю тоже сможет.

Плюсую vim.

Less

И как там перейти в режим вставки?

см. мой ник.

Зачем открывать десятигиговые файлы в текстовом редакторе?

Мне тоже стало интересно.

3.2G

vim сразу завис, я прибил его

gedit начал открывать, нигде не завис но открывать файл ему ещё долго.

less открыл сразу, не завис. При переходе к концу файла выдал Calculating line numbers... (interrupt to abort) но через минуту две таки перешел к концу файла. После чего переход на начало и конец файла происходит сразу.

nano

что за файл ты открыл?

vim

Notepad++ есть в portable варианте и без плагинов.

less, sed, grep, awk.
Если кроме открытия нужно редактирование выкини из списка less и grep.

vim (надеюсь, что оперативной памяти у тебя много)

А вообще неправильно это, если файлы по 10 Гб текста руками открывать.

А что, на куски разбивать — не судьба?

Или ты почуял себя хитрожопым и решил удалить записи о скачанной тобой порнухе из логов сквида? Так это просто sed'ом делается…

ed

Так делал

cat /dev/urandom | base64 > text_file

Vim. Только докупить ОЗУ и увеличить своп не забудь.

vim

vurdalak, Ceiling_QB, powerguy, peregrine, RADDyomin

Так ладно, пагни, шутки в сторону, давайте ваш рецепт открытия файла размером больше объема оперативной памяти, раз уж посоветовали.

Как пример можно взять дамп латышской вики (273 мб, после распаковки 13G), но переименовав его в *.txt, потому что на xml сдохнет точно.

Я-то на своих 32GB открыл, всё нормально, но он сожрал точный размер файла, а что делать другим, т.к. я протестил на машине с меньшой рамой, хер там.

При открытии большого файла, когда вим жрет оперативку, но не показывает еще содержимое файла, можно нажать C-c , он покажет, но при этом перестанет читать до конца, например покажет только то, до чего дочитал.

Оптимальный запуск: vim -u NONE -n --noplugin file.txt

Советую емакс. 10 гиговый файл он, конечно, не откроет, но там есть встроенный психоаналитик, что тебе сейчас гораздо актуальнее, до утра есть шанс продержаться. Ну а с утречка можно будет и в стационар лечь.

но он сожрал точный размер файла, а что делать другим

не отключать своп

sed

рецепт открытия файла размером больше объема оперативной памяти

mmap. Я, собственно, таким образом делал обработку логов сквида и еще кое чего: файлы были по 4ГБ и больше, а памяти 1-2ГБ.

интересно, почему создатели редакторов не используют этот «прогрессивный» способ?

Sublime Text 3. Он покажет прогрессбар загрузки, но висеть этот прогрессбар будет доооолго

файлы были по 4ГБ и больше, а памяти 1-2ГБ

64-битная система на компе с одним гигом памяти? А ты ещё более поехавший, чем казался. И можешь не отмазываться словом PAE, оно не позволяет выделять 4+ гига одним куском.

Откуда ж я знаю? Ничто не мешает сделать нормальный редактор, который хоть терабайтные файлы позволит редактировать.

64-битная система на компе с одним гигом памяти?

А на кой черт эта 32-битная говнотень всралась?

в 64 бита влазит сразу два символа utf-32, очевидно же

Плюсую sublime.

10 гиговый файл он, конечно, не откроет, но там есть встроенный психоаналитик,

раз он там есть, значит предназначен для пользователей этой поделки

не справился

ещё не хватало из-за быдлокода людей, которые, блин, текст на экран вывести не могут портить ssd лишний раз

А что, на куски разбивать — не судьба?

кстати, а как это сделать без копирования?

в своё время пробовал на нём подобное. не осилил. и портабл фейлится и не портабл, да на родной его ОС.

фейлится, как и все

если что, joe тоже не подходит.

Написать патч к модулю ядра твоей ФС, вестимо.

Кстати, если интересно, можешь в моих сниппетах взять как раз для ЛОРа написанный прикол, который делает swap двух файлов без занятия дополнительного места (правда, если питание вырубишь, кирдык обоим файлам).

Большие логи (по несколько гигабайт) мне удавалось открывать только vim (режим редактирования). Без чтения хотя бы краткого мануала пользоваться им не получится.

gvim

Написать патч к модулю ядра твоей ФС, вестимо.

нет, спасибо — бороться с быдлокодерами таким путём мне не хочется. интересно было бы, да, но времени, увы, не так много.

вопрос только в том, что он всё грузит в память. несколько гигов откроет, а вот чуть больше — уже нет.

точно открывает? или как и остальные — загрузив всю оперативу (т.е., считай не открывает)?

Можно, кстати, trunk хвоста делать. В этом случае если у тебя есть 20-гиговый файл, а свободного места только десяток метров, ты можешь тупо кусками по 10МБ с хвоста понаоткусывать.

gvim

сам-то пробовал? :)

Подскажите текстовый редактор под онтопик, который умеет открывать текстовые файлы... (комментарий)

Это логично: обычно людям не нравится, что текстовый редактор тормозит. И обычно файлы имеют небольшие размеры. Поэтому fstat'ом смотрим размер, делаем соответствующий malloc и тупо весь файл в оперативу загоняем. Все шустро, а как записать надо — скидываем на диск последнюю версию. Плюс: легко при помощи realloc увеличить размер памяти.

Если же делать mmap, то усложняется процесс увеличения размера файла. Все операции записи после модификации будут медленнее из-за этого. Да и просто при пролистывании файла будут заметны тормоза, возникающие при считывании ведром очередного блока с диска.

Ничего они не посоветуют. vim всегда выжирает весь файл в память.

Это логично: обычно людям не нравится, что текстовый редактор тормозит

но есть одно «но» mc прекрасно открывает такие файлы и не тормозит. более того, для текстовых файлов 1+ мегабайт является нормой (война и мир та же). а вот такие файлы уже быстрее не загружать в память целиком, ибо именно хард является бутылочным горлышком производительности.

вообще, я в сети видел ссылки на то, что якобы к виму есть какой-то плагин для открытия больших файлов.