Как неинвазивно проверить доступ на запись в файл?

В сценарии оболочки, как я могу легко и неинвазивно проверить доступ на запись в файл без фактической попытки изменить файл?

Я мог бы проанализировать вывод stat, но это кажется действительно сложным и, возможно, хрупким, хотя я не уверен, насколько статистический вывод отличается в разных реализациях и времени.

Я мог бы добавить в конец файла и посмотреть, если это удастся, но это потенциально опасно, по двум причинам, которые я могу думать:

1. Теперь мне нужно удалить дополнение, и в случае, если какой-то другой процесс записывает в файл, это сразу становится нетривиальным, так как моя строка больше не является последней.
2. Любой процесс, читающий файл, может иметь произвольные требования к содержимому этого файла, и я, возможно, просто нарушил это приложение.

Просто используйте - wфлаг использования test:

[ -w /path/to/file ] && echo "writeable" || echo "write permission denied"

Обратите внимание, что если вы собираетесь записать файл позже, все еще возможно, что вы не сможете писать в него. Возможно, файл перемещен, разрешения могут быть изменены и т. Д. Также может случиться так, что -wобнаружатся разрешения на запись, но вмешивается другой фактор, который делает файл недоступным для записи .

Другой подход:

if >> /path/to/file
then
    echo "writeable"
else
    echo "write permission denied"
fi

Это попытается открыть файл для добавления и, если это удастся, не выполнить команду (то есть выполнить нулевую команду ) с выводом в файл. 

Помните, что это создает пустой файл, если он не существует.

-wОператор testкоманды может просто сделать , stat а затем попытаться выяснить , выглядит ли это , как вы должны иметь доступ. Моя альтернатива (выше) более надежна, чем testподход в некоторых особых условиях, потому что она заставляет проверку доступа выполнять ядро, а не оболочка. Например,

• если файл находится в файловой системе не-Unix - особенно если он удаленно монтируется с файлового сервера не-Unix - потому что statможет вернуть значение режима, которое вводит в заблуждение.
• если файл находится в файловой системе, которая монтируется только для чтения.
• если файл имеет ACL, и режим делает его похожим на то, что у вас должен быть доступ, но ACL запрещает его, или наоборот.
• если какая-то инфраструктура безопасности (AppArmor, SELinux,…) запрещает доступ к файлу.

G-мужчина прав: [ -w ]не всегда говорит правду. Здесь, чтобы справиться с несуществующим файлом и сообщением об отказе в доступе из оболочки:

( [ -e /path/to/file ] && >> /path/to/file ) 2> /dev/null && 
  echo writable || 
  echo not writable

Обновление : выглядит пугающе, не так ли? Ну, это так. Хм ... как это выразить ... НЕ ИСПОЛЬЗУЙТЕ ЭТО, если только вы точно не знаете, что находитесь в условиях, которые он требует для работы, как ожидается. Смотрите комментарий Стефана.

Что делать вывод тогда? Даже если [ -w ]не говорит правду, это единственная команда, которая предназначена для выполнения этой работы. Если этого не произойдет, мы обвиним в этом, напишем отчеты об ошибках, и это сработает в будущем. Лучше проверить условия, при которых он работает и использовать [ -w ]; написать специальный код для особых случаев. Обходные пути имеют свои условия.

[ -w /path/to/file ]

лучший априори .