Coreutils realpath : запутанный вывод при использовании с жесткой (?) ссылкой
Это всего лишь пример сценария, который вы можете использовать для изменения в соответствии с вашими потребностями.
FILE="xxxx_xxx_`date +"%Y-%m-%d"`_0.log"
grep -E "maxretry|not synchronized|FCS Bad receipt" $FILE > fcs_error.log
if [[ $(wc -l fcs_error.log | awk '{print $1}') -gt 0 ]]; then
mail -s "error found" mail_id Проверьте cron , как планировать задания.
Используйте параметр -n команды grep для печати номера строки. См. grep для получения более подробной информации.
Я проверял это, и у меня этого не происходит. Я подозреваю, что (, как было предложено ), это связано с символической ссылкой где-то, поскольку realpathразрешает их.
Попробуйте:
ls -li /bin/pip /usr/bin/pip
Это должно дважды проверить, что две записи каталога ссылаются на один и тот же inode/файл (либо прямо, либо косвенно ).
Теперь попробуйте:
ls -ld /bin /usr/bin
Это должно показать два каталога(dв первом столбце ). Если один из них (почти наверняка /usr/binпоказывает lв этом столбце, то это символическая ссылка, и это объясняет поведение, которое вы видите (, как отмечалось ранее, realpathразрешает символические ссылки ).
Окончательное уточнение :если один из /binили /usr/binявляется символической ссылкой на другой, realpathбудет следовать символической ссылке к своей цели и использовать эту цель в качестве реального пути.
GNU realpath(, но не все остальные )имеют опцию --no-symlinks; если вы используете это, вы, вероятно, получите результат, который вы изначально ожидали.