Exportation d'une variable avec le point (.) Dans celui-ci

Au less pour bash la page man définit la syntaxe d'export comme:

 export [-fn] [name[=word]] ... 

Il définit également un "nom" comme:

  name A word consisting only of alphanumeric characters and under‐ scores, and beginning with an alphabetic character or an under‐ score. Also referred to as an identifier. 

Par conséquent, vous ne pouvez pas vraiment définir une variable comme my.home car il n'y a pas d'identifiant valide.

Je suis sûr que votre ksh a une définition très similaire d'un identifiant et ne permet donc pas ce genre de variables. (Jetez un oeil à sa page de man.)

Je suis également certain qu'il existe une sorte de standard général (POSIX?) Qui spécifie ce qui est autorisé en tant qu'identifiant (et donc nom de variable).

Si vous avez vraiment besoin de ce genre de variable pour une raison quelconque, vous pouvez utiliser quelque chose comme

 env "my.home=/tmp/someDir" bash 

pour le définir de toute façon. Mais là encore, vous ne pourrez pas y accéder en utilisant la syntaxe normale du shell. Dans ce cas, vous avez probablement besoin d'une autre langue comme perl:

 perl -e 'print $ENV{"my.home"}' 

Par exemple

 env "my.home=/tmp/someDir" perl -le 'print $ENV{"my.home"}' 

devrait imprimer votre path.

Les variables d'environnement peuvent avoir n'importe quel nom (y compris la string vide) ne contenant pas un signe égal ou un octet nul, les shells mappent les variables d'environnement aux variables shell et dans la plupart des shells, les noms de variables sont limités aux caractères alphanumériques ASCII et _ 't être un chiffre (à l'exception des parameters positionnels et d'autres parameters spéciaux tels que $* , $- , $@ , …, qui ne sont pas mappés aux variables d'environnement correspondantes). Notez également que certaines variables sont réservées / spéciales par / au shell.

Exceptions à cela:

• Le shell rc et ses dérivés comme es et akanga supportent n'importe quel nom sauf la string vide et ceux qui sont tous numériques ou contiennent des caractères (et exportent toujours toutes leurs variables vers l'environnement et prennent garde des variables spéciales comme * , status , pid …):

   ; '%$£"' = test ; echo $'%$£"' test ; '' = x zero-length variable name ; 

  Cependant, il utilise son propre encoding pour les variables dont le nom ne contient pas d'alnums ou pour les arrays lorsqu'ils sont passés dans l'environnement des commands en cours d'exécution:

   $ rc -c '+ = zzz; __ = zzz; a = (zzz xxx); env' | sed -n /zzz/l __2b=zzz$ __5f_=zzz$ a=zzz\001xxx$ $ env +=x rc -c "echo $'+'" x $ env __2b=x rc -c "echo $'+'" x 

• AT & T ksh , yash et zsh (également bash mais seulement pour les caractères à un seul octet) prennent en charge les alnums dans les parameters régionaux en cours, pas seulement les ASCII.

   $ Stéphane=1 $ echo "$Stéphane" 1 

  Dans ces shells, vous pouvez changer les parameters régionaux pour considérer la plupart des caractères comme alpha, mais cela ne fonctionnerait pas pour les caractères ASCII comme . . Vous pouvez tromper zsh ou ksh en pensant £ est une lettre, mais pas cela . ou tout autre caractère ASCII (où autoriser les caractères dans les noms de variables est concerné, pas pour le [[:alpha:]] glob par exemple).

• ksh93 a des variables spéciales dont le nom contient un point comme ${.sh.version} , mais celles-ci ne sont pas mappées aux variables d'environnement et sont spéciales. Le . est de s'assurer qu'il ne soit pas en conflit avec d'autres variables. S'il avait choisi de l'appeler $sh_version , il pourrait y avoir des scripts potentiellement brisés qui utilisaient déjà cette variable (voir par exemple comment zsh a des problèmes avec son $path ou $commands array spécial / hash variables (a la csh) scripts).

Notez que, en plus des shells ne supportant pas ces variables, certains shells comme pdksh / mksh les suppriment de l'environnement qu'ils reçoivent ( bash supprime celui qui a un nom vide, ash , ksh et bash supprime les strings d'environnement qui ne contiennent pas de = caractère):

 $ env %%%=test 1=%%% ab=%%% mksh -c env | grep %%% $ env %%%=test 1=%%% ab=%%% bash -c env | grep %%% %%%=test ab=%%% 1=%%% $ perl -le '$ENV{""}="%%%"; exec "bash", "-c", "env"' | grep %%% $ perl -le '$ENV{""}="%%%"; exec "zsh", "-c", "env"' | grep %%% =%%% $ echo 'main(){char*a[]={"sh","-c","env",0};char*e[]={"%%%",0}; execve("/bin/ash",a,e);}'|tcc -run - | grep %%% $ echo 'main(){char*a[]={"sh","-c","env",0};char*e[]={"%%%",0}; execve("/bin/zsh",a,e);}'|tcc -run - | grep %%% %%% 

En résumé, il vaut mieux s'en tenir aux noms de variables supportés par la plupart des shells et essayer d'utiliser des majuscules pour les variables d'environnement (et minuscules ou mixtes pour les variables shell non exscopes) en évitant celles qui sont spéciales dans les shells (comme IFS , PS1 , BASH_VERSION …).

Si vous avez besoin de définir une telle variable dans un shell qui ne les supporte pas, mais ne les élimine pas, vous pouvez soit vous réexécuter avec quelque chose comme:

 #! /bin/ksh - perl -e 'exit 1 unless defined($ENV{"ab"})' || exec env ab=%%% "$0" "$@" 

(évidemment, si vous avez besoin de le faire au milieu du script, cela ne vous aidera pas, mais vous pourriez alors jeter un oeil à cette approche pour sauvegarder et restaurer l'environnement d'exécution du shell sur un ré-exec). Ou essayez l'approche du débogueur:

 gdb --batch-silent -ex 'call putenv("ab=%%%")' --pid="$$" 

(celui-ci semble fonctionner avec zsh , yash , csh et tcsh sous Linux amd64, mais pas avec les autres shells que j'ai essayé ( mksh , ksh93 , bash , dash )).