En resumen, cita todo lo que no requieras que el shell realice la división de tokens y la expansión de comodines.
Las comillas simples protegen el texto entre ellas literalmente. Es la herramienta adecuada cuando necesita asegurarse de que el shell no toque la cadena en absoluto. Por lo general, es el mecanismo de cotización elegido cuando no se requiere interpolación variable.
$ echo 'Nothing \t in here $will change'
Nothing \t in here $will change
$ grep -F '@&$*!!' file /dev/null
file:I can't get this @&$*!! quoting right.
Las comillas dobles son adecuadas cuando se requiere interpolación variable. Con adaptaciones adecuadas, también es una buena solución cuando necesita comillas simples en la cadena. (No hay una forma directa de escapar de una cita simple entre comillas simples, porque no hay un mecanismo de escape dentro de las comillas simples; si existiera, no citarían completamente al pie de la letra).
$ echo "There is no place like '$HOME'"
There is no place like '/home/me'
No hay comillas adecuadas cuando se requiere específicamente que el shell realice una división de tokens y / o expansión de comodines.
División de tokens;
$ words="foo bar baz"
$ for word in $words; do
> echo "$word"
> done
foo
bar
baz
Por el contrario:
$ for word in "$words"; do echo "$word"; done
foo bar baz
(El bucle solo se ejecuta una vez, sobre la cadena única entre comillas).
$ for word in '$words'; do echo "$word"; done
$words
(El ciclo solo se ejecuta una vez, sobre la cadena literal entre comillas simples).
Expansión comodín:
$ pattern='file*.txt'
$ ls $pattern
file1.txt file_other.txt
Por el contrario:
$ ls "$pattern"
ls: cannot access file*.txt: No such file or directory
(No hay ningún archivo llamado literalmente file*.txt).
$ ls '$pattern'
ls: cannot access $pattern: No such file or directory
(¡No hay ningún archivo llamado $patterntampoco!)
En términos más concretos, cualquier cosa que contenga un nombre de archivo debe ser citado (porque los nombres de archivo pueden contener espacios en blanco y otros metacaracteres de shell). Cualquier cosa que contenga una URL generalmente debe citarse (porque muchas URL contienen metacaracteres de shell como ?y &). Cualquier cosa que contenga una expresión regular generalmente debe citarse (ídem ídem). Cualquier cosa que contenga espacios en blanco significativos que no sean espacios individuales entre caracteres que no sean espacios en blanco debe ser citado (porque de lo contrario, el shell combinará el espacio en blanco, efectivamente, en espacios individuales y recortará cualquier espacio en blanco inicial o final).
Cuando sabe que una variable solo puede contener un valor que no contiene metacaracteres de shell, las comillas son opcionales. Por lo tanto, un sin comillas $?está básicamente bien, porque esta variable solo puede contener un solo número. Sin embargo, "$?"también es correcto y se recomienda por su consistencia y corrección general (aunque esta es mi recomendación personal, no es una política ampliamente reconocida).
Los valores que no son variables básicamente siguen las mismas reglas, aunque también podría escapar a los metacaracteres en lugar de citarlos. Para un ejemplo común, &el shell analizará una URL con una entrada como un comando de fondo a menos que se escape o se cite el metacarácter:
$ wget http://example.com/q&uack
[1] wget http://example.com/q
-bash: uack: command not found
(Por supuesto, esto también sucede si la URL está en una variable sin comillas). Para una cadena estática, las comillas simples tienen más sentido, aunque cualquier forma de cita o escape funciona aquí.
wget 'http://example.com/q&uack' # Single quotes preferred for a static string
wget "http://example.com/q&uack" # Double quotes work here, too (no $ or ` in the value)
wget http://example.com/q\&uack # Backslash escape
wget http://example.com/q'&'uack # Only the metacharacter really needs quoting
El último ejemplo también sugiere otro concepto útil, que me gusta llamar "cotización de balancín". Si necesita mezclar comillas simples y dobles, puede usarlas adyacentes entre sí. Por ejemplo, las siguientes cadenas citadas
'$HOME '
"isn't"
' where `<3'
"' is."
se pueden pegar juntas, formando una sola cadena larga después de la tokenización y eliminación de comillas.
$ echo '$HOME '"isn't"' where `<3'"' is."
$HOME isn't where `<3' is.
Esto no es muy legible, pero es una técnica común y, por lo tanto, es bueno saberlo.
Por otro lado, los scripts generalmente no deberían usarse lspara nada. Para expandir un comodín, solo ... úsalo.
$ printf '%s\n' $pattern # not ``ls -1 $pattern''
file1.txt
file_other.txt
$ for file in $pattern; do # definitely, definitely not ``for file in $(ls $pattern)''
> printf 'Found file: %s\n' "$file"
> done
Found file: file1.txt
Found file: file_other.txt
(El bucle es completamente superfluo en el último ejemplo; printfespecíficamente también funciona bien con múltiples argumentos stat. Pero recorrer un comodín es un problema común, y con frecuencia se hace incorrectamente).
Una variable que contiene una lista de tokens para recorrer o un comodín para expandir se ve con menos frecuencia, por lo que a veces abreviamos "citar todo a menos que sepa exactamente lo que está haciendo".