Quand à envelopper des guillemets autour d'une variable d'environnement?

En bref, devis tout où vous n'avez pas besoin de la shell pour effectuer jeton de fractionnement et de l'expansion des caractères génériques.

Guillemets simples de protéger le texte entre textuellement. C'est le propre de l'outil lorsque vous devez vous assurer que le shell ne pas toucher la corde. Généralement, c'est le citant le mécanisme de choix lorsque vous n'avez pas besoin interpolation de 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.

Les guillemets sont adaptés lors de l'interpolation de variable est nécessaire. Avec les adaptations appropriées, il est également une bonne solution lorsque vous avez besoin des guillemets simples dans la chaîne. (Il n'y a pas de façon simple d'échapper à une seule citation entre guillemets simples, car il n'existe pas de mécanisme d'échappement à l'intérieur des guillemets simples-s'il y avait, ils ne seraient pas citer complètement verbatim.)

$ echo "There is no place like '$HOME'"
There is no place like '/home/me'

Pas de guillemets sont appropriées lorsque vous exiger le shell pour effectuer jeton de fractionnement et/ou à l'expansion des caractères génériques.

Jeton de fractionnement;

 $ words="foo bar baz"
 $ for word in $words; do
 >   echo "$word"
 > done
 foo
 bar
 baz

Par contraste:

 $ for word in "$words"; do echo "$word"; done
 foo bar baz

(La boucle ne s'exécute une fois, sur l'unique chaîne de caractères entre guillemets.)

 $ for word in '$words'; do echo "$word"; done
 $words

(La boucle ne s'exécute une fois, plus le littéral simple chaîne de caractères entre guillemets.)

Expansion des caractères génériques:

$ pattern='file*.txt'
$ ls $pattern
file1.txt      file_other.txt

Par contraste:

$ ls "$pattern"
ls: cannot access file*.txt: No such file or directory

(Il n'existe pas de fichier nommé littéralement file*.txt.)

$ ls '$pattern'
ls: cannot access $pattern: No such file or directory

(Il n'existe pas de fichier nommé $pattern!)

En termes plus concrets, tout ce qui contient un nom de fichier doit généralement être cité (parce que les noms de fichiers peuvent contenir d'espaces et d'autres shell métacaractères). Tout ce qui contient une URL doit généralement être cité (parce que de nombreuses adresses contiennent shell métacaractères comme ? et &). Tout ce qui contient une regex doit généralement être cité (idem idem idem idem). Tout ce qui contient d'importants espaces autres que les espaces entre les caractères espace doit être cité (parce que sinon, le shell va munge l'espace, de manière efficace, les espaces, et couper les espaces avant ni après).

Lorsque vous savez qu'une variable ne peut contenir qu'une valeur qui ne contient pas de shell métacaractères, citant est facultatif. Ainsi, un non-cotées $? est fondamentalement bien, parce que cette variable ne peut contenir qu'un seul numéro. Cependant, "$?" est également correct, et recommandé pour la cohérence générale et de l'exactitude (même si c'est ma recommandation personnelle, pas un fait largement reconnu de la politique).

Valeurs qui ne sont pas des variables essentiellement de suivre les mêmes règles, mais vous pouvez aussi échapper à toute caractères de remplacement au lieu de les citer. Pour un exemple, une URL avec un & dans il sera analysé par le shell comme un fond de commande, à moins que le caractère de remplacement est échappé ou cité:

$ wget http://example.com/q&uack
[1] wget http://example.com/q
-bash: uack: command not found

(Bien sûr, cela se produit également si l'URL est dans le non coté variable). Pour une chaîne statique, entre guillemets simples à faire le plus de sens, bien que toute forme de citations ou d'échapper fonctionne ici.

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

Le dernier exemple, suggère également un autre concept utile, ce que j'aime appeler "balançoire en citant". Si vous avez besoin de mélanger les guillemets simples et doubles, vous pouvez les utiliser adjacents les uns aux autres. Par exemple, la cité des chaînes

'$HOME '
"isn't"
' where `<3'
"' is."

peuvent être collées ensemble, dos à dos, formant une longue chaîne après la segmentation et devis de déménagement.

$ echo '$HOME '"isn't"' where `<3'"' is."
$HOME isn't where `<3' is.

Ce n'est pas très lisible, mais c'est une technique courante et donc bon à savoir.

Que d'un côté, les scripts ne devrait généralement pas utiliser ls pour n'importe quoi. Pour développer un générique, juste ... l'utiliser.

$ 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

(La boucle est complètement inutile dans le dernier exemple; printf spécifiquement fonctionne très bien avec plusieurs arguments. stat trop. Mais en boucle sur une wildcard match est un problème commun, et souvent fait de manière incorrecte.)

Une variable contenant une liste de jetons en boucle ou un générique pour élargir l'est moins fréquemment observée, de sorte que nous avons parfois l'abréviation de "citation tout, sauf si vous savez précisément ce que vous faites".

OriginalL'auteur tripleee

J'utilise généralement cité comme "$var" de sécurité, sauf si je suis sûr que $var ne contiennent pas d'espace.

Je ne l'utilisation de $var comme un moyen simple de rejoindre les lignes:

lines="`cat multi-lines-text-file.txt`"
echo "$lines"                             ## multiple lines
echo $lines                               ## all spaces (including newlines) are zapped

OriginalL'auteur Bach Lien