назад тики против двойных кавычек

Я долго размышлял об этом, но не понял, как это найти –

это:

x=`command -v r2g` 

так же, как это:

 x="$(command -v r2g)" 

или это так же, как это:

 x=$(command -v r2g) 

… если это последнее, я должен сделать это, чтобы это исправить?

 x="`command -v r2g`" 

Все примеры имеют переменное назначение из подстановки команд, поэтому они эквивалентны. Согласно ответу Жиля , цитирование не обязательно в правой части присваивания переменной, так как там не происходит разбиение слов. Так что все четверо в порядке.

Если бы они были автономными, то есть не в назначении, то вам нужно было бы цитировать. Форма $(...) по сравнению с обратными чертами имеет то преимущество, что кавычки можно вкладывать и разбивать на несколько строк, поэтому в настоящее время эта форма обычно предпочтительнее. Другими словами, вы можете использовать "$( echo "$var" )" с этой формой, чтобы защитить как внутреннее раскрытие $var и внешнее раскрытие $(...) от разбиения слов и искажения имени файла.

Как показано в спецификациях POSIX Shell Command Language , встроенные многострочные сценарии не работают с обратными галочками (слева), но работают с формой $() (справа).

 echo ` echo $( cat <<\eof cat <<\eof a here-doc with ` a here-doc with ) eof eof ` ) echo ` echo $( echo abc # a comment with ` echo abc # a comment with ) ` ) echo ` echo $( echo '`' echo ')' ` ) 

Четыре примера функционально эквивалентны.

Обратные пометки устарели, и если вы не используете оболочку 1970 года, например, оболочку Борна (например, семейную реликвию), они вам не нужны. Основная проблема в том, что их довольно сложно вкладывать , попробуйте:

 $ echo $(uname | $(echo cat)) Linux $ echo `uname | `echo cat`` bash: command substitution: line 2: syntax error: unexpected end of file echo cat 

На правой стороне командной строки, имеющей только присвоение, не обязательно (но безвредно) заключать в кавычки расширение, так как расширение в любом случае считается заключенным в кавычки:

 $ var=$(uname) 

Но это не всегда так, назначение при экспорте команды рассматривается как аргумент и будет разделено и выведено в некоторых shellх (не в bash):

 $ dash -c 'export MYVAR=`echo a test`;echo "$MYVAR"' a 

То же самое относится и к local ( нужны ли кавычки для присваивания локальной переменной? ) И к declare (и некоторым другим).

Что вы должны сделать, чтобы «исправить это», это:

 x=$(command -v r2g) 

И иногда (для переносимых скриптов):

 export x="$(command -v r2g)" 

Да, кавычки также должны быть указаны.

Это может быть вопросом предпочтительного стиля bash для случаев, когда вывод команды не содержит пробелов. Вот цитата автора утилиты shellharden из shellharden « Как безопасно делать вещи в bash »:

 Should I use backticks? Command substitutions also come in this form: Correct: "`cmd`" Bad: `cmd` While it is possible to use this style correctly, it looks even more awkward in quotes and is less readable when nested. The consensus around this one is pretty clear: Avoid. Shellharden rewrites these into the dollar-parenthesis form. 

Я также считаю, что было бы неплохо либо заключить кавычки в кавычки с помощью " , либо (лучше) переписать его, чтобы использовать $() . Если выходные данные команды содержат пробелы или специальные символы при использовании обратных кавычек, это может быть проблематично, если не заключать в кавычки выражение.

Да, мое предположение выглядит правильным, согласно этому документу: https://github.com/anordal/shellharden/blob/master/how_to_do_things_safely_in_bash.md

Это говорит:

 # Should I use backticks? # Command substitutions also come in this form: Correct: "`cmd`" Bad: `cmd`