How to fix "not a valid identifier" error after setting environment variables?

Question

I'm trying to setup cocos2dx in Ubuntu 14.04 LTS but after setting the environmental variables (in .bashrc) I start getting this error:

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

And I don't know what to do to fix it.

Solution 1

but after setting the environmental variables

It looks like you did not do that correctly.

The errors you're getting mean that the paths (like /home/john/android) are being used as the names of variables, rather than as the values assigned to them.

• The correct syntax to assign a variable is NAME=value.
• The correct syntax to export a variable (with whatever value, if any, it has already been assigned) is export NAME.
• The correct syntax to assign and export a variable (with the assigned value) at the same time is export NAME=value.

I suspect you are attempting to do the third thing but using wrong syntax. Five common mistakes that could produce errors like what you're seeing are:

1. Using spaces instead of =. export NAME value is incorrect; value is then interpreted as the name of a subsequent variable to export.

   (This happens because export NAME1 NAME2 is correct syntax for exporting multiple variables.)

2. Putting spaces around =. In many programming languages, it's both valid and stylistically preferred to pad operators with spaces most of the time. But to assign a value to a variable in a shell script (or other situation where you are issuing shell commands), this is not allowed. NAME = value (in an export command or otherwise) won't work; you must use NAME=value.

   (export NAME = value tries to export variables named NAME, =, and value. Fortunately this never appears to succeed silently because attempting to export a variable called = is a syntax error. In contrast export NAME= value will appear to work, but does not assign value to NAME--instead, it assigns the empty, zero-length string to NAME and exports it, and separately exports the variable value. Both are common mistakes.)

3. Separating parts of the variable's value with spaces. Environment variables can contain spaces, but in practice they are rarely used as field separators in environment variables. When a single variable intentionally contains multiple paths, usually : is used to separate them.

4. Not quoting spaces when assigning to variables. Sometimes an environment variable's value is supposed to contain a space. For example, it might be the name of a directory that really contains a space. In that case, it's necessary to quote any spaces.

   One way to do this is to precede them with \. See How can I protect parentheses passed to a cd command? and Unable to delete file for information on other ways--the methods presented in the answers apply, even though neither question is specifically about assigning to environment variables.

   For example, here are a few ways to export the environment variable SILLYPATH with the value /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"
   

   Often when a folder that you must use in a shell or assign to a widely used environment variable contains a space, it might benefit from being renamed. (But sometimes that's impractical or undesirable.)

5. Assigning and/or exporting a variable when nothing had to be done at all. This is sort of a meta-mistake; the specific technical problem is often one of the above, but the solution is to get rid of the offending line, or some part of it, rather than fix it. Don't indiscriminately remove code from .bashrc, of course. But an export may have been accidentally added, or may inadvertently have more code in it than was intended. For example, suppose you meant to write:

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

   That would append to .bashrc, then re-source it. But suppose you instead wrote:

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

   Then your export command would not just export an augmented value of PATH, but would also attempt to export variables named . and /home/your-username/.bashrc, which is not what you want. Since they contain characters that are prohibited in variable names, so you would get an error every time you start a new interactive bash shell.

   To avoid this problem, I suggest editing .bashrc in an editor (e.g., nano ~/.bashrc, gedit ~/.bashrc) rather than redirecting output to the end of it with >>.

_{I suspect this may be enough information for you to find and fix the bug in your .bashrc file. If you need further help, you should of course post the full contents of that file for analysis. (It is only by coincidence that your problem happened to be one sufficiently frequently encountered, and with a sufficiently transparent error message, to make a general answer like this one possible.)}

Solution 2

Make sure that you're running:

export ENV_VARIABLE

Rather than:

export $ENV_VARIABLE

Otherwise, you are trying to export the value of the variable rather than the variable itself, so you will get this error.

Solution 3

Eliminate spaces and the dollar sign. For instance this works just the same way you could set a django settings module on a web server via SSH ie:

export DJANGO_SETTINGS_MODULE=myapp.settings

Comments

[fiatux]

You'll have to show exactly how you're setting the variables.

[Rengas]

Thank you! Such an detailed answer. In my case putting space around = was the issue. I was struggling with this for a while.