Nohup Failing with Anaconda Ipython

Conda command working in command prompt but not in bash script

I solved the problem thanks to @darthbith 's comment.

Since conda is a bash function and bash functions can not be propagated to independent shells (e.g. opened by executing a bash script), one has to add the line

source /opt/anaconda/etc/profile.d/conda.sh

to the bash script before calling conda commands. Otherwise bash will not know about conda.

Running python py file from cmd but getting ImportError. Running from conda prompt is working

What the Anaconda Prompt does is it adds several folder to your system path: Not just the location of the interpreter, but also the location of the dll libraries.

If you are running from the cmd prompt, you probably just have the interpreter on the path, nothing else. This is why the dll import fails.

You ALWAYS have to activate conda before you have access to the full Anaconda Python installation. See activating an environment. Note that there is at least the base environment.

Error when executing `jupyter notebook` (No such file or directory)

It seems to me as though the installation has messed up somehow. Try running:

# For Python 2
pip install --upgrade --force-reinstall --no-cache-dir jupyter
# For Python 3
pip3 install --upgrade --force-reinstall --no-cache-dir jupyter

This should reinstall everything from PyPi. This should solve the problem as I think running pip install "ipython[notebook]" messed things up.

Python - Activate conda env through shell script

The error message is rather helpful - it's telling you that conda is not properly set up from within the subshell that your script is running in. To be able to use conda within a script, you will need to (as the error message says) run conda init bash (or whatever your shell is) first. The behaviour of conda and how it's set up depends on your conda version, but the reason for the version 4.4+ behaviour is that conda is dependent on certain environment variables that are normally set up by the conda shell itself. Most importantly, this changelog entry explains why your conda activate and deactivate commands no longer behave as you expect in versions 4.4 and above.

For more discussion of this, see the official conda issue on GitHub.

Edit: Some more research tells me that the conda init function mentioned in the error message is actually a new v4.6.0 feature that allows a quick environment setup so that you can use conda activate instead of the old source activate. However, the reason why this works is that it adds/changes several environment variables of your current shell and also makes changes to your RC file (e.g.: .bashrc), and RC file changes are never picked up in the current shell - only in newly created shells. (Unless of course you source .bashrc again). In fact, conda init --help says as much:

IMPORTANT: After running conda init, most shells will need to be closed and restarted for changes to take effect

However, you've clearly already run conda init, because you are able to use conda activate interactively. In fact, if you open up your .bashrc, you should be able to see a few lines added by conda teaching your shell where to look for conda commands. The problem with your script, though, lies in the fact that the .bashrc is not sourced by the subshell that runs shell scripts (see this answer for more info). This means that even though your non-login interactive shell sees the conda commands, your non-interactive script subshells won't - no matter how many times you call conda init.

This leads to a conjecture (I don't have conda on Linux myself, so I can't test it) that by running your script like so:

bash -i shell_script.sh

you should see conda activate work correctly. Why? -i is a bash flag that tells the shell you're starting to run in interactive mode, which means it will automatically source your .bashrc. This should be enough to enable you to use conda within your script as if you were using it normally.

How to run jupyter notebook in the background ? No need to keep one terminal for it

You can put the process into the background by using jupyter notebook --no-browser & disown. You can close the terminal afterwards and the process will still be running.

If you're using zsh you can also use a shorter version that does the same: jupyter notebook --no-browser &!.

To kill the process you can use pgrep jupyter to find the PID of the process and then kill 1234, replacing 1234 with the PID you just found.

Explanation

The --no-browser flag makes jupyter not open the browser automatically, it also works without this flag.

The & puts it into the background of the currently running shell.

The disown then removes the job from the background of the currently running shell and makes it run independently of the shell so that you may close it.

In the zsh version the &! is a built-in function that does the same as & disown.

ImportError: No module named when trying to run Python script

This issue arises due to the ways in which the command line IPython interpreter uses your current path vs. the way a separate process does (be it an IPython notebook, external process, etc). IPython will look for modules to import that are not only found in your sys.path, but also on your current working directory. When starting an interpreter from the command line, the current directory you're operating in is the same one you started ipython in. If you run

import os
os.getcwd()

you'll see this is true.

However, let's say you're using an ipython notebook, run os.getcwd() and your current working directory is instead the folder in which you told the notebook to operate from in your ipython_notebook_config.py file (typically using the c.NotebookManager.notebook_dir setting).

The solution is to provide the python interpreter with the path-to-your-module. The simplest solution is to append that path to your sys.path list. In your notebook, first try:

import sys
sys.path.append('my/path/to/module/folder')

import module_of_interest

If that doesn't work, you've got a different problem on your hands unrelated to path-to-import and you should provide more info about your problem.

The better (and more permanent) way to solve this is to set your PYTHONPATH, which provides the interpreter with additional directories look in for python packages/modules. Editing or setting the PYTHONPATH as a global var is os dependent, and is discussed in detail here for Unix or Windows.