Поиск подстроки во всех поддиректориях

[kt315e]

Как найти файлы содержащие заданную подстроку, включая находящиеся в поддиректориях. Возможно несколько уровней вложения. Аналогично найти все файлы у которых есть строки длинее стольки то символов.

[Kopilov]

Первая задача:

Код: Выделить всё

grep --color=auto "what to search" /where/to/search -R

вероятно.

[drBatty]

Как найти файлы содержащие заданную подстроку

Код: Выделить всё

find -exec grep {} \;

если надо найти и остановится, то

Код: Выделить всё

find -type f -ls -exec grep 'pattern' {} \; -quit

есть строки длинее стольки то символов.

Код: Выделить всё

sed -r '/.{77}/q70'

вернёт error code 70, если найдёт хоть одну строку с 77ю символами

[kt315e]

Да, вот так работает:

Код: Выделить всё

grep -R 123 .

Старые маны оказывается смотрел.

[SLEDopit]

find -exec grep {} \;

По сравнению с grep -R будет работать существенно дольше. Если уж так принципиален именно find, то хотя бы \+ используйте.

К тому же, как я могу догадываться, необходим только список файлов, в таком случае будет полезна опция -l у grep'a.

Так же стоит обратить внимание на опцию -m1, чтобы, в случае больших файлов, не читать весь файл, а остановить чтение конкретного файла после первого совпадения.

Ну и для строк с количеством символов > 77:

Код: Выделить всё

grep -Rl -m1 '.\{77\}' .

Это чуть проще решения с sed'ом, т.к. тут не нужно анализировать exit status. Ну и sed не умеет работать с несколькими файлами в представленном выше виде, т.к. будет непонятно к какомй именно файлу относится exit статус.

[drBatty]

По сравнению с grep -R будет работать существенно дольше. Если уж так принципиален именно find, то хотя бы \+ используйте.

не. Тут как раз надо по одному файлы обрабатывать,
1. что-бы вовремя остановиться.
2. что-бы вбить второй файл /dev/null, т.к. смысла нет найти строку, не зная, ГДЕ найдена эта строка.

К тому же, как я могу догадываться, необходим только список файлов, в таком случае будет полезна опция -l у grep'a.

см. вторую мою команду с -quit. Это пример. На самом деле там можно что угодно написать. И более того, сделать две вветки нашла/не нашла.

Так же стоит обратить внимание на опцию -m1, чтобы, в случае больших файлов, не читать весь файл, а остановить чтение конкретного файла после первого совпадения.

ну можно и так. Хотя тогда уж лучше sed.

Это чуть проще решения с sed'ом, т.к. тут не нужно анализировать exit status.

ну что вы за бред пишете? Кто мешает вместо q70 использовать любую другую команду, в т.ч. и bash-скрипт?
Не хоте код возврата? Да пожалуйста! Напишите что-то другое. В grep так не сделать, увы.

Ну и sed не умеет работать с несколькими файлами в представленном выше виде, т.к. будет непонятно к какомй именно файлу относится exit статус.

вот именно потому и нужно обрабатывать файлы по одному. Grep умеет, но это только для самых простых случаев подходит.

[SLEDopit]

не. Тут как раз надо по одному файлы обрабатывать,

ок, согласен, тут действительно \+ не годится. хотя работать всё равно дольше будет (:

ну что вы за бред пишете? Кто мешает вместо q70 использовать любую другую команду, в т.ч. и bash-скрипт?
Не хоте код возврата? Да пожалуйста! Напишите что-то другое. В grep так не сделать, увы.

Т.е. вы считаете, что в данном конкретном случае любая другая команда, в т.ч. и bash-скрипт, проще, чем grep с -m1, я правильно понимаю?
тут дело не в том, что в grep'e нельзя так сделать, а в том, что, имхо, sed в данном случае -- оверкилл. впрочем, с вами на эту тему бесполезно спорить: вы готовы даже в кофеварку sed засунуть.

[drBatty]

Т.е. вы считаете, что в данном конкретном случае любая другая команда, в т.ч. и bash-скрипт, проще, чем grep с -m1, я правильно понимаю?

нет, не правильно. И понимаете неправильно, и ваше "проще" тоже далеко не всегда правильно. Потому что "проверка кода возврата" вовсе и не обязательно нужна. И если она не нужна, то её и не нужно делать. Это уже вопрос совсем другой.

тут дело не в том, что в grep'e нельзя так сделать, а в том, что, имхо, sed в данном случае -- оверкилл. впрочем, с вами на эту тему бесполезно спорить: вы готовы даже в кофеварку sed засунуть.

grep с Over9000ю ключей -- тоже оверкилл. Ну и вообще, что "оверкилл", а что — нет, это мы не знаем. Зависит от задачи. Sed конечно не всегда лучший вариант, но не нужно говорить, что sed "всегда не проще" и "всегда оверкилл", если речь идёт о задаче ТС(которая вообще слабо формализована).

Я даже не представляю, что там ТС хочет искать, как, и как должны выглядеть результаты. Т.ч. grep тоже подойдёт, как вариант. Ну и sed, как другой вариант. А что из них оверкилл — это мы решим, как только условия задачи будут чётче.

ок, согласен, тут действительно \+ не годится. хотя работать всё равно дольше будет (:

а я это прекрасно знаю.

PS: чем мне нравится grep, так это раскраской, которая в grep искароппки, а в sed тоже можно, но жуткими и страшными костылями.

PPS: а чем не нравится, так это жуткой тормознутостью (которая вроде бы исправлена в посл. версии).

[Bizdelnick]

Да, вот так работает:

Код: Выделить всё

grep -R 123 .

Старые маны оказывается смотрел.

Можно короче: rgrep 123 ..

[/dev/random]

Можно короче: rgrep 123 ..

rgrep есть не везде.

[kt315e]

Спасибо всем! grep похоже подойдёт. Ковыряю фортрановские исходники с огромным количеством файлов. В частности ищу как читаются входные файлы.

[drBatty]

Ковыряю фортрановские исходники с огромным количеством файлов.

советую освоить vim+ctags+cscope.