Presque partout où j'ai lu, y compris Guide de style de script Bash de Google mentionné à la nécessité de cibler des substitutions de commande (sauf si elle est spécifiquement souhaitée bien sûr).
Je comprends le quand / où / pourquoi / pourquoi de cibler des substitutions de commande pendant une utilisation générale. Par exemple: Cependant, pour des missions variables spécifiquement, j'ai vu tant d'exemples que tels:
Pourtant, j'ai trouvé aucune instance sur laquelle Quelqu'un peut-il donner des situations où laissant la substitution non notée lors de l'assidation variable entraînerait un problème? écho "$ (CAT <<<" * String inutile * ")" plutôt que echo $ (...)
variable = "$ (commande)"
variable = $ (commande) n'est pas équivalent.
variable = "$ (echo" * ")" et variable = $ (écho "*") définit la valeur sur '*'.
3 Réponses :
La coque ne fonctionne pas scission de mot em> pour des affectations variables (il est normalisé de cette façon par POSIX et vous pouvez compter sur elle). Ainsi, vous n'avez pas besoin de guillemets (mais vous pouvez les utiliser sans faire le résultat différent) dans Cependant, la scission de mot est effectuée avant d'exécuter des commandes, donc dans P> case "$FOO" in
(frob) ...;;
esac
C'est ce que cette réponse dit.
Pouvez-vous donner un lien vers la partie exacte de la norme POSIX où cela est nécessaire? J'ai du mal à le trouver.
@LUCAS J'interpréteriez 2.9.1 Commandes simples, n ° 4 dans pubs. opengroup.org/onlinepubs/9699919799/utieux/... : "Chaque affectation de variable doit être étendue à l'expansion de Tilde, à l'expansion des paramètres, à la substitution de commande, à l'expansion arithmétique et à la suppression de la citation avant d'attribuer la valeur." / I> Cela ne dit pas la division de mots ici.
Dans BASH , une expansion de paramètres utilisé comme argument à l'opérateur d'ici-string n'est également pas soumise à la fractionnement de mots ou à la génération de pathernes, bien que les corrections de bugs ne prenaient pas une réalité jusqu'à la réalité de la récente 4.4.
Test avec tant de commandes différentes, c'est la même chose. Impossible de trouver une différence.
Ce n'est pas une réponse à la question. Et pour voir une différence, essayez echo $ (ECHO -E "Hello \ nworld") contre écho "$ (ECHO -E" HELLO \ NWORLD ")"
Lorsque vous utilisez BASH, ces deux lignes sont 100% équivalentes: tandis que ces deux ne sont pas: hélas, Le cerveau humain n'est pas un ordinateur. C'est particulièrement non aussi fiable quand il s'agit de répéter un travail. Il est donc de même que si vous mélangez des styles (c'est-à-dire que vous citez lorsque vous utilisez des arguments de commande, mais que vous ne citez pas lorsque vous attribuez une variable), En une fois de temps en temps, vous aurez le problème. pire, une fois de temps en temps, vous voudrez que le résultat de la commande soit étendu à des mots individuels. Et le prochain gars qui lit votre code se demandera s'il regarde un bug. Conculsion: Comme les deux premières lignes sont identiques, il est plus facile du cerveau moyen de toujours citer $ () (même quand ce n'est pas nécessaire) pour vous assurer de toujours citer quand vous devez.
OK, cela a du sens alors pourquoi il est recommandé si souvent ... Quand j'ai commencé à écrire des scripts Shell, j'ai pris en compte en règle générale. Maintenant que je suis beaucoup plus familier avec cela, j'essaie juste d'éliminer quoi que ce soit redondant ou inutile.
Bonne question! J'ai fait de nombreux tests et on dirait qu'ils sont exactement les mêmes, pas de différence.
Je pense que la question qu'il demande peut survenir avec $ cmd, $ {cmd}. En substitution et dans les clauses si, nous avons besoin de "" là-bas. S'il vous plaît corriger si je me trompe