BTRFS :Список Crc блоков файла

Используйте /usr/xpg4/bin/grepв Solaris для чтения шаблонов из файла с помощью -fи сравнения строк с помощью -F, затем

find /export/home/testing -type f -name apache_logs.txt -exec tail -n 50 {} \; |
/usr/xpg4/bin/grep -vF -f avoid.txt >result.txt

... где avoid.txt— текстовый файл со строкой в ​​каждой строке:

akamai/sureroute
/wp7/wp-login.php
HTTP/1.0" 200
HTTP/1.1" 200

Это будет искать обычные файлы с именем apache_logs.txtв каталоге /export/home/testingили в нем. Для каждого такого файла вызывается tail -n 50, чтобы получить последние 50 строк (в соответствии с вашим кодом; используйте catвместо tail -n 50, чтобы получить все содержимое каждого файла ).

Полученные строки текста передаются по конвейеру через /usr/xpg4/bin/grep, который отфильтровывает (удаляет )каждую строку, содержащую любую из подстрок, перечисленных в файле avoid.txt.

С параметром grepиспользуются следующие параметры:

• -vинвертировать смысл совпадения (возвращать строки не соответствующие шаблону ).
• -Fдля обработки каждого шаблона как строки и выполнения сравнения строк, а не сопоставления с регулярным выражением. Это позволяет шаблонам в файле содержать символы, которые в противном случае были бы специальными в регулярных выражениях, без их экранирования.
• -f avoid.txtдля чтения паттернов из файла avoid.txt.

Остальные строки текста записываются в result.txt.

Без опции -Fвам пришлось бы быть немного осторожнее с шаблонами в avoid.txtи сделать их правильными регулярными выражениями. Может что-то вроде

akamai/sureroute
/wp7/wp-login\.php
HTTP/1\.[01]" 200

Если вы ожидаете, что ваш findнайдет только отдельный файл , код можно упростить до

tail -n 50 /path/to/apache_logs.txt |
/usr/xpg4/bin/grep -vF -f avoid.txt >result.txt

Есть несколько проблем с вашим кодом:

• Вы не цитируете расширения переменных. См. . Когда необходимо двойное -цитирование?
• Вы напрасно сохраняете результат конвейера в переменной, а затем используете echoдля вывода результата в файл.
• Ваш первый конвейер tail+ grepиспользует $fileс обеих сторон канала.Это заставит grepигнорировать ввод от tail.

• Ваш второй (более длинный )конвейер будет использовать result1.txtтолько для последнего grep, а более ранние grepкоманды будут ожидать чтения данных из стандартного ввода (их не будет )и в конце концов будет убит, когда будет выполнено последнее grep.

  Конвейер такого типа обычно выглядит так

  command inputfile | command | command | command
  

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

• Выходной файл, result.txt, перезаписывается с нуля для каждого найденного apache_logs.txtфайла, так как вы записываете в него, используя >в цикле. Это может быть нормально, если вы ожидаете, что findнайдет только один файл (, и в этом случае было бы лучше вообще не использовать find, так как файл, по-видимому, не будет перемещаться в файловой системе )..

• Вы анализируете выводfind(пути к найденным файлам )с помощью read. Как правило, это плохая идея, так как пути в Unix могут содержать любой символ, включая символ новой строки и обратную косую черту, за исключением символа nul (\0), который является ограничителем строки в языке программирования C. См. Почему зацикливание вывода find является плохой практикой?

Также связанные:

• Описание параметра -exec команды `find`