grep --colour=auto и пустой выхлоп

А проверить для начала выхлоп? тот же cat -A, и выяснить для начала какая именно часть приводит к такому поведению.

отображается только одна строка вначале которой стоит $.

После разворачивания на весь экран у переменных среды LINES и COLUMNS правильные значения?

Да,в данном случае 67*159.

Немного неверно написал, так как одна строка таки отображается.

Вот она:

./libraries/spacer.php:57:		$html[] = '<span class="spacer">';

grep -rni '.spacer.' .

Лучше опишите проблему полностью, потому что не понятно, в чём именно проблема. Отображатся должно больше строчек? Они должны быть цветными?

Проблема в том что отображается только 1 строка (вообще отображается), вместо остальных просто пустота. Вот скрин

Если указать --colour=none, то отображаются все строки, или как вариант grep ...|cat -A.

Интерестное поведение.

Если указать ″--color=always″, и перенаправить вывод grep'а в файл, то файл будет с управляющими последовательностями. Дальше этот файл можно вывести с помощью ″cat″ и получить цветной текст.

Если сравнить файлы получаемые при обычном размере терминала и при развёрнутом, попробовать вывести файл в обычном терминале и в развёрнутом то тогда станет ясно, проблема в grep или в терминале.

Попробую, но судя по всему в grep. Я уже пробовал в xterm, sakura и terminator - везда аналогично.

В общем если кому интересно, то это своего рода баг вывода цветного grep, если в файле присутствует перенос строк в dos стиле (\r) grep (colored) почему-то не переваривает его, и выводит в таком виде, что приводит к очищению выводимой строки. Вот думаю стоит ли постить багрепорт.

В дос стиле — в смысле \r\n — два символа?

да. Вот пример файла http://www.sendspace.com/file/39ouyh (grep -i '.spacer">.' default.php)

У меня вот так вот работает:

grep --color=always -H -i '.spacer">.' default.php | tr -d '\r'

Если терминал сжать до такого размера, что последний символ выводимой строки не будет виден ('\r'), то терминал его не обработает и строка будет видна. А иначе, терминал выводит всю строку, потом обрабатывает воврат каретки '\r', предвигает курсор в начало строки без перевода строки и выведенный текст исчезает. Если запустить xterm по медленной сети, то цветные строчки даже успевают промелькнуть. Поэтому у вас и влиял размер терминала.

Вот, допустим, команда:

echo -e 'aaa\rbb'

напечатает «bba».

Похоже, что grep в вашем случае хочет печатать цветом до конца строки '\n' включая в шаблон '\r'. Этот самый '\r' он тоже печатает цветом, а потом, между '\r' и '\n' выводи esc-последовательность, переключающую цвет.

Мне не хочется разбиратся в ESC-последовательностях, но, похоже, что терминал правильно делает, стирая строку, получив «0d 1b 5b 6d 1b 5b 4b». И grep тоже делает правильно, выводя ESC-последовательность после '\r', а не перед.

Я не знаю, какого именно вывода вы хотели от последней точки в вашем регулярном выражении. По идее у вас после ″>″ идёт перевод строки, но так как он состоит из двух байт, то возврат каретки '\r' попадает в выражение и раскрашивается. Такое вот:

grep --color=always -H -i '.spacer">[^'$'\r'']' default.php

grep --color=always -H -i '.spacer">[^'$'\r'']*' default.php

grep --color=always -H -i '.spacer.' default.php

P.S. У меня там башизм ″$'\r'″, не знаю как по другом указать grep'у символ возврата каретки.

Я не знаю, какого именно вывода вы хотели от последней точки в вашем регулярном выражении

Любой символ, тогда это вообще было спонтанно написано.

Согласен что это криво, но в любом случае греп не должен выводить перенос таким образом, мне кажется. Должна быть какая-то защита «от дурака».

Что бы не было вот так:

[user@localhost:~]$ grep -i '."spacer">.' default.php | od -c
0000000  \t  \t  \t  \t  \t   <   d   i   v       c   l   a   s   s   =
0000020   "   s   p   a   c   e   r   "   >  \r  \n  \t  \t  \t   <   d
0000040   i   v       c   l   a   s   s   =   "   s   p   a   c   e   r
0000060   "   >  \r  \n
0000064

Ха, оказалось это старый баг. http://savannah.gnu.org/bugs/?25539