Ваша проблема решена Почему мой сценарий оболочки подавляется пробелами или другими специальными символами? . Я просто кратко объясню, что здесь происходит.
Причина - для r в $ {documents [@]}
. Поскольку расширение переменной не заключено в кавычки, вы используете операцию «split + glob»: значение каждого элемента массива разбивается на слова в соответствии со значением IFS
, и каждое слово обрабатывается как шаблон подстановочного знака. Поскольку вы всегда устанавливаете IFS
только на время чтения
(см. Почему так часто используется `while IFS = read` вместо` IFS =; при чтении. .`? ), значение IFS
в этот момент является значением по умолчанию, которое включает пробелы. Кроме того, если у вас есть поле, содержащее что-то вроде foo *
, вы увидите имена файлов в текущем каталоге.Решением является для r в "$ {documents [@]}"
, что является стандартным способом итерации по массиву: двойные кавычки превращают это в прямое разыменование переменной без разделения и подстановки, и [@]
заставляет каждый элемент массива помещаться в отдельное слово.
Хотя установка IFS = $ '\ t'
для всего скрипта, похоже, решает проблему, на самом деле это решает только половину проблемы: это не предотвращает глобализацию с $ {документы [@]}
. Хотя вы можете отключить подстановку с помощью set -f
, использование двойных кавычек более понятно.
Ответ на этот вопрос был дан в этих двух вопросах:
https://superuser.com/questions/180545/setting-differing-acls-on-directories-and-files
Соответствующие биты взяты из man setfacl
:
Поле perms представляет собой комбинацию символов, указывающих на >разрешения: чтение (r), запись (w), выполнение (x), выполнение только если файл является каталог или уже имеет разрешение execute для какого-то пользователя (X). В качестве альтернативы, поле perms может быть восьмеричной цифрой (0-7).
(Подчеркнуто мной)
Соответствующий раздел из первого вопроса в ответе @slm♦ следующий:
Подведем итог
Файлы не получат разрешение execute (маскирующее или эффективное). Не имеет значения, какой метод мы используем: ACL, umask или mask & ACL.
Каталоги могут получить разрешение на выполнение, но это зависит от того, как установлено маскирующее поле.
Единственный способ установить разрешения на выполнение для файла, который находится под ACL разрешениями - это установить их вручную с помощью chmod.
Что в основном означает, что, похоже, вы не можете делать то, что хотите, с помощью ACL, поскольку очень немногие программы на самом деле явно говорят, что хотят создать исполняемый файл.
Я не думаю, что вы можете использовать ACL для принудительной установки бита разрешения .
Используя справочную страницу Linux ACL в качестве справки, ACL по умолчанию копируется в права доступа к файлу, но
- записи ACL доступа соответствуют битам прав доступа к файлу изменены так, что они не содержат разрешений, которые не содержащиеся в разрешениях, указанных параметром режима [передается в
open ()
,creat ()
и т. Д.] .
Поскольку битовая маска разрешения соответствует битам разрешения группы, здесь она затрагивается.
Если нет ACL по умолчанию, вместо него используется umask
, но та же самая маскировка по-прежнему выполняется.
Что, конечно, согласуется с обычным обычаем программы ограничивать разрешения теми, которые она передает в open
при создании файла, будь то исключение разрешений на выполнение в режиме 0666
или исключение доступа других пользователей к файлу в режиме 0600
.