Problema resuelto.
La definición de terminal me da una pista para la solución. Revisé la definición de terminal SCO en /etc/termcap
, después de esa definición en Progreso en /usr/dlc7/protermcap
. Elijo otro terminal que no sea xterm, compatible y cambio la configuración de putty en Terminal ->Keyboard -> The Function keys and keypad -> VT100+
yConnection -> Data -> Terminal-type string -> vt220
Ahora la visualización y el aspecto están bien, las teclas de función como ESC y F1 -F4 se comportan como en la configuración original.
Используйте /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 является плохой практикой?
Также связанные: