¿Cuál es el beneficio de usar $ () en lugar de backticks en scripts de shell?

Hay dos formas de capturar la salida de la línea de comando en bash:

1. Backticks de shell Bourne heredados ``:

   var=`command`

2. $() sintaxis (que hasta donde yo sé es específica de Bash, o al menos no es compatible con shells antiguos que no son POSIX como Bourne original)

   var=$(command)

¿Hay algún beneficio al usar la segunda sintaxis en comparación con los backticks? ¿O son los dos totalmente 100% equivalentes?

La principal es la capacidad de anidarlos , comandos dentro de los comandos, sin perder la cordura tratando de descubrir si alguna forma de escapar funcionará en los backticks.

Un ejemplo, aunque algo artificial:

deps=$(find /dir -name $(ls -1tr 201112[0-9][0-9]*.txt | tail -1l) -print)

que le dará una lista de todos los archivos en el /dirárbol de directorios que tienen el mismo nombre que el archivo de texto con fecha más temprana de diciembre de 2011 ^(a) .

Otro ejemplo sería algo así como obtener el nombre (no la ruta completa) del directorio principal:

pax> cd /home/pax/xyzzy/plugh
pax> parent=$(basename $(dirname $PWD))
pax> echo $parent
xyzzy

^(a) Ahora que el comando específico puede no funcionar realmente, no he probado la funcionalidad. Por lo tanto, si me rechaza, ha perdido de vista la intención :-) Se entiende solo como una ilustración de cómo puede anidar, no como un fragmento listo para la producción libre de errores.

Suponga que desea encontrar el directorio lib correspondiente al lugar donde gccestá instalado. Tienes una opción:

libdir=$(dirname $(dirname $(which gcc)))/lib

libdir=`dirname \`dirname \\\`which gcc\\\`\``/lib

El primero es más fácil que el segundo: use el primero.

El backticks ( `...`) es la sintaxis heredada requerida solo por las capas de bourne más antiguas no compatibles con POSIX y $(...)es POSIX y más preferido por varias razones:

• Las barras invertidas ( \) dentro de los backticks se manejan de una manera no obvia:

  $ echo "`echo \\a`" "$(echo \\a)"
  a \a
  $ echo "`echo \\\\a`" "$(echo \\\\a)"
  \a \\a
  # Note that this is true for *single quotes* too!
  $ foo=`echo '\\'`; bar=$(echo '\\'); echo "foo is $foo, bar is $bar" 
  foo is \, bar is \\

• Las citas anidadas en el interior $()son mucho más convenientes:

  echo "x is $(sed ... <<<"$y")"

  en vez de:

  echo "x is `sed ... <<<\"$y\"`"

  o escribiendo algo como:

  IPs_inna_string=`awk "/\`cat /etc/myname\`/"'{print $1}' /etc/hosts`

  porque $()usa un contexto completamente nuevo para citar

  que no es portátil ya que los shells Bourne y Korn requerirían estas barras invertidas, mientras que Bash y dash no.

• La sintaxis para las sustituciones de comandos de anidación es más fácil:

  x=$(grep "$(dirname "$path")" file)

  que:

  x=`grep "\`dirname \"$path\"\`" file`

  porque $()impone un contexto completamente nuevo para las citas, por lo que cada sustitución de comandos está protegida y puede tratarse por sí sola sin especial preocupación por las citas y las escapadas. Al usar backticks, se vuelve más y más feo después de dos niveles o más.

  Pocos ejemplos más:

  echo `echo `ls``      # INCORRECT
  echo `echo \`ls\``    # CORRECT
  echo $(echo $(ls))    # CORRECT

• Resuelve un problema de comportamiento inconsistente cuando se utilizan comillas inversas:

  • echo '\$x' salidas \$x
  • echo `echo '\$x'` salidas $x
  • echo $(echo '\$x') salidas \$x

• La sintaxis de Backticks tiene restricciones históricas sobre el contenido del comando incrustado y no puede manejar algunos scripts válidos que incluyen comillas inversas, mientras que el $()formulario más nuevo puede procesar cualquier tipo de script incrustado válido.

  Por ejemplo, estos scripts incrustados válidos no funcionan en la columna izquierda, pero sí funcionan en el ^IEEE derecho :

  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 ')'
  `                              )

Por lo tanto, la sintaxis para la $sustitución de comandos prefijada debería ser el método preferido, ya que es visualmente clara con una sintaxis limpia (mejora la legibilidad humana y mecánica), es anidable e intuitiva, su análisis interno es independiente y también es más consistente (con todas las otras expansiones que se analizan entre comillas dobles) donde los backticks son la única excepción y el `carácter se camufla fácilmente cuando está adyacente para "hacerlo aún más difícil de leer, especialmente con fuentes pequeñas o inusuales.

Fuente: ¿Por qué se $(...)prefiere sobre `...`(backticks)? en BashFAQ

Ver también:

• Sección estándar POSIX "2.6.3 Sustitución de comandos"
• Justificación de POSIX para incluir la sintaxis $ ()
• Sustitución de comando
• bash-hackers: sustitución de comandos

De man bash:

          $(command)
   or
          `command`

   Bash performs the expansion by executing command and replacing the com-
   mand  substitution  with  the  standard output of the command, with any
   trailing newlines deleted.  Embedded newlines are not deleted, but they
   may  be  removed during word splitting.  The command substitution $(cat
   file) can be replaced by the equivalent but faster $(< file).

   When the old-style backquote form of substitution  is  used,  backslash
   retains  its  literal  meaning except when followed by $, `, or \.  The
   first backquote not preceded by a backslash terminates the command sub-
   stitution.   When using the $(command) form, all characters between the
   parentheses make up the command; none are treated specially.

Además de las otras respuestas,

$(...)

destaca visualmente mejor que

`...`

Los backticks se parecen demasiado a los apóstrofes; esto varía según la fuente que esté utilizando.

(Y, como acabo de notar, los backticks son mucho más difíciles de ingresar en ejemplos de código en línea).

$() permite anidar.

out=$(echo today is $(date))

Creo que los backticks no lo permiten.

Es el estándar POSIX que define la $(command)forma de sustitución de comandos. La mayoría de los shells en uso hoy en día cumplen con POSIX y admiten esta forma preferida sobre la notación arcaica de backtick. La sección de sustitución de comandos (2.6.3) del documento Shell Language describe esto:

La sustitución de comandos permite sustituir la salida de un comando en lugar del nombre del comando en sí. La sustitución del comando ocurrirá cuando el comando esté encerrado de la siguiente manera:

$(command)

o (versión con comillas):

`command`

El shell expandirá la sustitución del comando ejecutando el comando en un entorno de subshell (consulte Entorno de ejecución de Shell ) y reemplazando la sustitución del comando (el texto del comando más el "$ ()" o comillas anexas) con la salida estándar del comando, eliminando secuencias de uno o más <newline>caracteres al final de la sustitución. Los <newline>caracteres incrustados antes del final de la salida no se eliminarán; sin embargo, pueden tratarse como delimitadores de campo y eliminarse durante la división de campo, según el valor de IFS y las cotizaciones vigentes. Si la salida contiene bytes nulos, el comportamiento no se especifica.

Dentro del estilo de sustitución de comando entre comillas, <backslash>retendrá su significado literal, excepto cuando sea seguido por: ' $', ' `' o <backslash>. La búsqueda de la cita inversa coincidente deberá ser satisfecha por la primera cita inversa no escapada sin comillas; durante esta búsqueda, si se encuentra una comilla inversa no escapada dentro de un comentario de shell, un documento aquí, una sustitución de comando incrustada del formulario $ ( comando ) o una cadena entre comillas, se producen resultados indefinidos. Una cadena entre comillas simples o dobles que comienza, pero no termina, dentro de "`...` secuencia " produce resultados indefinidos.

Con el formulario $ ( comando ), todos los caracteres que siguen el paréntesis abierto al paréntesis de cierre coincidente constituyen el comando . Se puede usar cualquier script de shell válido para el comando , excepto un script que consista únicamente en redirecciones que produzcan resultados no especificados.

Los resultados de la sustitución de comandos no se procesarán para una mayor expansión de tilde, expansión de parámetros, sustitución de comandos o expansión aritmética. Si se produce una sustitución de comando entre comillas dobles, la división del campo y la expansión del nombre de ruta no se realizarán en los resultados de la sustitución.

La sustitución de comandos puede estar anidada. Para especificar el anidamiento dentro de la versión con comillas invertidas, la aplicación precederá las comillas internas con <backslash>caracteres; por ejemplo:

\`command\`

La sintaxis del lenguaje de comandos de shell tiene una ambigüedad para las expansiones que comienzan con "$((", que puede introducir una expansión aritmética o una sustitución de comando que comienza con un subshell. La expansión aritmética tiene prioridad; es decir, el shell primero determinará si puede analizar la expansión como una expansión aritmética y solo analizará la expansión como un comando sustitución si determina que no puede analizar la expansión como una expansión aritmética. El shell no necesita evaluar expansiones anidadas al realizar esta determinación. Si encuentra el final de la entrada sin haber determinado ya que no puede analizar la expansión como una expansión aritmética, el Shell tratará la expansión como una expansión aritmética incompleta e informará un error de sintaxis. Una aplicación conforme se asegurará de que separa el " $(" y '('en dos tokens (es decir, sepárelos con un espacio en blanco) en una sustitución de comando que comienza con una subshell. Por ejemplo, una sustitución de comando que contiene una única subshell podría escribirse como:

$( (command) )

Esta es una pregunta heredada, pero se me ocurrió un ejemplo perfectamente válido de $(...)más `...`.

Estaba usando un escritorio remoto para Windows ejecutando cygwin y quería iterar sobre el resultado de un comando. Lamentablemente, el carácter de backtick fue imposible de ingresar, ya sea por el escritorio remoto o por el propio cygwin.

Es sensato suponer que un signo de dólar y paréntesis serán más fáciles de escribir en configuraciones tan extrañas.