Develop Reference

ModuleNotFoundError when running BASH script on CMD

I have a BASH script called run2scripts.sh that runs two python scripts at the same time. Here is the BASH script:
#!/bin/bash
python text_reader.py & python text_writer.py &
When I run the bash script on the CMD terminal, the result is:
>bash run2scripts.sh
File "text_reader.py", line 2, in <module>
import matplotlib.pyplot as plt
ModuleNotFoundError: No module named 'matplotlib'
However, when I run the BASH script via Cygwin with $ ./run2scripts.sh, it works perfectly fine. Matplotlib works. I included in my .bashrc file export PATH="PATH TO PYTHON INTERPRETER" so python always goes to the path with all the modules installed. Furthermore, the command where python in CMD returns 2 results. C:\Cygwin64\bin\python and the path of the python interpreter with the modules installed. And CMD uses the latter path. The path to the interpreter is also apart of my PATH environment variable. So for these reasons, CMD shouldn't be returning a ModuleNotFoundError. print(sys.path) includes the path where Matplotlib is installed. The which python command in CMD however returns /usr/bin/python. Why is this happening and how can I fix it? I suspect the problem is related to the which python command and /usr/bin/python.

Different directory using python3.8 instead of python3.7

I tried to open a file named (choony.py) from the terminal and I got an error.So,
this is what I typed in the terminal:
python3 choony.py
This is the error that I got
No such file or directory
I tried this in the terminal
echo $PATH
This is the result that I got
/Library/Frameworks/Python.framework/Versions/3.7/bin:/Library/Frameworks/Python.framework/Versions/3.8/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
As you can see, python is running 3.7
how can I make python 3.8 the defult.

Anaconda prompt: ModuleNotFoundError when running Python script

I am trying to run the following script "test.py" on Anaconda Prompt:
from tensorflow.keras.applications.resnet50 import ResNet50
...with the following command:
(conda_env) C:\dev>test.py
This results in the following error:
ModulNotFoundError: No module named 'tensorflow'
When I run the same script on Anaconda Prompt with the following command I don't get any errors:
(conda_env) C:\dev>python test.py
I have installed tensorflow in the Anaconda environment 'conda_env'
(conda_env) C:\dev\>conda env list
# conda environments:
#
base C:\Users\xx\Anaconda3
conda_env * C:\Users\xx\Anaconda3\envs\conda_env
keras_1 C:\Users\xx\Anaconda3\envs\keras_1
tf-gpu C:\Users\xx\Anaconda3\envs\tf-gpu
Why is this like that?

You won’t get errors if you do
(conda_env) C:\dev> python test.py
because then you’re following the correct syntax for running python scripts in a terminal. By adding python before the .py file, you initiate the Python interpreter that executes your script. Without it, the terminal won’t know what Python interpreter to use to execute your script and may end up using an interpreter that doesn't have the modules you require. There are ways to skip writing python before executing if that’s what you want.
For example, see: Calling a python script from command line without typing "python" first

"python myscript" ignores "#!/usr/bin/env pythonX" where pythonX doesn't exist

Why doesn't test.py throw error env: python3: No such file or directory when Python 3 is not installed?
My system (Mac OS X) has Python 2.7 installed, but not Python 3:
$ /usr/bin/env python -V
Python 2.7.12
$ /usr/bin/env python3 -V
env: python3: No such file or directory
File test.py:
#!/usr/bin/env python3
import sys
print sys.executable
Executing test.py:
$ python test.py
/usr/local/opt/python/bin/python2.7
I thought that since Python 3 does not exist on my system, having the shebang line #!/usr/bin/env python3 will throw an error and terminate the script. But env actually selected the Python 2.7 interpreter.

The shebang is interpreted by OS when it tries to execute the script. Whey you type python test.py, the OS executes python and python executes the script (and python is found based on the current PATH) as opposed to being processed by the OS.
If you make the script executable (chmod +x test.py) and then try to execute it directly (e.g. ./test.py), the OS will be responsible for running the script so it will look at the shebang to figure out what program is responsible to run the script. In this case, it is /usr/bin/env which will look for python3 and try to use that. Since python3 isn't there (or not findable on your PATH) you'll see the error.

The shebang is only processed when you do test.py, running the file directly instead of running python with test.py as an argument. When you do python test.py, Python completely ignores the shebang line.

Access is denied error with pregenerated .pyc or .pyo files

I am getting an Access is denied error while I am trying to run the .pyo file by double click or from the command prompt.
Lets say I have abc.py (keeping main method entry point) which imports files xyz.py and imports wx etc.
I generate the .pyo file. But once I try to run abc.pyo I get the access is denied error.
I am not getting why this happening? Any help will really appreciated.
(I am using windows xp as os).
I am making .pyo from .py as following.
I am having a .bat file CompileAllToPyo.bat which have
python -O Compileall.py
The Compileall.py keep the follwoing things
import os
import compileall
os.popen3(cmdLine, 'b')
compileall.compile_dir('.', force=1)
This is all the info
Thanks

You can tell the system that your hw.pyo file is "executable", for example (in Linux, MacOSX, or any other Unix-y system) by executing the command chmod +w hw.pyo at the terminal shell prompt. Consider, for example, the following short and simple shell session:
$ cat >hw.py
print('hello world')
$ python2.5 -O -c'import hw'
hello world
$ ./hw.pyo
bash: ./hw.pyo: Permission denied
$ chmod +x hw.pyo
$ ./hw.pyo
hello world
$
By default, .pyo (and .pyc) files are not marked as executable because they're mostly meant to be imported, not directly executed (indeed, note that we're explicitly using a Python import statement to create the .pyo file!); however, as this example shows, it's quite easy to make one of them "executable as the main script". BTW, observe also:
$ cat >hw.py
print('hello world from ' + __name__)
$ python2.5 -O -c'import hw'
hello world from hw
$ chmod +x hw.pyo
$ ./hw.pyo
hello world from __main__
$
The __name__ is what tells the module whether it's being imported (so the first "hello world" says "from hw") or run as the main script (so the second one says "from __main__"). That's the reason modules that are designed to be used both ways normally end with if __name__ == '__main__': main() or the like, where main is a function that, this way, gets called iff the module's running as the main script (it's always best to have all substantial code execute in a function, not at a module's top level).

You don't "run" a .pyo file, as it's not an executable. You can give it to the python interpreter in lieu of the .py file, but in general, you should use a .py file as your entry point, so that the .pyc or .pyo file can be recreated when necessary.
$ python imported.pyo
Success!
$ ./imported.pyo
bash: ./imported.pyo: Permission denied