Ваш шаблон подстановки имен файлов почти правильный для обнаружения имен, которые имеют по крайней мере два символа подчеркивания, но вы заставляете имена иметь символ подчеркивания в самом конце.
Все будет в порядке, если вы просто добавите окончание *
в конце паттерна:
$ find. -name '*_*_*'
./file__name
./a_file_name
./more_file_name_here
Чтобы явно не сопоставлять имена с более чем двумя символами подчеркивания:
$ find. -name '*_*_*' ! -name '*_*_*_*'
./file__name
./a_file_name
Вторая часть здесь, -name '*_*_*_*'
, будет соответствовать любому имени с тремя или более знаками подчеркивания, а предшествующая !
сведет на нет смысл совпадения.
Обратите внимание, что выражение find
без -type
будет соответствовать именам файлов любого типа, то есть оно может соответствовать именам каталогов, именованных каналов, сокетов, файлов устройств и т. д.
Чтобы дополнительно сопоставлять только обычные файлы, добавьте -type f
, или вы можете использовать ! -type d
, чтобы избежать сопоставления имен каталогов. Используйте -type l
для соответствия символическим ссылкам.
Последняя команда find
может выглядеть как:
find. -type l -name '*_*_*' ! -name '*_*_*_*' -delete
Это удалит символические ссылки, найденные в текущем каталоге или ниже, чьи имена содержат ровно два символа подчеркивания. Цели символических ссылок не будут затронуты, если только они сами не являются символическими ссылками с именами, соответствующими критериям и расположенными в текущем каталоге.
Вы нашли IEEE 1003.1 -2017, также известную как Единая спецификация Unix , опубликованную The Open Group.
Для получения дополнительной информации см. «Что такое POSIX? », «Разница между POSIX, единой спецификацией UNIX и спецификациями Open Group Base? » и все вопросы, связанные с ними. и ответы.
Здесь -n
выделено жирным шрифтом, так что его трудно не заметить. И да, \c
является стандартным.
Изменения в поведении echo
печально известны. Вас не должно удивлять, что /bin/echo
— это не то же самое, что оболочка, построенная -в echo
, и что для одного требуется -e
, а для другого — нет. Это даже не так просто.
Подробное объяснение см. в " Почему printf лучше, чем echo? ".
О малоизвестной -изменчивости printf
, по иронии судьбы включающей ту же самую \c
управляющую последовательность, см. «Не работает форматирование Bash printf ».
Если вы работали на сертифицированной POSIX платформе с торговой маркой UNIX, echo
по умолчанию обрабатывал \c
.
Это относится к Solaris, AIX, HP -UX и Apple.
Apple даже использует bash
для поддержки такого эхо-поведения, но вам нужен специальный параметр компиляции, чтобы сделать bash
совместимым по умолчанию. Эта опция компиляции для bash
используется для MacOS и Solaris. Таким образом, люди могут быть сбиты с толку, когда поймут, что bash
ведет себя иначе на сертифицированной POSIX платформе,
Помните, что:GNU
читает GNU не UNIX.... многие инструменты GNU несовместимы с POSIX или несовместимы с POSIX по умолчанию. Так что будьте осторожны, когда вы не на сертифицированной платформе.
BTW :Вы можете получить брендинг POSIX для небольших встроенных платформ, даже если вы не поддерживаете echo \c
, но для брендинга UNIX
вам необходимо поддерживать всеXSI
расширения POSIX. Linux не поддерживает большинство расширений XSI
. Многие дистрибутивы Linux, например. используйте dash
в качестве оболочки по умолчанию, а идентификатор dash
определенно не соответствует требованиям, например. потому что он не поддерживает многобайтовые символы.