чем открыть .txt весом 1.5gb

cat, more

Открыть чтобы что?

qemacs?

Посредством grep получите номера строк.

А затем посредством sed выберите следующую строку за номером, который вы получили от grep.

идея хорошая, так я уже делал, но это муторно. Например если надо посмотреть 6 строк подрят. P.S. люди до сих пор один пароль используют ко всем сервисам.

emacs gedit nano пробывал. Натырел вчера с одного сервака оперативы, с использованием уязвимости openssl, grepom пробил, теперь надо увидеть остальные 16бит которые на второй строке=)

sed '1d;2q' filename

less. Если надо редактировать, побей на куски ~10МБ при помощи split, потом cat'ом собери обратно.

grepom пробил, теперь надо увидеть остальные 16бит которые на второй строке=)

man grep

Context Line Control -A NUM, --after-context=NUM Print NUM lines of trailing context after matching lines. Places a line containing a group separator (--) between contiguous groups of matches. With the -o or --only-matching option, this has no effect and a warning is given.

-B NUM, --before-context=NUM Print NUM lines of leading context before matching lines. Places a line containing a group separator (--) between contiguous groups of matches. With the -o or --only-matching option, this has no effect and a warning is given.

-C NUM, -NUM, --context=NUM Print NUM lines of output context. Places a line containing a group separator (--) between contiguous groups of matches. With the -o or --only-matching option, this has no effect and a warning is given.

Например если надо посмотреть 6 строк подрят.

grep -C3 покажет строку с совпадением и по 3 строки до/после. -A -B показывают контекст только до или после.

кстати sed тоже может. Хотя простыми средствами только после.

sed -n '/needle/,+3p'

(и если в «после» есть needle(ещё раз), то не покажет ещё 3 строки)

короче не один редактор не справляется с таким объемом. P.S. никто не знает, что это означают символы под адресом ячейки. Мои подозрения, что программа.Коллега говорит, так кириллица записывается... <code> 2750: E4 C2 DE 59 43 24 69 F1 82 6F FA 89 0B 1A 84 0B ...YC$i..o...... 2760: 1A D5 6D E8 C4 82 E5 7C EE 1B 57 14 DC 0A 73 8C ..m....|..W...s. 2770: 8F 10 F9 0B 99 62 93 5A E4 F0 3F 8A 45 0B 57 23 .....b.Z..?.E.W# 2780: 6C E8 60 95 16 BA 49 0C 19 BC 9F AA AB E9 D4 39 l.`...I........9 2790: 45 79 DE 66 3B 44 D0 E8 0C 79 57 29 75 A0 06 9F Ey.f;D...yW)u... 27a0: 92 50 14 49 06 B0 4C F0 97 82 1B 22 34 08 8F 15 .P.I..L....«4... 27b0: 7C 6F 62 F8 4A 8B 09 E5 30 04 36 13 7A AF 39 BA |ob.J...0.6.z.9. 27c0: AF 22 36 CC DB BD 8F 53 2F C1 82 FE 9E BD 77 B6 .„6....S/.....w. 27d0: 14 21 C3 2F 66 37 CE C2 ED BB 8C A6 E8 B1 ED C3 .!./f7.......... 27e0: DF 6F 68 A4 D6 DE 6B 5F 09 FE 72 52 C5 64 9F 19 .oh...k_..rR.d.. 27f0: A4 B3 AB 0A ED F0 E2 BF E5 2C CD C6 BC 32 13 07 .........,...2.. 2800: F1 73 4F 2E A5 55 ED 65 EA 8E 12 7D 7D E0 AF 63 .sO..U.e...}}..c 2810: A1 CE EE D4 68 8A 9D C5 CF 45 98 F0 0A B7 98 9B ....h....E...... 2820: 08 59 ED 46 5C F2 F7 53 DD 93 25 9C 76 3D 31 9B .Y.F\..S..%.v=1. 2830: E2 39 2D 7F 9C 7A 1A 5A 7F 4F 44 06 4F B9 A7 97 .9-..z.Z.OD.O... 2840: A4 52 DE 79 02 49 5C 49 67 91 18 46 10 DE A2 48 .R.y.I\Ig..F...H 2850: 73 1A D8 D8 96 A3 3D 9F 21 99 67 1E A9 5C 75 5D s.....=.!.g..\u] 2860: B3 B2 1B 20 8F 65 0B EF 8D ED 9A A8 56 9F 38 56 ... .e......V.8V 2870: AA 1A 17 60 D2 CD 08 9B C5 E9 0C B4 82 E7 72 E9 ...`..........r. 2880: C3 39 47 47 0E 94 88 47 1F 12 76 AB 27 77 58 16 .9GG...G..v.'wX. </code>

14 21 C3 2F 66 37 CE C2 ED BB 8C A6 E8 B1 ED C3

проверил cp1251, koi8-r, cp866, получается хрень непонятная.

кстати если кому интересно, chatvdvoem.ru до сих под уязвим.=)

Ну и смотри, кто запрещает-то? Скажи sed, что хочешь посмотреть с 7 по 13 строки и делов-то.

А хрюникод?

короче не один редактор не справляется с таким объемом

Ради интереса сейчас склеил сейчас разные логи в файл объемом 2гига. Все прекрасно открывается в vim и emacs. У тебя, случайно, не 32 бита, ась?

короче не один редактор не справляется с таким объемом.

1.5gb? Ты гонишь. Только что открыл файл размером 923207680 байт vim'ом.

У тебя, случайно, не 32 бита, ась?

на 32х битах тоже открывается. Лишь-бы памяти хватило. Да, медленно конечно.

Только что открыл файл размером 923207680 байт vim'ом.

Это меньше, чем у ТС.

Разбей его при помощи dd

bs=bytes
              Читает и пишет по bytes байт за раз.  Данная  опция  перекрывает
              опции  ibs  и  obs.   (Кроме  того, установка bs не эквивалентна
              установке обеих опций ibs и obs в то  же  значение,  по  крайней
              мере, когда не задано преобразований отличных от sync, noerror и
              notrunc, так как она оговаривает, что каждый входной блок  будет
              копироваться   на  выход  как  отдельный  блок  без  объединения
              коротких блоков).


skip=blocks
              Пропускает blocks блоков длины ibs байт во входном  файле  перед
              началом копирования.


 count=blocks
              Копирует лишь blocks блоков длины ibs байт из входного файла,  а
              не весь входной файл, как обычно.

на 32х битах тоже открывается.

Редактор читает файл частями, что ли? А если поиск по тексту, каждый раз перезагружает части? Что-то я сомневаюсь.

Это меньше, чем у ТС.

какая разница? Просто под рукой была серия сериалчика. Могу и слить пару серий. Я в своё время и поболее дампы БД открывал. Хотя конечно sed справляется лучше.

Разбей его при помощи dd

для этого есть split. Хотя гвозди я тоже забивал отбойным молотком. При должной сноровке это возможно.

Редактор читает файл частями, что ли?

а хрен знает. 1.5Гб это не 4+, далеко до лимита.

какая разница?

Ну разница такая, что если редактор кушает память в полтора раза больше чем объем файла (служебные данные на каждую строку и т.д.) то 1гиг файла займет 1.5гига оперативки (помещается в процесс на 32 битах), а 1.5гига файла займут 2.25гига оперативки (не помещается в процесс на 32 битах).

Но в целом, конечно, ТС просто криворук.

1.5Гб это не 4+, далеко до лимита.

Во-первых лимит 2гига, во-вторых в памяти файл будет занимать больше, т.к. данные хранятся не в виде простых строк (для ускорения работы).

less

Редактор использует динамически прогружаемое дерево с очень хитрыми свойствами, потому и не тупит в отличие от глупых «загружу-ка все в память». Я когда-то где-то читал статью с полным описанием движка, но теперь не могу найти.

По теме: разве она соответствует правилам? Чем это лучше той внц-крысы?

Ну разница такая, что если редактор кушает память в полтора раза больше чем объем файла

ну это уж ты через край хватанул. Vim примерно столько же кушает (если перекодировку отключить, а то он обычно в utf-8 конвертит, что для русского текста как минимум +70%)

а 1.5гига файла займут 2.25гига оперативки (не помещается в процесс на 32 битах).

с чего это? AFAIK до 3х гигов без проблем, или нет?

PS: да, я на 64х битах тестил, а на нетбуке(единственная 32 под рукой) всего 1000Мб мозгов, и там ВЕСЬ /home/. Если и взлетит, то только в init 1 и со свопом на гиг. Мне лень.

Во-первых лимит 2гига

дай пруф что-ли. AFAIK стандартная реализация gcc не даёт проблем до 3х ГБ, как и glibc. (хотя мне это не проверить, т.к. нет под рукой 32х битных систем с 2+ Гб).

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

накладные расходы не очень велики, если средняя длинна строк ~50 байт и больше.

если строки в начале, то, может, head поможет?

дай пруф что-ли.

Сейчас погуглил, оказывается я отстал от жизни. Лет так 5-7 назад было в ядре было по умолчанию 2гига, а 3 гига шло опцией. Сейчас такой опции вообще нет, а 3гига сделали по дефолту. Мой пардон, давно не ковырял 32 бита.

накладные расходы не очень велики, если средняя длинна строк ~50 байт и больше.

Ну про полтора раза я сказал так, для примера. Посмотрел, пустой vim VSZ=50M, с моим тестовым файлом 2.1G VSZ=2.5G, т.е. ~20%.

Уже нет. Или у меня эксплоит неправильный?

Мой пардон, давно не ковырял 32 бита.

да я тоже не вдавался особо, потому что раньше у меня было 32 бита, но памяти немного. А сейчас я даже на десктоп с 1500Мб ставлю 64(для совместимости).

с моим тестовым файлом 2.1G VSZ=2.5G, т.е. ~20%.

на реальных дампах БД(говнокод MySQL сгенереный каким-то говнодвижком на php) у меня получалось <10%. Но это всё равно намного хуже sed(которая читает построчно, и жрёт памяти примерно как самая длинная строка).

короче не один редактор не справляется с таким объемом.

ты vim не пробовал

dd бери, и ничего разбивать не надо

joe.

Хороший вопрос кстати, я так и не нашел ничего гуевого для этого. В винде это умеет akelpad и notepad++, в линуксе и макоси - не нашел. И файлы у меня побольше - гигабайт на 10-20.

Блокнот под вайном

У меня vim 3ГБ данных открывал не поперхнувшись...

там одна строка скорее всего

Была та же проблема, только файлики еще больше. Решение - любой шестнадцатиричный редактор. Да, не совсем удобно, задо может открыть любый файлы.

любой

они тоже файл в память читают, почти все гуёвые на онтопике. как это ни печально, но okteta тоже.

bless не читает

Sam или Acme.

gvim

sublime text

чем открыть .txt весом 1.5gb

Попробуй консольный unlink.