Quand les espaces autour du signe = sont-ils interdits?

Je sais que dans ~ / .bashrc on ne doit pas mettre d'espaces autour = signes en affectation:

 $ tail -n2 ~/.bashrc alias a="echo 'You hit a!'" alias b = "echo 'You hit b!'" $ a You hit a! $ b b: command not found 

Je passe en revue le file de configuration MySQL /etc/my.cnf et j'ai trouvé ceci:

 tmpdir=/mnt/ramdisk key_buffer_size = 1024M innodb_buffer_pool_size = 512M query_cache_size=16M 

Comment pourrais-je vérifier que les espaces autour des = signes ne sont pas un problème?

Notez que cette question n'est pas spécifique au file /etc/my.cnf , mais plutôt aux files de configuration * NIX en général. Ma première inclination est à RTFM mais en fait, l' man mysql ne fait aucune mention de la question et si je dois aller à la chasse en ligne pour chaque cas, je ne serai jamais nulle part. Y a-t-il une convention ou un moyen facile de vérifier? Comme on peut le constater, plusieurs personnes ont édité ce file (différentes conventions pour = signes) et je ne peux ni les forcer à utiliser des espaces, ni vérifier si tout est configuré et peut-être pas correct.

EDIT: Mon intention est de s'assurer que les files actuellement configurés sont correctement exécutés. Lors de la configuration des files moi-même, je vais avec la convention de tout ce que le mainteneur de package mettre là.

Je vais répondre de façon plus générale – en regardant un peu l'set de " l'expérience d'apprentissage Unix".

Dans votre exemple, vous utilisez deux outils et voyez que la langue est similaire. Il n'est pas clair quand utiliser exactement quoi. Bien sûr, vous pouvez vous attendre à une structure claire, alors vous nous requestz d'expliquer cela.
Le cas avec l'espace autour = est seulement et exemple – il y a beaucoup de cas similaires-mais-bot-assez .
Il doit y avoir une logique, pas vrai?

Les règles pour écrire du code pour un outil , un shell, une database, etc. ne dépendent que de ce que cet outil particulier nécessite .

Cela signifie que les outils sont complètement indépendants , techniquement. La relation logique que je pense que vous attendez n'existe tout simplement pas .

La similitude évidente des langues que vous voyez ne fait pas partie de la mise en œuvre du programme . La similitude existe parce que les développeurs ont convenu de la façon de le faire quand ils l'ont écrit pour un programme particulier. Mais les humains ne peuvent s'entendre que partiellement .

La relation que vous voyez est une chose culturelle – cela ne fait ni partie de la mise en œuvre ni dans la définition de la langue .


Alors, maintenant que nous avons manipulé la théorie, que faire en pratique?

Un grand pas est d' accepter que la cohérence que vous attendiez n'existe pas – ce qui est beaucoup plus facile quand vous comprenez les raisons – j'espère que la partie théorie vous aidera.

Si vous avez deux outils qui n'utilisent pas le même langage de configuration (par exemple les deux scripts bash), connaître les détails de la syntaxe de l'un n'aide pas beaucoup à comprendre l'autre;
Donc, en effet, vous devrez regarder les détails indépendamment . Assurez-vous de savoir où vous trouvez la documentation de reference pour chacun.

Du côté positif, il y a une certaine cohérence là où on ne l'attendait pas: dans le context d'un seul outil (ou d'outils différents utilisant le même langage), on peut être sûr que la syntaxe est cohérente.
Dans votre exemple mysql , cela signifie que vous pouvez supposer que toutes les lignes ont la même règle. Donc, la règle est "espace avant et après = n'est pas pertinent ".

Il y a de grandes différences dans la difficulté d'apprendre ou d'utiliser le langage de configuration ou de script d'un outil.
Il peut être un peu comme " Liste des valeurs foo dans cmd-foo.conf, un par ligne.".
Il peut s'agir d'un langage de script complet utilisé ailleurs. Ensuite, vous avez un outil puissant pour écrire la configuration – et dans certains cas, c'est juste agréable, dans d'autres, vous en aurez vraiment besoin.
Des outils complexes , ou de grandes familles d'outils associés utilisent parfois une syntaxe de file de configuration spéciale très complexe – (certains exemples célèbres sont sendmail et vim ).
D'autres utilisent un langage de script général comme base, et étendent ce langage pour prendre en charge les besoins spéciaux , parfois de manière complexe, comme le permet le langage. Ce serait un cas très spécifique d'un langage spécifique au domaine ( DSL ) .

Bash interprétera une ligne dont le text est suivi d'une = comme affectation à une variable, mais interprétera une ligne contenant du text suivi d'un espace comme une command avec un argument.

var=assignment vs command =argument

Bash scripts fonctionnent sur le principe que tout dans le script est comme si vous l'avez tapé dans la command line.

Dans les files de configuration qui ne sont pas interprétés par bash (ou un autre shell), cela sera déterminé par l'parsingur qui est utilisé pour lire le file de configuration. Certains parsingurs prendront des espaces, d'autres non. C'est à la request dans ce cas. Personnellement, je vais avec n'importe quelle convention le file de configuration par défaut a utilisé.

.bashrc n'est rien de plus qu'un file de configuration pour bash, tout comme my.cnf, php.ini, httpd.conf ou un pld de launchd. Chacun a sa propre syntaxe, allant de l'atsortingbution sans espace de bash à la souche de balises XML de launchd (il y a aussi une version binary: -O)

Il n'y a pas de conventions fermes, et vous avez déjà découvert la première directive d'Unix: Lisez le manuel fin.

Certains programmes offrent une vérification du file de configuration, par exemple:

 postfix check 

Sinon, vous pouvez récupérer les files de configuration d'origine à partir des référentiels et les comparer avec diff au courant.

Les espaces autour de = signe sont toujours problématiques lorsque vous effectuez une affectation dans bash . Il n'y a pas d'exception ici, vous devez supprimer tous les espaces autour de = si vous voulez get une assignation simple valide (pas d'expansion, pas d'arithmétique, pas d'assignation de tableau) dans bash .

Pour le file de configuration, car chaque logiciel a son propre parsingur pour parsingr son file de configuration, bash n'a pas de relation. Vous devez lire la documentation pour savoir quelle syntaxe est autorisée dans le file de configuration.

Par exemple, mysql , dans son script d'initialisation /etc/init.d/mysqld , possède un parsingur pour my.cnf :

 # Try to find basedir in /etc/my.cnf conf=/etc/my.cnf print_defaults= if test -r $conf then subpat='^[^=]*basedir[^=]*=\(.*\)$' dirs=`sed -e "/$subpat/!d" -e 's//\1/' $conf` for d in $dirs do d=`echo $d | sed -e 's/[ ]//g'` if test -x "$d/bin/my_print_defaults" then print_defaults="$d/bin/my_print_defaults" break fi if test -x "$d/bin/mysql_print_defaults" then print_defaults="$d/bin/mysql_print_defaults" break fi done fi 

Je dirais que lorsque vous utilisez une command bash qui signifie atsortingbuer une valeur à quelque chose, sign = signifie assigment et vous devez supprimer des espaces autour ou il va également atsortingbuer l'espace.

Alors que dans un file de configuration où = est de séparer une key d'une valeur, vous pouvez ou ne pas mettre un espace sans problème et cela n'aura pas de signification particulière.