Используйте 'меньше' пейджер на файле с нестандартным кодированием
Я часто использую less пейджер для просмотра файлов журнала. Обычно я использую less -F следовать за прогрессом журнала а-ля tail.
Однако некоторые файлы журнала используют национальные характеры в нестандартном кодировании (латинский 1, в то время как система использует UTF-8). Очевидно, они не будут отображены правильно.
Как я могу просмотреть такие файлы с less?
Единственные решения я нашел:
- Исправьте кодирование файла (
recodeилиiconv). Это не работает, в то время как файл все еще пишется, не позволяет мне использоватьless -F. Плюс он уничтожает файлы журнала исходная метка времени, которая плоха с точки зрения аудита. - Используйте канал (
recode latin1... |less). Работы для происходящих файлов, но к сожалению затемless -Fкажется, не работает (это просто не обновляет; я верюrecodeобработайте выходы, после того как это сделано).
Какое-либо решение, которое позволяет мне "выследить" файл журнала и все еще показывает национальные характеры правильно?
3 ответа
Гм, по-видимому less не может сделать этого. Часть в исходном коде less', который реализует "следующее", кажется:
A_F_FOREVER:
/*
* Forward forever, ignoring EOF.
*/
if (ch_getflags() & CH_HELPFILE)
break;
cmd_exec();
jump_forw();
ignore_eoi = 1;
while (!sigs)
{
make_display();
forward(1, 0, 0);
}
ignore_eoi = 0;
Насколько мое (ограниченное) знание C идет, это означает, что, если "следуют", активируется, меньше будет:
- ищите в конец входа
- считайте и обновите дисплей в цикле, пока Ctrl-C не будет нажат
Если введенный pipel, 1. не возвратится, пока канал не сигнализирует о EOF. Если я использую tail -f xx|less, канал никогда не будет сигнализировать о EOF, таким образом, меньше зависнет :-(.
Я действительно однако находил способ получить то, что я хочу:
tail -f inputfile | recode latin1.. > /tmp/tmpfile
затем
less +F /tmp/tmpfile
Это будет работать, потому что это позволяет меньшему количеству +F работать над реальным файлом. Это является все еще несколько неловким, потому что recode по-видимому только обрабатывает данные в блоках 4 096 байтов, но они работают...
Это возможно это recode буферизует вывод в канале, таким образом, производит, только проникает, когда буфер, вероятно, 4K, полон. Можно попытаться использовать unbuffer сценарий, который идет expect.