I am using the tcsh terminal in Linux. In the other terminal I normally used I set the path to some license file as follows:
export PATH="$PATH:$MODEL_TECH"
Tcsh shell does not recognise this command so I tried the following:
setenv PATH "$PATH:$MODEL_TECH"
set PATH "$PATH:$MODEL_TECH"
setenv PATH=("$PATH:$MODEL_TECH")
But then I always get the following error:
Bad : modifier in $ ($).
What be also great if someone could help me here out quickly, tried quite a few combinations but nothing works.
Drop the =
setenv LICENSE_FILE "/usr/local/softwarex/license.dat"
From the man page for tcsh:
setenv [name [value]]
Without arguments, prints the names and values of all environ‐
ment variables. Given name, sets the environment variable name
to value or, without value, to the null string.
Put curly braces around the variable names:
setenv PATH ${PATH}:${foo}
or use this form:
set path = ($path $foo)
Try setenv LICENSE_FILE /usr/local/softwarex/license.dat. This should be documented in the man page somewhere on your system, so try reading up in man tcsh; tcsh is a very different beast from bash and friends. If the relevant man page isn't available on your system for some reason, here's the first man tcsh I found.
On a tcsh shell the path or any environment variable can be appended as below:
setenv PATH $PATH":$NEWPATH"
If it's not working use this:
setenv PATH ${PATH}:/.../../../
Related
I'm writing a script in csh (it needs to be in csh)
and I've really been struggling on what seems like a trivial problem.
I want to set an environment variable with string containing a numeric variable. However I want to increment the value being stored without affecting the value. Is this possible. I've spent quite a while digging through csh tutorials and I'm at a loss.
Below is the last iteration of what I have tried. Nothing seems to work.
set LOG_HIST = 8
setenv LOG_FILE "/foo/log/foo."${LOG_FILE}".log"
setenv NEXT_LOG_FILE "/foo/log/foo."(${LOG_FILE} + 1)".log"
You can use the backticks to get the output of a command and use expr to evaluate an arithmetical expression:
% set LOG_HIST = 8
% setenv LOG_FILE "/foo/log/foo."${LOG_HIST}".log"
% setenv NEXT_LOG_FILE "/foo/log/foo."`expr ${LOG_HIST} + 1`.log
% echo $NEXT_LOG_FILE
/foo/log/foo.9.log
I am to trying cross-compile pile Qt from a Linux terminal. When I run qmake it applies the mkspecs qmake.conf in my context in such manner that the CROSS_COMPILE variable must be defined. For example, there is a critical conf line that looks like this:
QMAKE_CXX = $${CROSS_COMPILE}g++
Qmake returns an error though which clearly indicates $${CROSS_COMPILE} is not being resolved. It is simply using "g++" instead of the whole value which ought to be there.
I've tried to invoke qmake and define the variable from a bash script like this:
qmake qt.pro "CROSS_COMPILE=${CROSS_COMPILE}"
And like this :
qmake qt.pro -- "CROSS_COMPILE=${CROSS_COMPILE}"
And a few other such stabs at it. I've also tried hard coding the value in that command in case that had anything to do with it. I've tried defining this as an environmental variable too (just in case)...
Nothing works. Yet, I've seen piles of examples where this syntax seems to be valid. What am doing wrong? Could there be a character escape complication?
Your problem is that the shell already interpreted the ${} inside your string as a form of variable substitution.
Since you did not define the variable CROSS_COMPILE in the shell, it had no value and what qmake got were actually the 2 arguments between quotes "qt.pro" and "CROSS_COMPILE=", meaning that you have actually made qmake set CROSS_COMPILE to an empty value.
What you should try is:
qmake qt.pro "CROSS_COMPILE=\${CROSS_COMPILE}"
Note the backslash before the dollar sign, which escapes it to prevent it from having a special meaning to the shell and enables it to get passed on literally to qmake.
This question has also been already asked on Stackoverflow:
Define a string in qmake command line
More on the variable substitution of Bash:
https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html
EDIT:
Example:
I just tried myself with a fresh project file with the following contents:
SOME_OTHER_VAR=$${SOME_VAR}_something
message($${SOME_OTHER_VAR})
and doing
SOME_VAR=value
qmake qmake_variables.pro "SOME_VAR=${SOME_VAR}"
does work for me, printing:
Project MESSAGE: value_something
This is not the best answer, but I "solved" the problem by adding this to my qmake.conf:
CROSS_COMPILE=$$(CROSS_COMPILE)
That defined the variable in qmake by getting it from an environmental variable I set in my calling bash script.
While installing UIMA I got this steps in readme file
* Set JAVA_HOME to the directory of your JRE installation you would like to use for UIMA.
* Set UIMA_HOME to the apache-uima directory of your unpacked Apache UIMA distribution
* Append UIMA_HOME/bin to your PATH
* Please run the script UIMA_HOME/bin/adjustExamplePaths.bat (or .sh), to update
paths in the examples based on the actual UIMA_HOME directory path.
This script runs a Java program;
you must either have java in your PATH or set the environment variable JAVA_HOME to a
suitable JRE.
I opened /etc/environment and perfomed this changes:
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/UIMA_HOME/bin"
JAVA_HOME="/usr/lib/jvm/java-7-openjdk-i386"
UIMA_HOME="/root/Desktop/karim/software/UIMA/UIMA_SDK_1.4.5"
after that executed:
UIMA/UIMA_SDK_1.4.5/bin# ./documentAnalyzer.sh
which gave this error:
./documentAnalyzer.sh: 2: .: Can't open /bin/setUimaClassPath.sh
documentAnalyzer.sh code :
#!/bin/sh
. "$UIMA_HOME/bin/setUimaClassPath.sh"
if [ "$JAVA_HOME" = "" ];
then
JAVA_HOME=$UIMA_HOME/java/jre
fi
"$JAVA_HOME/bin/java" -cp "$UIMA_CLASSPATH" -Xms128M -Xmx900M "-Duima.home=$UIMA_HOME" "-Duima.datapath=$UIMA_DATAPATH" -DVNS_HOST=$VNS_HOST -DVNS_PORT=$VNS_PORT "-Djava.util.logging.config.file=$UIMA_HOME/Logger.properties" com.ibm.uima.reference_impl.application.docanalyzer.DocumentAnalyzer
What is the mistake here? I guess I set environment variable correctly
I think the answers given about adding the $ to the variable UIMA_HOME in your PATH variable are correct, but, I think you are also lacking the EXPORT command for your variables.
Look, after you set their values, you should also writhe this in /etc/environment:
export UIMA_HOME
export JAVA_HOME
export PATH
That way, you would be able to use them later (always remember to fix the PATH variable with the $UIMA_HOME as well).
If this does not work, try rebooting your computer after setting the variables as I said.
In the case that does not work either, try repeating the process and in a console (after doing everythin all over again) try using the following command:
source /etc/environment
Fianlly, if that does not work, try setting the variables in the file called /etc/profile (do the same process: setting the varialbes and exporting them), and this should work.
The order of variable assignments in your /etc/environment is wrong; in order to use $UIMA_HOME in the PATH=..., you have to define UIMA_HOME afore, e. g.
UIMA_HOME="/root/Desktop/karim/software/UIMA/UIMA_SDK_1.4.5"
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:$UIMA_HOME/bin"
JAVA_HOME="/usr/lib/jvm/java-7-openjdk-i386"
I need to set an environment variable called "64bit" (i.e. with a leading digit) in bash. However, bash variable names disallow a variable with a leading digit. I know a way to set it when invoking bash:
env 64bit=1 /usr/bin/bash
However, I'm looking for a way to change it in the currently running shell i.e. not by starting a new shell. I also know that csh allows variables to start with a digit, but I need to use bash.
Is there any way to achieve this?
You can also bypass the bash interpreter and define the variable directly with the bash internal functions:
$ gdb --batch-silent -ex "attach $$" \
-ex 'set bind_variable("64bit", "1", 0)' \
-ex 'set *(int*)(find_variable("64bit")+sizeof(char*)*5) = 1' \
-ex 'set array_needs_making = 1'
$ env | grep 64
64bit=1
As people point out, Bash does not allow variables starting with digits. It does however pass on unrecognized environment string to external programs, which is why the variable shows up in env but not in set.
As a workaround, you can work with a valid name like _64bit and then automatically inject your invalid variable name into commands you run:
#!/bin/bash
# Setup for injection hack
original=$PATH
PATH="/"
command_not_found_handle() {
PATH="$original" env "64bit=$_64bit" "$#"
}
# Your script and logic
_64bit="some dynamic value"
# This verifies that '64bit' is automatically set
env | grep ^64bit
Note that this particular method only works if you invoke through $PATH, not if you use relative or absolute path names.
If you do invoke by pathname, consider modifying PATH and invoking by name instead.
I have an app which runs and reads a text configuration file.
This points to several locations of configurations / outputs etc.
Is it possible to use environmental variables inside the text configuration file, rather than hardcoded paths?
LogFilePath=$LOG_FILE_PATH
vs
LogFilePath=/home/user/logs
When running, the application fails as it cannot expand the Environment Variable.
It will be sourced inside the shell before the application is run.
Thanks!
Recently I used this in a (bash) script:
#!/bin/bash
# ...
source config.file
# ...
Where config.file had lines like this:
export ORIG_PATH="${PATH:-.}:/bla/bla"
export SOMESETTING="${SOMEVAR:-"somedefault"},somedata"
...
So the ${parameter:-word} thing worked well for me: use default values, if parameter is unset or null, the expansion of word is substituted. Otherwise, the value of parameter is substituted. (From man bash.)
HTH