обратные тики против двойных кавычек
В Fedora 20 он находится в этом пакете :
$ repoquery -ql kde-runtime-0:4.13.3-3.fc20.x86_64 | grep kdesu
/usr/bin/kdesu
/usr/libexec/kde4/kdesu
/usr/libexec/kde4/kdesud
Я выяснил это, запросив YUM-репозитории в моей системе, ища пакет, содержащий файл * / bin / kdesu .
$ repoquery -qf */bin/kdesu
kde-runtime-0:4.13.3-3.fc20.x86_64
kde-runtime-0:4.11.3-2.fc20.i686
kde-runtime-0:4.13.3-3.fc20.i686
kde-runtime-0:4.11.3-2.fc20.x86_64
Все примеры относятся к присвоению переменных из подстановки команд, поэтому они эквивалентны. Согласно ответу Жиля , цитирование не требуется справа от присвоения переменной, поскольку там не происходит разделения слов. Так что все четыре в порядке.
Если бы они были автономными, т. е. не в назначении, вам нужно было бы цитировать. Преимущество формы $(...)по сравнению с обратными кавычками заключается в том, что кавычки могут быть вложены и разбиты на несколько строк, поэтому в настоящее время эта форма обычно предпочтительнее. Другими словами, вы можете выполнить "$( echo "$var" )"с этой формой, чтобы защитить как внутреннее расширение $var, так и внешнее расширение $(...)от разбиения на слова и подстановки имен файлов.
Как показано в спецификациях командного языка оболочки POSIX , встроенные многострочные скрипты не работают с обратными кавычками (слева ), но работают с формой $()(слева. справа ).
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 ')'
` )
Sí, también se deben citar los acentos graves.
Esto puede ser una cuestión de estilo bash preferido para los casos en que la salida del comando no contiene espacios. Aquí hay una cita del autor de la utilidad shellharden, de " cómo hacer las cosas de forma segura en 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.
También creo que es una buena forma citar acentos graves con ", o (mejor )reescribirlo para usar $(). Si la salida del comando contiene espacios o caracteres especiales al usar acentos graves, puede ser problemático si no se cita la expresión.
Sí, mi suposición parece correcta, según este documento :https://github.com/anordal/shellharden/blob/master/how_to_do_things_safely_in_bash.md
Dice:
# Should I use backticks?
# Command substitutions also come in this form:
Correct: "`cmd`"
Bad: `cmd`
Los cuatro ejemplos son funcionalmente equivalentes.
Los acentos graves están obsoletos y, a menos que esté usando un shell de 1970 como un Bourne shell (como Heirloom ), no los necesita. El principal problema es que son bastante difíciles de anidar , prueba:
$ echo $(uname | $(echo cat))
Linux
$ echo `uname | `echo cat``
bash: command substitution: line 2: syntax error: unexpected end of file
echo cat
En el lado derecho de una línea de comando con solo una asignación, no es necesario (sino inofensivo )citar la expansión, ya que la expansión se considera citada de todos modos:
$ var=$(uname)
Pero eso no siempre es cierto, una asignación en el comando export se considera un argumento y se dividirá y se glob en algunos shells (no en bash):
$ dash -c 'export MYVAR=`echo a test`;echo "$MYVAR"'
a
El mismo razonamiento se aplica alocal(¿Se necesitan comillas para la asignación de variables locales?)ydeclare(y algunos otros ).
Lo que debes hacer para "arreglarlo", es:
x=$(command -v r2g)
Y a veces (para scripts portátiles):
export x="$(command -v r2g)"