$ VAR vs $ {VAR} и цитировать или не указывать

я могу написать

VAR=$VAR1 VAR=${VAR1} VAR="$VAR1" VAR="${VAR1}" 

конечный результат для меня все кажется примерно одинаковым. Зачем мне писать то или другое? являются ли какие-либо из них не переносимыми / POSIX?

3 Solutions collect form web for “$ VAR vs $ {VAR} и цитировать или не указывать”

VAR=$VAR1 – упрощенная версия VAR=${VAR1} . Есть вещи, которые второй может сделать, что первый не может, например, ссылаться на индекс массива (не переносимый) или удалять подстроку (POSIX-портативный). См. Раздел « Дополнительные сведения о переменных » руководства Bash для начинающих и расширения параметров в спецификации POSIX.

Использование цитат вокруг переменной как в rm -- "$VAR1" или rm -- "${VAR}" – хорошая идея. Это делает содержимое переменной атомной единицей. Если значение переменной содержит пробелы (ну, символы в специальной переменной $IFS , пробелы по умолчанию) или заглавные символы, и вы не цитируете их, тогда каждое слово рассматривается для генерации имени файла (globbing), расширение которого составляет столько аргументов, сколько что бы вы ни делали.

 $ find . . ./*r* ./-rf ./another ./filename ./spaced filename ./another spaced filename ./another spaced filename/x $ var='spaced filename' # usually, 'spaced filename' would come from the output of some command and you weren't expecting it $ rm $var rm: cannot remove 'spaced': No such file or directory # oops! I just ran 'rm spaced filename' $ var='*r*' $ rm $var # expands to: 'rm' '-rf' '*r*' 'another spaced filename' $ find . . ./another ./spaced filename ./another spaced filename $ var='another spaced filename' $ rm -- "$var" $ find . . ./another ./spaced filename 

О переносимости: согласно разделу 2.6.2 POSIX.1-2008 фигурные скобки необязательны.

${VAR} и $VAR в точности эквивалентны. Для простого расширения переменных единственной причиной использования ${VAR} является то, что при синтаксическом анализе в противном случае количество символов в имени переменной будет ${VAR1}_$VAR2 (которое без фигурных скобок будет эквивалентно ${VAR1_}$VAR2 ). Большинство украшенных расширений ( ${VAR:=default} , ${VAR#prefix} , …) требуют скобки.

В переменной присваивается разделение поля (т. Е. Расщепление в пробеле в значении) и расширение пути (т. VAR=$VAR1 ), поэтому VAR=$VAR1 в точности эквивалентен VAR="$VAR1" , во всех оболочках POSIX и во всех pre-POSIX sh, о котором я слышал. (POSIX ref: простые команды ). По той же причине VAR=* надежно устанавливает VAR в литеральную строку * ; конечно, VAR=ab устанавливает VAR в a так как b является отдельным словом в первую очередь. Вообще говоря, двойные кавычки не нужны, когда синтаксис оболочки ожидает одно слово, например, в case … in (но не в шаблоне), но даже там вам нужно быть осторожным: например, POSIX указывает, что цели перенаправления ( >$filename ) не требуют цитирования в сценариях, но несколько оболочек, включая bash, требуют двойных кавычек даже в скриптах. См. Когда требуется двойное цитирование? для более тщательного анализа.

Вам нужны двойные кавычки в других случаях, в частности, в export VAR="${VAR1}" (что может быть эквивалентно записывать export "VAR=${VAR1}" ) во многие оболочки (POSIX оставляет этот случай открытым). Сходство этого случая с простыми присваиваниями и разбросанность списка случаев, когда вам не нужны двойные кавычки, – вот почему я рекомендую использовать двойные кавычки, если вы не хотите разделить и glob.

 ls -la lrwxrwxrwx. 1 root root 31 Nov 17 13:13 prodhostname lrwxrwxrwx. 1 root root 33 Nov 17 13:13 testhostname lrwxrwxrwx. 1 root root 32 Nov 17 13:13 justname 

конец:

 env=$1 if [ ! -f /dirname/${env}hostname ] 

стоит упомянуть в качестве более ясного примера использования колючек

  • Что происходит, когда скрипт встречает ошибку в одной из команд?
  • Как я могу группировать числа в файле
  • Все файлы не загружаются скриптом SFTP
  • Может ли кто-нибудь уточнить для меня о глобальной переменной в этом сценарии оболочки?
  • Прогулка по файлам в каталоге случайным образом
  • Как пропустить невосприимчивый сервер
  • source / dev / stdin не работает должным образом
  • Учитывая две фоновые команды, завершите оставшуюся, когда либо выйдет
  • Скопируйте файлы, исключая x, y, z, вызывая ошибку в сценарии оболочки
  • Git Bash для Ubuntu / Linux и Windows требует перезагрузки ssh-agent
  • Создание дополнительного скрипта копирования и вставки
  • Linux и Unix - лучшая ОС в мире.