Как сделать, чтобы глобальные классы символов bash учитывали регистр?

Question

Я создал несколько файлов, таких как knob_A.png и knob_a.png и моя напарница по Windows сказала, что это вызвало проблемы с ее приложением. Я решил назвать его knob_W.png вместо knob_a.png . Затем я сделал rsync до нашего общего сервера. Для того, чтобы навести порядок, я тогда сделал

rm knob_[a-d]*.png

и он удалил knob_A.png тоже. Это неправильно как футбольная бита.

Ни shopt -s nocaseglob ни shopt -u nocaseglob не ведут себя так, как я хочу.

Как мне сказать bash, чтобы его глобусы были чувствительны к регистру, как в старые времена?

Answer 1

Bash чувствителен к регистру. Проблема заключается в порядке сортировки символов в диапазоне. Из руководства Bash (info bash):

Порядок сортировки символов в выражениях диапазона определяется текущей локалью и значением переменной оболочки 'LC_COLLATE', если она установлена.

Например, в языковом стандарте C по умолчанию «[a-dx-z]» эквивалентно «[abcdxyz]». Многие локали сортируют символы в порядке словаря, и в этих локалях «[a-dx-z]» обычно не эквивалентно «[abcdxyz]»; например, это может быть эквивалентно '[aBbCcDdxXyYz]'. Чтобы получить традиционную интерпретацию диапазонов в выражениях в скобках, вы можете принудительно использовать локаль C, установив для переменной окружения 'LC_COLLATE' или 'LC_ALL' значение 'C'.

Попробуй сделать

export LC_COLLATE=C

Answer 2

Bash имеет опцию оболочки для сохранения соответствия шаблону, поэтому регистр не игнорируется во время расширения. Вы можете добавить shopt -s globasciiranges в ваш скрипт, чтобы включить регистрозависимые совпадения, и отключить его с помощью shopt -u globasciiranges . См. Bash Reference - Shopt Builtin

В качестве альтернативы вы можете использовать LC_COLLATE=C как указано в другом ответе, но убедитесь, что он был экспортирован в вашу среду с export LC_COLLATE