As seen in the comments your Library is located at /usr/lib/oracle/12.1/client/lib/, but your path just includes /usr/lib/oracle/12.1/client/bin... you see why it can't find the library?
You can expand your LD_LIBRARY_PATH with the /usr/lib/oracle/12.1/client/lib/ directory (in your .profile or .environment or .bash_profile or (if you want it for all users) in the /etc/bash.bashrc file) - i don't know if sqlplus takes care of the LD_LIBRARY_PATH - just have a try.
To see to what LD_LIBRARY_PATH is set you have to type:
echo $LD_LIBRARY_PATH
(note the $ if you want to read the value!)
Hope this helps!
Using direnv
Install direnv
, which is a tool for this purpose which is a statically linked executable that hooks into your shell (csh,bash, and the like)
sudo apt-get install direnv && echo "eval "$(direnv hook bash)"" >> ~/.bashrc
Now to whichever folder you'd like the environment variables to be set, add an .direnvrc
file that must have valid bash syntax. For example of your case, you can load both pyenv's version management as well as your own variables by setting your .direnvrc
to:
use_python() {
local python_root=$PYENV_ROOT/versions/$1
load_prefix "$python_root"
if [[ -x "$python_root/bin/python" ]]; then
layout python "$python_root/bin/python"
else
echo "Error: $python_root/bin/python can't be executed."
exit
fi
}
export CUSTOM_VAR="xyz";
You can see other examples at their wiki
Thanks to @ChrisKuehl in the comments for the suggestion
Another alternate approach would be to override the PROMPT_COMMAND
(as suggested in the comments by @steeldriver) to point to a function that loads your environment variable up, by adding something like this to your .bashrc
prmfn() {
if [ "$PWD" == "yourdirectorypath" ]; then
export CUSTOM_ENV_VAR=value
else
unset CUSTOM_ENV_VAR
fi
}
export PROMPT_COMMAND=prmfn
Now when you enter yourdirectorypath
, it'll automatically set CUSTOM_ENV_VAR
, when you exit out of it, it'll unset
(remove) the variable, hence that variable is only available when the current directory is yourdirectorypath
Best Answer
First, in general, setting the env var
CLASSPATH
usually causes more problems than it solves -- since not all app's want/need the same classpath, & often break when undesired or even unneeded jars are included in the classpath. A java app should only include the minimum number of jars it requires, no more, no less.When you have specific, individual apps that do require that the classpath be set, then usually the command-line option is preferred:
java -cp path1:path2:...
. Desktop icons can have their command altered to include these options, or shell scripts can be modified to include these options.That being said (and since there are always exceptions to the rule), then depending on the version of java (this requres java 6 or later), you can specify that a whole directory of jars be added to the classpath by adding a "
*
" at the end of a directory; e.g, the following:Means:
/dir1/foo.jar
- (the single jar) will be added to the classpath;/dir2/dir3
- all un-jar'd classes in this directory will be added to the classpath (must be in proper package structure; e.g,com.my.Foo.class
must be in/dir2/dir3/com/my/Foo.class
)/dir5/dir6/*
- all jars in this directory (i.e.,/dir5/dir6/*.jar
) will be added to the classpath. Note that this "*
" isn't a wildcard (you can't usef*.jar
or even*.jar
); it's a special character indicating "add all jars"In general, if you have to add a whole directory of jars to the application's classpath, the app was not bundled correctly. Rather, the app should have a manifest containing the list of jars it depends on. Or at the very least, only one jar should be added to your classpath, and that jar can have in its manifest the whole list of jars in some subdirectory.