Saltar al contenido

¿Se han desaprobado las comillas invertidas (es decir, `cmd`) en los shells * sh?

David, miembro de este gran equipo, nos ha hecho el favor de redactar esta reseña ya que controla a la perfección este tema.

Solución:

Hay dos significados diferentes de “obsoleto”.

estar en desuso: (principalmente de una función de software) sea utilizable pero se considere obsoleto y es mejor evitarlo, generalmente debido a que ha sido reemplazado.

—New Oxford American Dictionary

Por esta definición, comillas invertidas están obsoleto.

Estado obsoleto también puede indican que la función se eliminará en el futuro.

—Wikipedia

Según esta definición, las comillas invertidas son no obsoleto.

Aún soportado:

Citando la Especificación de grupo abierto en los lenguajes de comandos de Shell, específicamente la sección “2.6.3 Sustitución de comandos”, se puede ver que ambas formas de sustitución de comandos, comillas invertidas (`..cmd..`) o parens en dólares ($(..cmd..)) todavía se admiten en la medida en que avanza la especificación.

extracto

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 se producirá cuando el comando se adjunte de la siguiente manera:

          $(command)

          or (backquoted version):

          `command`

El shell expandirá la sustitución del comando ejecutando el comando en un entorno de subnivel (ver Entorno de ejecución del shell) y reemplazando la sustitución del comando (el texto del comando más el adjunto $() o comillas inversas) con la salida estándar del comando, eliminando secuencias de uno o más caracteres al final de la sustitución. Incorporado los caracteres anteriores al final de la salida no se eliminarán; sin embargo, pueden tratarse como delimitadores de campo y eliminarse durante la división de campos, según el valor de IFS y las citas que estén en vigor. Si la salida contiene alguna null bytes, el comportamiento no está especificado.

Dentro del estilo de sustitución de comandos entre comillas, conservará su significado literal, excepto cuando esté seguido de: ‘$’, ‘`‘, o . La búsqueda de la cita inversa coincidente se satisfará con la primera cita inversa sin comillas no escapada; durante esta búsqueda, si se encuentra una comilla inversa sin escape dentro de un comentario de shell, un documento aquí, una sustitución de comando incrustado del $(command) formulario, o una cita string, se producen resultados indefinidos. Una cotización simple o una cotización doble string que comienza, pero no termina, dentro del “`...`“La secuencia produce resultados indefinidos.

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

Entonces, ¿por qué todo el mundo dice que las comillas inversas han quedado obsoletas?

Porque la mayoría de los casos de uso deberían utilice la forma parens del dólar en lugar de las comillas invertidas. (En desuso en el primer sentido anterior). Muchos de los sitios de mayor reputación (incluido U&L) a menudo también afirman esto, por lo que es un buen consejo. Este consejo no debe confundirse con algún plan inexistente para eliminar la compatibilidad con las comillas invertidas de los shells.

  • BashFAQ # 082 – ¿Por qué se prefiere $ (…) sobre `…` (comillas invertidas)?

    extracto

    `...` es la sintaxis heredada requerida solo por los bourne-shells más antiguos no compatibles con POSIX. Hay varias razones para preferir siempre el $(...) sintaxis:

  • Wiki de Bash Hackers – Sintaxis obsoleta y obsoleta

    extracto

    Esta es la forma más antigua de sustitución de comandos compatible con Bourne. Ambos `COMMANDS` y $(COMMANDS) POSIX especifica las sintaxis, pero la última es muy preferido, aunque el primero, lamentablemente, sigue siendo muy frecuente en los scripts. Las sustituciones de comandos de nuevo estilo se implementan ampliamente en todos los shell modernos (y más). La única razón para usar comillas inversas es la compatibilidad con un shell Bourne real (como Heirloom). Las sustituciones de comandos de comillas invertidas requieren un escape especial cuando están anidadas, y los ejemplos que se encuentran en la naturaleza se citan incorrectamente la mayoría de las veces. Consulte: ¿Por qué se prefiere $ (…) sobre `…` (comillas invertidas) ?.

  • Justificación del estándar POSIX

    extracto

    Debido a estos comportamientos inconsistentes, la variedad de sustitución de comandos entre comillas inversas no se recomienda para aplicaciones nuevas que anidan sustituciones de comandos o intentan incrustar scripts complejos.

NOTA: Este tercer extracto (arriba) continúa mostrando varias situaciones en las que las comillas invertidas simplemente no funcionan, pero el método más nuevo de dólar parens sí, comenzando con el siguiente párrafo:

Además, la sintaxis entre comillas tiene restricciones históricas sobre el contenido del comando incrustado. Mientras que el formulario “$ ()” más nuevo puede procesar cualquier tipo de script incrustado válido, el formulario entre comillas inversas no puede manejar algunos scripts válidos que incluyen comillas inversas.

Si continúa leyendo esa sección, las fallas se resaltan mostrando cómo fallarían usando comillas invertidas, pero funcionan usando la notación parens en dólares más nueva.

Conclusiones

Por lo tanto, es preferible que use parens en dólares en lugar de comillas invertidas, pero en realidad no está usando algo que técnicamente ha sido “desaprobado” como en “esto dejará de funcionar por completo en algún punto planeado”.

Después de leer todo esto, debería tener la conclusión de que se le recomienda encarecidamente que use los panales de dólar a menos que específicamente requieren compatibilidad con un shell Bourne original real que no sea POSIX.

No está en desuso, pero las comillas inversas (`...`) es la sintaxis heredada requerida solo por los más antiguos de los bourne-shells no compatibles con POSIX y $(...) es POSIX y más preferido por varias razones:

  • Barras invertidas () las comillas inversas internas 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 \
    
  • Cotización anidada dentro $() es mucho más conveniente:

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

    en lugar de:

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

    o escribiendo algo como:

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

    porque $() utiliza 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 lo hacen.

  • La sintaxis para anidar sustituciones de comandos 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 comando está protegida y puede tratarse por sí sola sin una preocupación especial por las citas y el escape. Cuando se usan comillas invertidas, se vuelve cada vez más feo después de dos niveles o más.

    Algunos ejemplos más:

    echo `echo `ls``      # INCORRECT
    echo `echo `ls``    # CORRECT
    echo $(echo $(ls))    # CORRECT
    
  • Resuelve un problema de comportamiento inconsistente al usar comillas inversas:

    • echo '$x' salidas $x
    • echo `echo '$x'` salidas $x
    • echo $(echo '$x') salidas $x
  • La sintaxis de las comillas inversas 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 más nuevo $() El formulario puede procesar cualquier tipo de script incrustado válido.

    Por ejemplo, estos scripts incrustados válidos no funcionan en la columna de la izquierda, pero funcionan en la derecha.IEEE:

    echo `                         echo $(
    cat <

Por lo tanto, la sintaxis para $-la sustitución de comandos con prefijo debe ser el método preferido, porque es visualmente claro con sintaxis limpia (mejora la legibilidad humana y de la máquina), es encajable e intuitivo, su análisis interno es separado y también es más consistente (con todas las otras expansiones que se analizan desde comillas dobles) donde las comillas inversas son la única excepción y ` El personaje se camufla fácilmente cuando está adyacente a " lo que dificulta aún más la lectura, especialmente con fuentes pequeñas o inusuales.

Fuente: Why is $(...) preferido sobre `...` (comillas invertidas)? 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

Reseñas y puntuaciones del post

Puedes ayudar nuestro ensayo fijando un comentario y valorándolo te lo agradecemos.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *