11492 2007-04-12 20:05:28 +0400 /usr/bin/tac некорректно выводит файл с отсутствующим carriadge return в конце файла 2008-08-30 16:13:17 +0400 1 1 4 Development Sisyphus coreutils unstable all Linux CLOSED NOTABUG P2 major --- 1 hiddenman placeholder glebfm ldv php-coder placeholder vt qa-sisyphus oldest_to_newest 48736 0 hiddenman 2007-04-12 20:05:28 +0400 Если в файле содержится больше одной строки и в конце последней строки нет символа "возврата каретки", то tac выводит последние две строки как одну. В coreutils 6.9, судя по diff между старым и новым tac.c, это тоже воспроизводится. Steps to Reproduce: 1.echo first >>testfile 2.echo second >>testfile 3.echo -n third >>testfile 4. tac testfile Actual Results: thirdsecond first Expected Results: third second first 50461 1 hiddenman 2007-05-21 02:55:00 +0400 Из-за этого "бага" в etcnet будут некорректно обрабатываться файлы ipv[46]rule,route и правила *tables при "остановке", если нет символа перевода строки в последней строке. 50530 2 ldv 2007-05-21 18:24:08 +0400 Я не знаю, это bug или нет. Напишите, пожалуйста, на bug-coreutils@gnu.org 66419 3 at 2008-03-23 03:59:52 +0300 Я считаю, что это баг. Если tac(1) читает построчно, то выводить тоже должен построчно. Склейка последней и предпоследней строк в одну строку в случае no newline at EOF явно противоречит идее "построчно". По аналогии можно, рассмотрим работу sort(1): $ printf 'B\nA' |sort A B $ Если бы sort(1) вывел "AB", то это был бы номер. 66420 4 at 2008-03-23 04:25:05 +0300 Вариант согласования с документацией 'info tac': если встречаем EOF без окончательно сепаратора, то такой EOF сам по себе канает за сепаратор. В противном случае два последних records -- последний и предпоследний -- безвозвратно склеиваются, что вряд ли логично. $ echo -n a:b:c |tac -b --separator=: :c:ba$ 76668 5 ldv 2008-08-30 16:13:17 +0400 Я не готов трактовать это поведение как ошибочное, Изложите, пожалуйста, вашу точку зрения на bug-coreutils@gnu.org