Où est-ce que "export var = valeur" n'est pas disponible?

J'ai repris – probablement sur Usenet au milieu des années 1990 (!) – que la construction

export var=value 

est un bachisme, 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 mis au défi, et je ne peux vraiment pas find de documentation pour sauvegarder ce qui était une croyance solide à moi.

Googler pour "export: command not found" ne semble pas apporter de cas où quelqu'un a effectivement eu ce problème, donc même si c'est vrai, je suppose que ce n'est pas très commun.

(Les hits que je reçois semblent être des débutants qui copynt / collent des signes de ponctuation et qui se terminent par 'export: command not found ou quelque chose de ce genre, ou essayant d'utiliser export avec sudo ).

Je peux certainement dire que cela fonctionne sur OS X, et sur diverses dissortingbutions Linux, y compris celles où sh est 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 export var=value est sûr à utiliser?

J'aimerais comprendre quelles sont les conséquences. Si ce n'est pas portable à v7 "Bourne classic", ce n'est guère plus que des anecdotes. 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.

     export foo=bar 

    n'est pas supporté par le shell Bourne. Cela a été introduit par ksh .

    Dans le Bourne shell, vous feriez:

     foo=bar export foo 

    ou:

     foo=bar; export foo 

    ou avec set -k :

     export foo foo=bar 

    Maintenant, le comportement de:

     export foo=bar 

    varie d'une coquille à l'autre.

    Le problème est que les affectations et les arguments de command simples sont analysés et interprétés différemment.

    La foo=bar ci-dessus est interprétée par certains shells comme un argument de command et par d'autres comme une assignation (parfois).

    Par exemple,

     a='bc' export d=$a 

    est interprété comme:

     'export' 'd=b' 'c' 

    avec quelques coquilles ( ash , zsh (en émulation sh), yash ) et:

     'export' 'd=bc' 

    dans les autres ( bash , ksh ).

    Tandis que

     export \d=$a 

    ou

     var=d export $var=$a 

    serait interprétée de la même manière dans tous les shells (comme 'export' 'd=b' 'c' ) car cette barre oblique inverse ou ce signe dollar arrête les shells qui le supportent pour considérer ces arguments comme des assignations.

    Si l' export lui-même est cité ou le résultat d'une certaine expansion (même partielle), selon le shell, il cesserait également de recevoir le traitement spécial.

    La syntaxe de Bourne cependant:

     d=$a export d 

    est interprété de la même façon par tous les obus sans ambiguïté.

    Cela peut être bien pire que cela. Voir par exemple cette discussion récente sur bash quand les arrays sont impliqués.

    (OMI, c'était une erreur d'introduire cette fonctionnalité ).

    Ce n'est pas un bashisme mais une syntaxe compatible POSIX. Il a effectivement commencé comme un kshism il y a longtime et a été plus tard adopté par presque tous les obus basés sur la syntaxe de Bourne. La seule exception notoire est /bin/sh sur Solaris 10 et plus, qui rest fidèle à la syntaxe du shell Bourne héritée. Espérons que Solaris 11 utilise un shell compatible POSIX comme /bin/sh .

    Par ailleurs, l' export était déjà une command embeddede dans le shell Bourne hérité, donc googler pour l' export: command not found était trompeuse.

    Voici le comportement du shell Bourne hérité lorsque l' export est associée à une affectation:

     $ export var=22 var=22: is not an identifier 

    Pour les nostalgiques, le code source de ce shell Bourne original est disponible et peut être compilé pour la plupart des dissortingbutions Unix et Linux.