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


9

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.


2
Il n'existe pas de "fichiers de configuration * NIX en général". Si je veux autoriser des espaces dans mon fichier de configuration, j'écrirai mon programme pour les autoriser. Si je veux que mon fichier de configuration utilise des deux-points ou des tuyaux au lieu de signes égaux, j'écrirai mon programme pour les utiliser. Bash ne nécessite aucun espace. Mysql leur permet.
hymie

Réponses:


3

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 .



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

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 ) .


Acceptée car c'est la réponse qui répond le plus à la question du point de vue de la question. Merci!
dotancohen

20

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.


Merci. Je m'inquiète de savoir comment vérifier les fichiers existants, maintenant et à l'avenir, qui peuvent avoir été configurés par d'autres types de devops en herbe. Lors de la configuration des fichiers moi-même, je respecte la convention de tout ce que le responsable du package y met, comme vous le suggérez. J'ai édité la question pour clarifier.
dotancohen

1
Je suppose que si vous vérifiez les fichiers existants, je vérifierai la documentation du produit et l'utiliserai comme exemple. En supposant que vous avez de la documentation et que ce n'est pas une application personnalisée. S'il s'agissait d'une application personnalisée, je m'en tiendrai à tout ce qui existe déjà. "Si ce n'est pas cassé, ne le répare pas"
Lawrence

Malheureusement, certains d'entre eux sont fauchés. Voilà pourquoi je demande!
dotancohen

Dans les coquilles, n'utilisez jamais d'espaces autour d'un égal. Dans tout ce qui n'est pas un shell, utilisez toujours des espaces. Vous pouvez auditer des fichiers existants en utilisant grep: 'grep "[^] = [^]" / etc / *' pour trouver des fichiers avec un = qui n'a pas d'espace.
qris

2
@dotancohen (1.) Pour tout fichier de configuration, il devrait y avoir au moins un paramètre qu'il serait assez facile de vérifier s'il est cassé. Qu'un fichier de configuration autorise ou non des espaces, il doit le faire de manière cohérente tout au long. (2.) Vous pouvez toujours télécharger une application et vérifier les configurations par défaut avec lesquelles elle est livrée. (3.) Vous pouvez toujours laisser de côté des espaces. a = bpeut ne pas toujours être acceptable mais a=bdevrait toujours fonctionner.
Two-Bit Alchemist

4

.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.


1
.bashrcn'est pas un fichier de configuration pour bash. .bashrcest un script shell qui bash s'exécute à chaque démarrage d'un processus bash. Il peut être utilisé pour configurer bash mais il peut aussi être utilisé pour faire toutes sortes d'autres choses: c'est un script, pas un fichier de configuration.
Josh

3

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.


En fait, cela semble vraiment résoudre le problème principal. Merci!
dotancohen

2

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

Il y a une exception dans (( var = 12 ))ou var=( value )ou $((var = 12))ou${var[foo = 12]}
Stéphane Chazelas

@ StéphaneChazelas: Je n'ai pas parlé de ces cas dans cette question, ajoutez des informations. Merci.
cuonglm
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.