Comment corriger l'erreur «pas un identifiant valide» après avoir défini des variables d'environnement?

J'essaie de configurer cocos2dx dans Ubuntu 14.04 LTS mais après avoir défini les variables d'environnement (en .bashrc), je commence à obtenir cette erreur:

bash: export: dev/cocos2d-x-3.2/tools/cocos2d-console/bin': not a valid identifier 
bash: export:/home/john/android': not a valid identifier 
bash: export: dev/android-ndk-r10b': not a valid identifier 
bash: export:dev/adt-bundle-linux-x86_64-20140702/sdk': not a valid identifier

Et je ne sais pas quoi faire pour y remédier.

mais après avoir défini les variables environnementales

Il semble que vous n'ayez pas fait cela correctement.

Les erreurs que vous obtenez signifient que les chemins (comme /home/john/android) sont utilisés comme noms de variables, plutôt que comme valeurs qui leur sont attribuées.

• La syntaxe correcte pour affecter une variable est NAME=value.
• La syntaxe correcte pour exporter une variable (avec n'importe quelle valeur, le cas échéant, elle a déjà été affectée) est export NAME.
• La syntaxe correcte pour affecter et exporter une variable (avec la valeur affectée) en même temps est export NAME=value.

Je soupçonne que vous essayez de faire la troisième chose mais en utilisant une mauvaise syntaxe. Cinq erreurs courantes qui pourraient produire des erreurs comme ce que vous voyez sont:

1. Utiliser des espaces au lieu de =. export NAME valueest incorrect; valueest alors interprété comme le nom d'une variable suivante à exporter.

   (Cela se produit car la syntaxe export NAME1 NAME2 est correcte pour exporter plusieurs variables.)

2. Mettre des espaces autour =. Dans de nombreux langages de programmation, il est à la fois valide et stylistiquement préféré de garnir les opérateurs avec des espaces la plupart du temps. Mais pour attribuer une valeur à une variable dans un script shell (ou dans toute autre situation où vous émettez des commandes shell), cela n'est pas autorisé. NAME = value(dans une exportcommande ou autre) ne fonctionnera pas; vous devez utiliser NAME=value.

   ( export NAME = valueEssais à des variables d'exportation nommées NAME, =et value. Heureusement , ce ne semble réussir en silence parce que la tentative d'exporter une variable appelée =est une erreur de syntaxe. En revanche export NAME= valuesemble fonctionner, mais ne attribue valueà NAME--instead, il affecte le vide, chaîne de longueur nulle NAMEet l'exporte, et exporte séparément la variable value. Les deux sont des erreurs courantes.)

3. Séparer les parties de la valeur de la variable par des espaces. Les variables d'environnement peuvent contenir des espaces, mais en pratique, elles sont rarement utilisées comme séparateurs de champs dans les variables d'environnement. Lorsqu'une seule variable contient intentionnellement plusieurs chemins, elle :est généralement utilisée pour les séparer.

4. Ne pas citer d'espaces lors de l'affectation à des variables. Parfois, la valeur d'une variable d'environnement est censée contenir un espace. Par exemple, il peut s'agir du nom d'un répertoire qui contient réellement un espace. Dans ce cas, il est nécessaire de citer tous les espaces.

   Une façon de le faire est de les précéder de \. Voir Comment puis-je protéger les parenthèses transmises à une commande cd? et Impossible de supprimer le fichier pour obtenir des informations sur d'autres manières - les méthodes présentées dans les réponses s'appliquent, même si aucune des questions ne concerne spécifiquement l'affectation aux variables d'environnement.

   Par exemple, voici quelques façons d'exporter la variable d'environnement SILLYPATHavec la valeur /home/ek/silly name/bin:

   export SILLYPATH=/home/ek/silly\ name/bin

   export SILLYPATH='/home/ek/silly name/bin'

   export SILLYPATH="/home/ek/silly name/bin"

   Souvent, lorsqu'un dossier que vous devez utiliser dans un shell ou affecter à une variable d'environnement largement utilisée contient un espace, il peut être avantageux de le renommer. (Mais parfois, c'est peu pratique ou indésirable.)

5. Assigner et / ou exporter une variable alors que rien ne devait être fait. C'est une sorte de méta-erreur; le problème technique spécifique est souvent l'un des problèmes ci-dessus, mais la solution est de se débarrasser de la ligne incriminée, ou d'une partie de celle-ci, plutôt que de la réparer. .bashrcBien sûr, ne supprimez pas aveuglément le code de . Mais un exportpeut avoir été ajouté accidentellement, ou peut contenir par inadvertance plus de code que prévu. Par exemple, supposons que vous vouliez écrire:

   echo 'export PATH=~/some.bin:"$PATH"' >>~/.bashrc; . ~/.bashrc

   Cela s'ajouterait .bashrc, puis le ressourcerait. Mais supposez que vous ayez plutôt écrit:

   echo 'export PATH=~/some.bin:"$PATH" . ~/.bashrc' >>~/.bashrc  # WRONG!

   Ensuite, votre exportcommande n'exporterait pas seulement une valeur augmentée de PATH, mais tenterait également d'exporter les variables nommées .et , ce qui n'est pas ce que vous voulez. Comme ils contiennent des caractères interdits dans les noms de variables, vous obtiendrez donc une erreur à chaque démarrage d'un nouveau shell bash interactif./home/your-username/.bashrc

   Pour éviter ce problème, je suggère de modifier .bashrcdans un éditeur (par exemple nano ~/.bashrc, gedit ~/.bashrc) plutôt que de rediriger la sortie à la fin avec >>.

_{Je soupçonne que cela peut être assez d'informations pour trouver et corriger le bogue dans votre .bashrcfichier. Si vous avez besoin d'aide, vous devez bien sûr publier l'intégralité du contenu de ce fichier pour analyse. (Ce n'est que par coïncidence que votre problème s'est avéré être un problème suffisamment fréquemment rencontré et avec un message d'erreur suffisamment transparent pour rendre possible une réponse générale comme celle-ci.)}

Assurez-vous que vous exécutez:

export ENV_VARIABLE

Plutôt que:

export $ENV_VARIABLE

Sinon, vous essayez d'exporter la valeur de la variable plutôt que la variable elle-même, vous obtiendrez donc cette erreur.

Éliminez les espaces et le signe dollar. Par exemple, cela fonctionne de la même manière que vous pouvez définir un module de paramètres django sur un serveur Web via SSH, c'est-à-dire:

export DJANGO_SETTINGS_MODULE=myapp.settings

J'ai vu celui-ci se produire assez fréquemment lorsque vous copiez quelque chose avec des virgules inversées (à partir du Web) et mettez à jour vos environnements ou votre fichier bashrc.

Un bon point de départ serait de taper manuellement les virgules inversées dans le contenu collé.