After installing cuda and cudnn with miniconda, whenever I start a new shell with the current user. I am always getting warnings about /usr/bin/zsh: /some/path/to/miniconda3/lib/libtinfo.so.6: no version information available.
It seemed that $LD_LIBRARY_PATH is set to /some/path/to/miniconda3/lib, but after extensive digging (examined all possible rc files in etc, $HOME, I am still unable to locate where exactly this variable is set. Also echoing $LD_LIBRARY_PATH on the top of every RC file yields this path (both login shell and non-login shell).
I would like to find out a way to disable this warning (presumably by unsetting LD_LIBRARY_PATH, is there any suggestions?
EDIT: After restarting my desktop, the error went away.. Is there any explanation why this happened? Is there some other config being executed prior to starting up the shell (in some cache file) which will be cleared after reboot?
Related
The error I was originally getting was that wsl was not able to find JAVA_HOME. After I ran the command
export JAVA_HOME="/mnt/c/Program Files/JAVA/jdk-15.0.2"
And now the error it gives me is:
ERROR: JAVA_HOME is set to an invalid directory: /mnt/c/Program Files/Java/jdk-15.0.2
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.
When I run
${JAVA_HOME}
to check the variable I get the response
bash: /mnt/c/Program: No such file or directory
Which I believe is due to the space in the file name. Online it said that the space shouldn't be an issue as it is enclosed in quotes so I don't know what to do here.
Any help would be appreciated!
It looks like you are trying to use the Windows version of Java from within WSL. That should be possible, but you are currently exporting a Linux-style path, which the Windows version won't handle (as you can see).
If you have both the Windows and Linux version of Java installed, then see this answer for some related information. The question there is about npm, but the core issue is the same -- The Windows version is getting picked up in the path before the Linux version.
If you just have the Windows version, then at least modify the JAVA_HOME to be 'C:\Program Files\JAVA\jdk-15.0.2' (watch out for potential quoting issues with backslashes in the Linux-shell string, though). I'm not sure that's going to take care of all of your issues -- I've never tried running the Windows Java version through WSL myself. But it's at least the first step you're going to need to take to get past the current error.
The second error when you just execute ${JAVA_HOME} is to be expected, as you are trying to execute this directory (with a space) as a command. The shell is interpreting the portion before the space as a command, and the portion after the space as the argument. If you were to set it to a directory without a space, you'd still get an error message when trying to execute it (as you are now), just that it would be something like bash: /mnt/c: Is a directory.
If you just want to check it, use echo ${JAVA_HOME}.
I have anaconda3 installed on 2 machines and both are 2019.10 version. On one of the machines, if I type conda activate <tab> bash will produce a list of my environments. I've never done anything specific on this machine to enable this - it just works. On the other machine, my environment names were not produced. I cannot tell where the difference might be captured - I've looked in ~/.profile, ~/.bashrc, and /etc/profile.d and didn't find anything noteworthy between the two systems.
I've tried installing conda-bash-completion, and that actually made it worse. Now, instead of not producing anything with the above command, it produces a list of basically all files/folders in my current directory, none of which are environments. Further, I've removed conda-bash-completion and yet this new behavior persists.
Any help is appreciated!
I have setup multiple python environment using Anaconda.
Usually, to run a script "manually", I would open a command line and then type:
activate my-env
python path/to/my/script.py
Fine.
Now I am trying to run a script automatically using a scheduler and I was wondering what the difference was between
Writing a batch which activates the environment and the executes the script (like in the snippet above)
Calling directly the python executable from the environment (within the envs/my-enjv/ directory) like below:
/path/to/envs/my-env/python.exe path/to/my/script.py
Both seem to work fine. Is there any difference?
I don't claim to be an expert but here's my 2 cents.
For small scripts, no, there isn't a difference.
You should notice a difference when calling external modules / packages. conda activate alters the system path to change how the command shell searches for the appropriate capabilities.
If you supply a full path to an interpreter and the full path to an isolated script, then the shell doesn't need to do a lookup as this has priority over the path. This means you could be in a situation where the interpreter can see the script but cannot see dependencies.
If you follow the conda activate process, and the environment is correctly packaged, then the shell will be able to trace any additional resources.
EDIT: The idea behind this is portability. If an admin has been careful in setting up a system, then scripts should have the appropriate visibility - i.e. see everything in it's environment plus everything in the main system installation.
It's possible to full-path every call to an interpreter and a script or package location, but then what happens when you need to move it to another machine? You would need to spend a lot of time setting everything up exactly as it was before. On the other hand, you can follow the package process and the system path will trace everything for you.
Simply checkout the PATH variable in your environment. After conda activation it has been extended by
\Anaconda3;
\Anaconda3\Library\mingw-w64\bin;
\Anaconda3\Library\usr\bin;
\Anaconda3\Library\bin;
\Anaconda3\Scripts;
\Anaconda3\bin;
This doesn't make much of a difference, if you are just using the standard library in your code. However, if you rely on external packages like pandas, it's a prerequisite so that the modules can be found.
Following Installing Emacs, I set HOME environment variable to a directory (c:), and make a _emacs file in the directory. It has this one line of code (server-start).
When I execute emacs (GNU Emacs 23.3.1 (i386-mingw-nt6.1.7601)), I get this error message.
Warning (initialization): An error occurred while loading `c:/_emacs':
error: The directory `~/.emacs.d/server' is unsafe
What's wrong with this?
Emacs - Error when calling (server-start) has the answer.
"The problem is the ownership of the directory ~/.emacs.d/server when
you also have “Administrators” rights on your account. Create the
directory ~/.emacs.d/server and set the owner of this directory to
your login name and the problem is gone.
Are you running on Windows 7 (or perhaps Vista)? At some point after XP, Windows decided that putting things in c:\ is a no-no. I guess for security reasons. If you don't set a home environment variable, then emacs will look for your .emacs in c:\users\yourname\appdata\roaming (or something like that - Win 7 machine w/emacs is at work, can't check exactly). You can also create your .emacs.d directory there too if you want.
At the very least, the message is not clear enough. Probably, Emacs should not simply barf this way. In any case, my advice would be to use M-x report-emacs-bug to let the Emacs developers know about this. Hopefully they will address the problem one way or another -- at least provide a more helpful message to users.
I'm following the instructions from various Wikis on how to compile Node so I can eventually get it running as a service on Windows.
My steps so far:
https://github.com/joyent/node/wiki/Installation
(which lead to...)
http://blog.tatham.oddie.com.au/2011/03/16/node-js-on-windows/
(successfully compiled via cygwin, but lead to...)
https://github.com/joyent/node/wiki/Building-node.js-on-mingw
(which apparently is better than the so far successful cygwin compile)
So - I've managed to compile Node.exe using Cygwin but not the preferred Mingw. I concur this isn't an ideal situation, building on Windows isn't the ideal. Nevertheless.
The error I see in Mingw, once I've followed all of the steps above, occurs when I try to ./configure --without-ssl. The error message is:
Danjah#PC /c/cygwin/home/Danjah/node-v0.4.7/node
$ ./configure –without-ssl
/usr/bin/env: python: No such file or directory
I understand from step 3's URL, that I must take steps to provide the environment variables for both Python and Git - using help from the provided URL I managed to input the Python path var, but I don't think I have the Git path var right. Either way, in no install directories for Python, Cygwin or Mingw32 do I see the path specified in the error msg: "/usr/bin/env".
Googling didn't really bring much to the table in terms of env variables or Mingw32, best I got was: PATH=C:\MinGW\bin;C:\MinGW\msys\1.0\bin where my install directory is at C:\MingW\.
The path I added to Windows environment vars for Python was: PythonPath=C:\Python27;C:\Python27\DLLs;C:\Python27\Lib;C:\Python27\Lib\lib-tk where Python 2.7 is installed in C:\Python27\.
I hate it when a file path stops you from doing things, as I suspect is the problem here. So please set me straight here - is it a file path problem I have or something else? And if its something else, please try and help me to get Node up and running... keen as to get experimenting.
I should probably also mention that I do also have a previously installed version of Git on my Windows XP SP3 machine, but had not previously had Cygwin, Mingw32 or Python installed, and I do not have IIS running as a service - my usual testing environment is a WAMP stack.
Windows uses the PATH environment variable to locate programs that are invoked without a fully qualified file path, i.e. 'python' rather than 'C:\Python27\python'.
So you need to add python's home directory to the Windows PATH variable, as well as MinGW, git and anything else your script requires.
Also by setting the PATH variable explicitly in your shell session or script, you are overwriting its original contents (in the local context) which limits which programs your shell can find to only those available within the PATH which is usually a bad idea.
See http://www.java.com/en/download/help/path.xml for details on modifying your PATH so you can always run your Python scripts from the command line.