Какой стиль цитирования определений переменных GNU Bash (в основном для путей)? [закрыто]
Для простых случаев (когда вы обращаетесь к устройству как к файлу) это, как написал @Jasen:
- Разрешение на чтение позволяет читать с устройства (дамп, запуск
fsckв режиме только для чтения и т. д.) - Разрешение на запись позволяет записывать на устройство (перезаписывать изображение и т. д.)
- Оба разрешения необходимы для запуска
fsck,tune2fsи т. д. , которые должны читать и изменять файловую систему. - Разрешение на выполнение игнорируется. Если вы попытаетесь запустить файл устройства, вы получите «Отказано в доступе», даже если блочное устройство содержит действительный исполняемый код.
Если вы root, вы обычно получаете возможности CAP_DAC_READ_SEARCH и CAP_DAC_OVERRIDE , что означает, что флаги разрешений полностью игнорируются.
Для ioctls все сложнее:
Чтобы выполнить ioctl, вы должны иметь возможность открыть файл, а это значит, что вам нужно как минимум разрешение на чтение или запись .
Все остальное зависит от драйвера.
Некоторые драйверы устройств проверяют только такие возможности, как CAP_SYS_RAWIO или CAP_SYS_ADMIN, некоторые используют разрешение на чтение для «безвредных» ioctl, которые предоставляют только информацию и разрешение на чтение и запись для других ioctl. Драйвер устройства может использовать разрешение на выполнение для проверки разрешения ioctl, но я не знаю ни одного драйвера, который делает это.
Для mount это проще:
Системный вызов mount проверяет только две вещи:
- Вы должны иметь возможность достичь устройства файл.
Это означает, что все каталоги на пути к файлу устройства должны иметь как минимум установленный бит разрешения на выполнение (или вам необходимо иметь возможность
CAP_DAC_READ_SEARCH). - У вас должна быть возможность
CAP_SYS_ADMIN(которую опять же вы обычно получаете, если вы являетесь пользователем root)
Биты разрешений в самом файле устройства полностью игнорируются при монтировании и не влияют на доступ к смонтированной файловой системе любым способом.
Использование sudo запускает исполняемую программу от имени пользователя root со всеми доступными возможностями, что означает, что все проверки разрешений игнорируются.
и, как написал @Jasen в комментарии, /bin/mount обычно имеет setuid-root, что приводит к тому, что он всегда получает все доступные возможности, поэтому биты разрешения не влияют на mount на большинство дистрибутивов Linux и других операционных систем Unixoid.
РЕДАКТИРОВАТЬ: части о возможностях относятся к Linux. Другие операционные системы unixoid, такие как BSD или OSX, не разделяют специальные возможности root на возможности, поэтому, когда упоминаются возможности, вам просто нужно быть root. Судя по доступным справочным страницам, проверки для mount аналогичны проверкам для Linux, которые я описал. Кажется, нет ОС, которая проверяет биты разрешений при монтировании.
Главное:Двойные кавычки для всех строк, содержащих любую форму расширения или пробела , если только вы не знаете, что вам не разрешено (см., например. " Когда необходимо двойное -цитирование? " ). Менее важно, заключаете ли вы в кавычки только те биты, которые на самом деле нуждаются в кавычках, и оставляете не -пробельные биты, которые являются статическими вне кавычек.
Я пройдусь по вашим вариантам, по одному:
VAR="/path/$V1/path with space/$V2"Это вариант, который проще всего прочитать (личное мнение ). Все расширения переменных заключены в кавычки, и строка не будет разделена на пробелы (, поскольку она заключена в кавычки ). Я бы воспользовался этим вариантом.
Единственное, что следует помнить, как Сергей Колодяжный указал в комментарии , это то, что если имя пути содержит фактический буквальный символ двойной кавычки, это должно быть обработано либо экранированием его как
\"или временно завершив строку в двойных кавычках и вставив"в строку в одинарных кавычках, как в"this is a string with a "'"'" in it". Точно так же другие символы, которые являются специальными для оболочки,например$,\и`, потребуется одинаковая обработка в строках с двойными кавычками. Обратите внимание, что это , а не проблема, если переменная, раскрываемая в строке пути, содержит один из этих символов (, который будет обрабатываться правильно ).VAR=/path/"$V1"/"path with space"/"$V2"Этот (ИМХО )выглядит немного беспорядочно, но работает. Он заключает в двойные кавычки все/большинство компонентов пути между косой чертой. Альтернативой может быть использование одинарных кавычек, где переменные не раскрываются :
.VAR=/'path'/"$V1"/'path with space'/"$V2"
Выбор между первым или вторым вариантом зависит от вас и вашего личного вкуса (или от того, что ваша команда использует в проекте, над которым вы работаете ). Я бы посоветовал вам придерживаться одного соглашения и не использовать их сочетание, если это возможно.
Нет никакой практической разницы между двумя «способами заключения пути в кавычки», за исключением, возможно, того, что имена путей содержат литеральные символы, которые являются специальными для оболочки (они не будут особыми внутри одинарных кавычек ), и количество используемых кавычек .
Вы также упомянули
VAR="$OTHER_VAR"/path/to/somethingЯ не вижу в этом абсолютно ничего плохого, и это то, что я чаще всего использую, когда остальная часть пути статична и не содержит пробелов. Нет абсолютно никакой разницы между этим и
VAR="$OTHER_VAR/path/to/something".
Третий вариант:
VAR="/path/"$V1"/path with space/"$V2""Не делай этого. Здесь
$V1и$V2на самом деле оставлены без кавычек , поскольку вы завершаете биты в двойных кавычках вокруг расширений переменных.
Preferred here meaning, works as intended in as many cases as possible without being unnecessarily verbose,
Тогда используйте первый. Остальные имеют ненужные кавычки. Вам нужно только два.
Если внутри двойных кавычек заключено много символов, имеющих особое значение, например $, \, "или `,тогда все необходимые побеги могут стать уродливыми. Но имена файлов и пути не содержат тех, которые часто.
Does quoting the variable substitutions individually do something extra?
Нет, за исключением того, что "$foo"barсовпадает с "${foo}bar". То есть вы можете использовать кавычки вместо фигурных скобок для завершения имени переменной. ("$foobar", конечно, было бы совершенно другим.)