Действительно ли возможно в ударе, начать читать файл из arbitary смещения количества байта?
Каждый дистрибутив и оболочка имеют различный набор команд по сравнению со встроенными функциями оболочки. Обычно идея состоит в том, что оболочки создают - в наиболее распространенных и простых функциях, чтобы сэкономить время, скорость, и интегрируются, будет с остальной частью их набора функций. Издержки намного ниже, так как они не должны запускать другой системный процесс. Однако это возможно к смешиванию и подгонке. Вы могли бы выполнить одну оболочку, которая имеет здание для чего-то, но имейте ту команду в своей системе также. Обычно встроенное брало бы приоритет, но Вы могли управлять этим.
Можно легко узнать, является ли определенная команда встроенным или не путем выполнения type mycommand. Большинство страниц справочника оболочки также имеет список своего builtins.
Править: Использовать type узнать, является ли команда встроенным, и если нет which изучить, откуда это будет выполняться.
for (( block = 0; block < 16; block += 1 ))
do
echo $block;
dd if=INPUTFILE skip=$((block*512))MB bs=64 count=1 status=noxfer 2> /dev/null | \
head -n 1
done
который.. не создает разделенных на временный файл файлов, пропускает блоки * 512 МБ данных при каждом выполнении, читает 64 байта из того положения и ограничивает вывод первой строкой этого 64 байта.
Вы могли бы хотеть корректироваться 64 к тому, что Вы думаете, что Вам нужно.
Это кажется, что Вы хотите:
tail -c +1048576
или безотносительно числа байтов Вы хотите пропустить. Знак "плюс" говорит хвосту иметь размеры от запуска файла вместо конца. При использовании версии GNU хвоста, можно записать что как:
tail -c +1M
Для получения постоянного числа байтов после сокращения, вместо всей остальной части файла, просто передайте его по каналу через голову:
tail -c +1048576 | head -c 1024
-
1Linux/удара является потрясающей (я определенно потратил слишком долго переключение на Linux). Я только что принял ответ akira, но я вытянул это, пока я не оцениваю это более полно.
ddпереходы к определенному байту (как делаетtail), но это - кодирование боли вокруг неизвестных длин строки и затем вызов к sed для снятия изоляции с ведущих частичных строк... Похоже, что tail|head может сделать это безболезненно (как быстро?). Я не понимаю, как голова может выключить касание на хвосте, но это кажется :) Это должен быть случай: Если голова прекращает получать, хвост прекращает отправлять (и останавливает дополнительные материалы для чтения). Должен пойти.. назад завтра. – Peter.O 03.03.2011, 04:06 -
2@fred.bear:
tail/headне могут ослепить, предполагают длины строки также. необходимо перейти к позиции x, и затем можно или выглядеть левыми или правыми из x для следующего\n. не имеет значения, чем называют программу. таким образом в обоих случаях Вы переходите к x и затем используетеheadнаправо искать следующий конец строки. – akira 03.03.2011, 11:22 -
3
tail|headпредлагает способность, которая не будет затронута вообще оddcount=val. С 'dd', если я не захватываю достаточно данных, это "игра закончена". Гибкость arbitary длин строки является большой. Я записал функцию для 'dd', который возвращает "следующую ближайшую" сплошную линию и ее смещение, но я предпочел бы избегать проблемы длины. Я теперь протестировал tail|head, и он первоначально работает хорошо (к offset=100MB), но замедляется существенно для взятия 2 минут для одного доступа в offset=8GB (я могуawkэто в 1 минуту)..., таким образом, это является большим для меньшего файла.. Спасибо за то, что сделали меня знающий о комбинации :) – Peter.O 03.03.2011, 14:57
Я попробовал бы что-то вроде этого для разделения журнала на блоки на 512 МиБ для более быстрого парсинга.
split <filename> -b 536870912
При поиске файла, следующее работало бы:
for file in x* ; do
echo $file
head -n 1 $file
done
Используйте тот вывод для определения который файл к grep для даты.
-
1Спасибо, но это медленнее, чем последовательный поиск. Взгляните на мои комментарии здесь unix.stackexchange.com/questions/8121 / … (вместо того, чтобы переписать то же самое здесь) – Peter.O 02.03.2011, 08:32
-
2при помощи 'разделения' Вы касаетесь каждого байта однажды. если Вы делаете это, Вы могли просто grep целые 8 ГБ также. – akira 02.03.2011, 10:54
-
3@sifusam.. Я хочу сделать двоичный поиск разделения (не, только разделяет файлы), en.wikipedia.org/wiki/Binary_search_algorithm..., таким образом, это был хороший ответ для differnt вопроса :).. Спасибо за ответ.. +1 для получения Вас прокручивающийся.... – Peter.O 02.03.2011, 12:32
Вот мой сценарий, я ищу первую строку, было первое поле, соответствует моему числу. Строки отсортированы согласно первому полю. Я использую dd для проверки первой строки блоков 128K, затем я перехожу к блоку и выполняю поиск. Это повышает эффективность, файл, по 1M.
Любой комментарий или исправление ценятся!
#!/bin/bash
search=$1;
f=$2;
bs=128;
max=$( echo $(du $f | cut -f1)" / $bs" | bc );
block=$max;
for i in $(seq 0 $max); do
n=$(dd bs=${bs}K skip=$i if=$f 2> /dev/null| head -2 | tail -1 | cut -f1)
if [ $n -gt $search ]; then
block=`expr $i - 1`
break;
fi
done;
dd bs=${bs}K skip=$block if=$f 2> /dev/null| tail -n +2 | awk -v search="$search" '$1==search{print;exit 1;};$1>search{exit 1;};';
* РЕДАКТИРУЮТ *** grep, намного быстрее и ack еще лучше
ddдля этого также... Это - большой инструмент! Потрясающий :) – Peter.O 06.03.2011, 17:59