I want to set an environment variable that has space in it. it is a path to a folder and the folder name is:
/Applications/Android Studio.app/Contents/gradle/gradle-2.10
I edit .bash_profile and add the following line to it:
export GRADLE_HOME=/Applications/Android Studio.app/Contents/gradle/gradle-2.10
and I get the result
-bash: export: `Studio.app/Contents/gradle/gradle-2.10': not a valid identifier
what should I do?
You can do it either this
export GRADLE_HOME=/Applications/Android\ Studio.app/Contents/gradle/gradle-2.10
way or this
export GRADLE_HOME="/Applications/Android Studio.app/Contents/gradle/gradle-2.10"
Important
Having taken so much pain in exporting the variable correctly, always make sure that you double quote the variable when you reference it in shell ie do:
"$GRADLE_HOME"
and not
$GRADLE_HOME
Example :
ls $GRADLE_HOME
will produce unexpected results.
Related
I have environment variable export MY_WORK_DIR="~/project".
While I'm using below command, it give me an error:
realpath $MY_WORK_DIR
realpath: '~/project': No such file or directory
In my guess, the ~ is not processed while using this env variable.
BTW, export MY_WORK_DIR=~/project is not an option for me. ~ should be in the string.
Could you please guide me how to get real path from envrionment variable ~/project ?
EDIT
Sorry. The variable is from other app so I cannot modify the environment variable which contains tilde. (Storing variable with tilde expanded form is not an option).
EDIT2
Is it safe to use eval command like this? eval "echo ${MY_WORK_DIR}". It works for my use.
I wouldn't use eval if I can avoid it. Especially in the way you are doing it, this is an invitation to do havoc by embedding dangerous code into MY_WORK_DIR.
A cheap solution for your concrete example would be to do a
if [[ ${MY_WORK_DIR:0:1} == '~' ]]
then
MY_WORK_DIR="$HOME/${MY_WORK_DIR:1}"
fi
which chops off the annoying ~ and prepends your home directory. But this would fail if MY_WORK_DIR is set to, say, ~einstein/project.
In this case, you would have to extract the user name (einstein) and search the home directory for this user.
Following steps can provide a resolution:
You need to replace "~" with the full path of the project directory.
Use pwd command to identify the full path of the project directory; e.g. /root/Documents/project is the full path you get.
Execute this command export MY_WORK_PROJECT=/root/Documents/project
Execute this command echo $MY_WORK_PROJECT so you should get this result
/root/Documents/project
I can successfully run the following command in the shell.
export ANT_HOME=/users/user1/workspace/apache-ant-1.7.0
But when I am adding the same line in a shell script, I am getting the following error.
`/users/user1/workspace/apache-ant-1.7.0': not a valid identifier
The shell interpreter is taking -1.7.0 in the path as a arithmetic operation.
How can I fix this ?
EDIT : the shell script which I am trying to run is here.
#!/bin/sh
settingsForANT()
{
export ANT_HOME=/users/user1/workspace/apache-ant-1.7.0
export PATH=${PATH}:${ANT_HOME}/bin
echo $ANT_HOME
echo $PATH
}
settingsForANT
Most likely you either have a $ before the ANT_HOME or a space after the =, probably the latter.
It's complaining about your path being an invalid identifier, meaning it's on the left hand of an assignment, not the right.
If that turns out to be not the case, check the shell you're running the script as. Some do not allow combined set/export and you may need:
ANT_HOME=whatever; export ANT_HOME
I'm trying to get emacs to become a global name so I can reference it anywhere on my filesystem. This is what I did on the command line:
$PATH = C:/emacs/bin:$PATH
But when I do that I get the following error:
sh.exe": /c/home/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/Program: No such file or directory
I even went directly to Start Menu->System [Properties]->Environment Variables and I tried to add C:\emacs\bin to the list of the paths but the name still came up as emacs: command not found. I don't know what I'm doing wrong.
Note that this is only a problem within C:\cygwin. Outside of that directory I can type emacs without a problem.
Your command
$PATH = C:/emacs/bin:$PATH
has several problems:
$ evaluates the variable, you need to set it
spaces are significant, you do not need them
you cannot use : inside a Cygwin path
Use this instead:
PATH=/c/emacs/bin:$PATH
I want to put my ~/Library/Application Support/ directory to a variable in my ~/.bash_profile` to make it easier to reference from within Terminal. I first attempted to define it as follows:
export L=~/Library/Application\ Support
However, when I tried to source ~/.bash_profile and then called ls $L, I got an error: /Users/username/Library/Application: Not a directory.
However, no matter how I define it I cannot define it properly, as far as I came up with the way to define it. Here's the list that I tried, but none of them worked properly.
~/Library/Application Support
"~/Library/Application Support"
"~/Library/Application\ Support"
So is it feasible to store a string which includes a whitespace to a variable in bash to begin with?
Your export statement is fine; the space is properly escaped. You just need to quote the expansion of the parameter, so that bash gives a single argument to the ls command:
ls "$L"
I've been trying to figure out what is the purpose of brackets in the bash environment variables. For example, in the below actual example of code, why are some of the definitions using a {} around the PATH, for example, export ...=.../${PATH}. Note also that some of the definitions are different: some use {$ECLIPSE_DIR} with the $ within the brackets; some use ${PATH} with the $ outside of the brackets, and some omit brackets altogether. This code generally works, although sometimes errors like the one shown at the bottom are shown (they appear to be transient), and I'm not sure why such errors only show up sometimes and not others.
What are the common practices concerning ways to include bash environment variables, when should brackets be used, and what is the difference between putting the $ inside and outside of brackets? Also, why do some lines have an "export" before the variable name, and some do not? What is the difference here?
# ECLIPSE
ECLIPSE_DIR=$HOME/eclipse
PATH=${PATH}:{$ECLIPSE_DIR}
# ANT
ANT_HOME=/usr/bin/ant
PATH=${ANT_HOME}/bin:${PATH}
export ANT_HOME PATH
# GRADLE
export GRADLE_HOME=/usr/local/gradle
export PATH=$GRADLE_HOME/bin:$PATH</code>
-bash: export: `/usr/bin/ant/bin:/usr/local/bin:{/Users/me/eclipse}:/usr/bin/scala-2.9.0.1/bin:/usr/local/mysql/bin:/usr/local/bin:{/Users/me/eclipse}': not a valid identifier
The braces are usually used for clarity, but a practical use is breaking up text from variable names. Say I had the following:
$ word="ello"
$ echo "h$word"
hello
$ echo "y$wordw" # bash tries to find the var wordw, and replaces with a blank
y
$ echo "y${word}w"
yellow
Variable names are automatically separated by most punctuation (notably . or /).
echo "$word/$word.$word"
ello/ello.ello
Looking at that error you presented, {$ECLIPSE_DIR} gets the variable expanded and then surrounded with literal open and close braces. I think the solution should be changing it to ${ECLIPSE_DIR}
In response to the export question, export is used to make a variable accessible to the shell that called this script. Any variable set up in a script does not exist once the script is finished unless it is exported. Hence, if you want your PATH to change after running that script, export PATH will have to be called before the script is over.
Braces are used with bash variables to disambiguate between variables. For example, consider this:
VAR=this
echo $VAR_and_that
echo ${VAR}_and_that
The first echo prints nothing, since bash thinks you are trying to echo out the var this_and_that which of course doesn't exist. The second echo doesn't have this problem and outputs this_and_that, since bash knows to expand out the VAR variable due to the braces.