1. Готовим среду:
mkdir -p ~/work/logseek
cd $_ # or cd <ALT-_> or cd <ALT-.>
seq 1 10 > test.log
sed -i 's/5/5 ERROR/; s/7/7 ERROR/' t<TAB>
cat t<TAB>
2. Где-то надо хранить значение строки. Можно в БД, в облаке, но
реально нам нужен простой файл:
echo 3 > nline
3. Сам не знаю, почему `cat nline` работает без убирания символа
перевода строки:
sed -n "$(cat nline)"',$p' test.log | grep ERROR
4. Соображаем, что № последней проверенной строки равен количеству строк:
wc -l test.log
Смотрим на вывод:
wc -l test.log | sed -r 's/(^[0-9]+).*/\1/'
5. Сводим все в тестовый скрипт:
lf=test.log
nf=nline
ef=errors.log
msg=ERROR
sed -n $(cat "$nf")',$p' "$lf" | grep "$msg" >> "$ef"
wc -l "$lf" | sed -r 's/(^[0-9]+).*/\1/' >"$nf"
6. Тестируем:
sh -x script
cat nline
cat errors.log
seq 11 15 | sed 's/12/12 ERROR/; s/13/13 ERROR/' >> test.log
sh script
cat nline
cat errors.log
7. Выбираем место для "nline"-файла, меняем скрипт на работу с
аргументами, добавляем шибанг, атрибут выполнения, тестируем с
реальными параметрами и файлами, документируем, прописываем в cron.
8. Думаем о том, что grep, когда используется sed, ненужен. Меняем.
Думаем, что используя tail скрипт может вообще летать. Меняем,
возвращаем grep. Тестируем на время, убеждаемся, что разницы во всех
трех скриптах нет. Через пару лет обнаруживаем, что действительно
скоростным решением было бы использование tac, но поскольку работаем
на гораздо более мощной машине - плюем на это.
ЗЫ До чего же очередной утренний приступ нехотения работать доводит.
