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

Je sais que dans ~ / .bashrc, il ne faut pas mettre d'espaces autour des =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

J'examine le fichier de configuration MySQL /etc/my.cnfet j'ai trouvé ceci:

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

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

Notez que cette question n'est pas spécifique au /etc/my.cnffichier, mais plutôt aux fichiers de configuration * NIX en général. Ma première inclination est vers RTFM mais en fait man mysqlne fait aucune mention du problème et si j'ai besoin d'aller chasser en ligne pour chaque cas, je n'irai jamais nulle part. Existe-t-il une convention ou un moyen facile de vérifier? Comme on peut le voir, plusieurs personnes ont édité ce fichier (différentes conventions pour les =signes) et je ne peux ni les forcer à n'utiliser aucun espace, ni à fou de vérifier tout ce qui peut avoir été configuré et peut ou peut ne pas être correct.

EDIT: Mon intention est de m'assurer que les fichiers actuellement configurés sont correctement exécutés. Lors de la configuration des fichiers moi-même, je respecte la convention de tout ce que le responsable du package y met.

Je répondrai à cela d'une manière plus générale - en regardant un peu l'ensemble de " l'expérience d'apprentissage Unix ".

Dans votre exemple, vous utilisez deux outils et voyez que la langue est similaire. On ne sait pas exactement quand utiliser quoi exactement. Bien sûr, vous pouvez vous attendre à ce qu'il y ait une structure claire , alors vous nous demandez d'expliquer cela.
Le cas avec l'espace autour =est seulement et exemple - il y a beaucoup de cas similaires mais bot-tout à fait .
Il doit y avoir une logique, non?!

Les règles sur la façon d'écrire du code pour un outil , un shell, une base de données, etc. ne dépendent que de ce dont cet outil particulier a besoin .

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 lorsqu'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 - elle ne fait partie ni de la mise en œuvre , ni de la définition de la langue .

Une grande étape consiste à accepter que la cohérence que vous attendiez n'existe pas - ce qui est beaucoup plus facile lorsque vous comprenez les raisons - j'espère que la partie théorique vous y 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 rechercher les détails indépendamment . Assurez-vous de savoir où vous trouvez la documentation de référence pour chacun.

Du côté positif, il y a une certaine cohérence là où vous ne vous y attendiez pas: dans le contexte d'un seul outil (ou de différents outils utilisant le même langage), vous pouvez être assez sûr que la syntaxe est cohérente.
Dans votre mysqlexemple, cela signifie que vous pouvez supposer que toutes les lignes ont la même règle. La règle est donc "l'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 s'agir de " Liste des valeurs foo dans cmd-foo.conf, une par ligne".
Il peut s'agir d'un langage de script complet qui est également utilisé ailleurs. Ensuite, vous avez un outil puissant pour écrire la configuration - et dans certains cas, c'est juste bien, dans d'autres, vous en aurez vraiment besoin.
Des outils complexes ou de grandes familles d'outils connexes utilisent parfois simplement une syntaxe de fichier de configuration spéciale très complexe (certains exemples célèbres sont sendmailet vim).
D'autres utilisent un script générallangue comme base, et étendre cette langue pour répondre aux besoins spéciaux , parfois de manière complexe, comme la langue le permet. Ce serait un cas très spécifique d'une langue spécifique au domaine ( DSL ) .

Bash interprétera une ligne contenant du texte suivi d' =une affectation à une variable, mais il interprétera une ligne contenant du texte suivi d'un espace comme une commande avec un argument.

var=assignment contre command =argument

Les scripts Bash fonctionnent sur le principe que tout dans le script est comme si vous l'aviez tapé dans la ligne de commande.

Dans les fichiers de configuration qui ne sont pas interprétés par bash(ou un autre shell), il sera déterminé par l'analyseur utilisé pour lire le fichier de configuration. Certains analyseurs prendront des espaces, d'autres non. C'est à l'application dans ce cas. Personnellement, je choisis la convention utilisée par le fichier de configuration par défaut.

.bashrc n'est rien de plus qu'un fichier de configuration pour bash, tout comme my.cnf, php.ini, httpd.conf ou un launchd plist. Chacun a sa propre syntaxe, allant de l'affectation sans espace de bash à la soupe de balises XML de launchd (il existe également une version binaire: -O)

Il n'y a pas de conventions fermes, et que vous avez déjà découvert la directive Prime d'Unix: Lire les Beaux Manuel.

Certains programmes proposent une vérification du fichier de configuration, par exemple:

postfix check

Sinon, vous pourriez obtenir les fichiers de configuration d'origine des référentiels et les comparer avec diff au courant.

Les espaces autour du =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 =si vous voulez obtenir une affectation simple valide (pas d'extension, pas d'arithmétique, pas d'affectation de tableau) dans bash.

Pour le fichier de configuration, car chaque logiciel a son propre analyseur pour analyser son fichier de configuration, bashn'a aucune relation. Vous devez lire la documentation pour savoir quelle syntaxe est autorisée dans le fichier de configuration.

Un exemple est mysql, dans son script init /etc/init.d/mysqld, il a un analyseur 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