(1 respuesta)
Cerrado hace 4 años.
Tiendo a citar sustituciones de comandos como se muestra a continuación, incluso cuando asigno su salida a una variable:
var="$(command)"
¿Es eso realmente necesario? ¿Cuándo se rompe? La respuesta aceptada aquí afirma:
DIRNAME=”$(dirname $FILE)” no hará lo que usted desea si $FILE contiene espacios en blanco o caracteres globales [?*.
El enlace apunta a la excelente página de Gray Cat Wiki sobre citas, pero esa página no menciona específicamente las sustituciones de comandos de citas. Y al citar la variable es claramente necesario, citar la sustitución del comando en sí no parece serlo.
Sin embargo, la misma publicación concluye con:
DIRNAME=”$(dirname “$FILE”)” es la forma recomendada. Puede reemplazar DIRNAME=con un comando y un espacio sin cambiar nada más, y dirname recibe la cadena correcta.
Que es lo que siempre he pensado y a menudo he escrito publicaciones aquí que no lo citan. Sin embargo, la página wiki vinculada anteriormente también afirma que:
Hay algunos casos en los que se pueden omitir las comillas dobles de forma segura:
En el lado derecho de una tarea simple. Puede escribir foo=$bar sin comillas. Esto es compatible con POSIX.
[. . . ]
Mientras que var=$(command) no es realmente una tarea "simple", sin embargo, no pude encontrar un caso en el que las comillas fueran realmente necesarias:
$ var=$(echo "foo bar baz") ## whitespace works
$ echo "$var"
foo bar baz
$ var=$(printf "foonbar * baz") ## so do globbing characters
$ echo "$var"
foo
bar * baz
$ var1="foonbar * baz"
$ var=$(printf "$var1") ## printing a variable doesn't make any difference
$ echo "$var"
foo
bar * baz
$ var=$(printf '%sn' "$var1")
$ echo "$var"
foonbar * baz
$ var=$(printf -- '-e %sn' "$var1") ## strings starting with - also work
$ echo "$var"
-e foonbar * baz
Por supuesto, las comillas son absolutamente necesarias si la sustitución del comando se usa directamente para cosas como command1 "$(command2)" , pero ese no parece ser el caso cuando se asigna a una variable.
Entonces, ¿qué me estoy perdiendo? ¿Alguna vez se necesitan las cotizaciones? ¿Qué caso de esquina será citar una sustitución de comando al asignar su valor de retorno a una variable protegerte de? ¿O siempre está bien no citar una sustitución de comando si es el lado derecho de una operación de asignación de variable?
Respuesta aceptada:
Como referencia, el manual de Bash es claro en esto:
Se puede asignar una variable a una declaración de la forma
name=[value]
Si no se proporciona valor, a la variable se le asigna la cadena nula. Todos los valores experimentan expansión de tilde, expansión de parámetros y variables, sustitución de comandos, expansión aritmética y eliminación de comillas (detallado a continuación). […] No se realiza la división de palabras , con la excepción de "[correo electrónico protegido]", como se explica a continuación. La expansión del nombre de archivo no se realiza.
Sin división de palabras, sin expansión de nombre de archivo, por lo tanto, sin necesidad de comillas.
Relacionado:¿Herramienta de línea de comando psql de PostgreSQL y ESTABLECER RESTRICCIONES APLAZADAS?En cuanto a POSIX, sección 2.9.1 Comandos simples:
2. Se ampliarán las palabras que no sean asignaciones variables o redirecciones. Si quedan campos después de su expansión Si quedan campos después de su expansión, el primer campo se considerará el nombre del comando y los campos restantes serán los argumentos del comando.
[…]
4. Cada asignación de variable se expandirá para la expansión de tilde, expansión de parámetros, sustitución de comandos, expansión aritmética y eliminación de comillas antes de asignar el valor.
No estoy seguro de si se supone que eso debe interpretarse como que la división de campo ocurre solo para las expansiones realizadas en el paso 2. El paso 4 no menciona la división de campos, aunque la sección sobre división de campos tampoco menciona las asignaciones de variables como una excepción a la producción de múltiples campos.