J'ai compris - probablement sur Usenet au milieu des années 1990 (!) - que la construction
export var=value
est un bashisme, et que l'expression portable est
var=value
export var
Je préconise cela depuis des années, mais récemment, quelqu'un m'a contesté à ce sujet, et je ne trouve vraiment aucune documentation pour sauvegarder ce qui était une croyance solide.
La recherche sur Google "export: command not found"
ne semble pas évoquer de cas où quelqu'un a réellement eu ce problème, donc même si c'est authentique, je suppose que ce n'est pas très courant.
(Les hits que je reçois semblent être des débutants qui copient / collent la ponctuation, et se sont retrouvés avec 'export: command not found
ou quelque chose comme ça , ou qui essaient d'utiliser export
avec sudo
; et les csh
utilisateurs débutants essayant d'utiliser la syntaxe du shell Bourne.)
Je peux certainement dire que cela fonctionne sur OS X et sur diverses distributions Linux, y compris celles où il se sh
trouve dash
.
sh$ export var=value
sh$ echo "$var"
value
sh$ sh -c 'echo "$var"' # see that it really is exported
value
Dans le monde d'aujourd'hui, est-il sûr de dire que son utilisation export var=value
est sûre?
J'aimerais comprendre quelles en sont les conséquences. Si ce n'est pas portable pour la v7 "Bourne classic", ce n'est guère plus qu'une anecdote. S'il existe des systèmes de production où le shell ne peut vraiment pas faire face à cette syntaxe, ce serait utile de le savoir.
la source
busybox
vient pas avec sa propre coquille minimale? (Je ne suis pas en mesure d'essayer non plus cette seconde.)Réponses:
n'était pas supporté par le shell Bourne (un ancien shell des années 70 dont
sh
dérivent des implémentations modernes comme ash / bash / ksh / yash / zsh). Cela a été présenté parksh
.Dans le shell Bourne, vous feriez:
ou:
ou avec
set -k
:Maintenant, le comportement de:
varie d'une coquille à l'autre.
Le problème est que les affectations et les arguments de commande simples sont analysés et interprétés différemment.
Ce qui
foo=bar
précède est interprété par certains shells comme un argument de commande et par d'autres comme une affectation (parfois).Par exemple,
est interprété comme:
avec certains shells (
ash
, anciennes versions dezsh
(en émulation sh),yash
) et:dans les autres (
bash
,ksh
).Tandis que
ou
serait interprété de la même manière dans tous les shells (as
'export' 'd=b' 'c'
) car cette barre oblique inversée ou ce signe dollar empêche les shells qui le prennent en charge de considérer ces arguments comme des affectations.Si
export
elle-même est citée ou résulte d'une certaine expansion (même partielle), selon la coque, elle cesserait également de bénéficier du traitement spécial.Voir "Des citations sont-elles nécessaires pour l'affectation des variables locales? " Pour plus de détails à ce sujet.
La syntaxe Bourne cependant:
est interprété de la même manière par tous les shells sans ambiguïté (
d=$a export d
fonctionnerait également dans le shell Bourne et les shells compatibles POSIX mais pas dans les versions récentes dezsh
sauf ensh
émulation).Cela peut devenir bien pire que cela. Voir par exemple cette récente discussion sur le
bash
moment où les tableaux sont impliqués.(OMI, c'était une erreur d'introduire cette fonctionnalité ).
la source
foo=bar export foo
, comme je l'avais toujours vu là-bas. Je sais que l'exportation est une fonction intégrée, mais pourquoifoo=bar; foo=baz export foo; echo $foo
se comporte-t-elle différemmentfoo=bar; foo=baz /bin/cat /dev/null; echo $foo
?export
sont.declare
, nonexport
, je recommande à quiconque se soucie de la sécurité de lire la discussion sur le lien que StéphaneChazelas a fourni à bash.bugs .d=$a export d
est interprété de la même manière par tous les obus sans ambiguïté ;-)d=$a export d
ne fonctionne pluszsh
, j'ai donc mis à jour la réponse. Voir modifier.Ce n'est pas un bashisme mais une syntaxe compatible POSIX. Il a en fait commencé comme kshism il y a assez longtemps et a ensuite été adopté par presque tous les shells basés sur la syntaxe Bourne. La seule exception notoire
/bin/sh
concerne Solaris 10 et les versions antérieures, qui restent fidèles à la syntaxe héritée du shell Bourne. Espérons que Solaris 11 utilise un shell compatible POSIX en tant que/bin/sh
.Soit dit en passant,
export
était déjà une commande intégrée dans le shell Bourne hérité, donc googlerexport: command not found
était trompeur.Voici le comportement hérité du shell Bourne lorsqu'il
export
est combiné avec une affectation:Pour les nostalgiques, le code source de ce shell Bourne
originalest disponible et peut être compilé pour la plupart des distributions Unix et Linux.la source