Develop Reference

Bash chaining commands with vs without semi-colon

Observed an interesting bash behavior that I don't understand.
Basically, when chaining commands in bash, whether there's a semi-colon between the two commands seem to make a difference in bash behavior. In particular the two examples below, one can read the env variable in Python, the other cannot
yuli#yuli-desktop:~$ A=1; python3
Python 3.8.10 (default, Nov 26 2021, 20:14:08)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ['A']
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.8/os.py", line 675, in __getitem__
raise KeyError(key) from None
KeyError: 'A'
>>> exit()
In a new bash process:
yuli#yuli-desktop:~$ A=1 python3
Python 3.8.10 (default, Nov 26 2021, 20:14:08)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>>
>>>
>>> os.environ['A']
'1'

You're not chaining two commands in the second example.
When you run a command in bash, you can set per-command environment variables by prefixing the command line with variable assignments, as in:
A=1 B=2 COLOR=red python3
In this case, those variables (A, B, COLOR) will be available in the environment of the command:
>>> os.getenv('COLOR')
'red'
In the first example, the semicolon splits the command line into two independent commands. Since the python3 command has no variable assignments associated with it, you're not setting any environment variables. Instead, you've set a shell-local variable A that would be visible in the shell but not in any child processes.
You can see documentation about this in the "SHELL GRAMMAR" section of the bash man page.
In comments, ErikMD mentions the export shell built-in, which is used to set persistent environment variables:
$ export COLOR=red
Or:
$ COLOR=red
$ export COLOR
An environment variable set this way will persist until explicitly unset and will be available in all subsequent commands. Contrast that with a variable set as part of a command invocation (as discussed earlier in this answer), which is only available for the duration of that command.

Python import working on host but not inside a VM

Pythonproject directory structure is like
--test
--upperlevel
-- __init__.py
-- manager.py
-- UpperLevel.py
this files in turn contains
# __init__.py
msg = "YAYY printing !!!"
print msg
# UpperLevel.py
from upperlevel import msg
# manager.py
import UpperLevel
So in my local MAC book with python 2.7.10, started a python shell in test directory.
From that shell,
Python 2.7.10 (default, Jul 30 2016, 19:40:32)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import upperlevel.manager
YAYY printing !!!
>>>
it worked !!!!
However i started a virtual machine (ubuntu 14.04 and python 2.7.10) with vagrant and added same test directory to it.
so if i did the same thing
Python 2.7.10 (default, Jul 13 2017, 19:26:24)
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import upperlevel.manager
YAYY printing !!!
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "upperlevel/manager.py", line 1, in <module>
import UpperLevel
File "upperlevel/UpperLevel.py", line 1, in <module>
from upperlevel import msg
File "upperlevel/upperlevel.py", line 1, in <module>
from upperlevel import msg
ImportError: cannot import name msg
>>>
So my questions are
1) why it is not working in the later case, i tried the same in docker and getting the same error
2) there is no such file in my project, File "upperlevel/upperlevel.py", line 1, in
3) why it is searching for upperlevel.py instead of UpperLevel.py
FYI
It looks like if we do "import upperlevel" from UpperLevel.py it is refering back to itself instead of going to upperlevel/init.py.
UPDATE:
I understood where the problem is from.... my test directory(volume) is being shared between mac and vagrant/docker, somehow UpperLevel.pyc is being treated as upperlevel.pyc in that shared volume.
Instead of running in a shared directory i created same folders/files in /home/vagrant and it worked.

It seems you are running from a Mac environment, and it is possible that the Python default search paths are different for those builds, despite the version being similar.
Try comparing:
import sys
print(sys.path)
It is probable that the default installation search paths might differ.
You can use the environment variable $PYTHONPATH to add additional import paths, while I don't really like this method it can be sufficient in most cases.
You can also setup your package in a proper module installation path.

Finally answering my own question...the problem is mac has a case insensitive file system and when it is mounted on linux, python is trying to use ubuntu mode of module reading like in the case sensitive way on a case insensitive File system.
After a lot of research found this link for docker https://github.com/docker/for-mac/issues/320 so those when using ubuntu docker with python on a mac be careful with your naming conventions.

Ubuntu VTK for Python compiled from source

I compiled VTK 7.0 (6.3 has the same effect) over cmake with following params:
-LIBRARY_OUTPUT_PATH:PATH="" -CMAKE_INSTALL_PREFIX:PATH="/usr/local" -VTK_ENABLE_VTKPYTHON:BOOL="1" -Module_vtkPython:BOOL="1" - -VTK_Group_Qt:BOOL="1" -CMAKE_OBJCOPY:FILEPATH="/usr/bin/objcopy" -VTK_RENDERING_BACKEND:STRING="OpenGL2" -VTK_INSTALL_PYTHON_MODULE_DIR:PATH="/usr/local/lib/python2.7/site-packages" -DVTK_EGL_DEVICE_INDEX:STRING="0" -VTK_WRAP_PYTHON:BOOL="1" -Module_vtkGUISupportQtOpenGL:BOOL="1"
Now i can find the binary "vtkpython" at /usr/local/bin .
Good news:
I am allowed to enter python shell with the command "vtkpython" out of this directory (/usr/local/bin) with all the needed vtk bindings.
markovich#markovich-desktop:~$ cd /usr/local/bin/
markovich#markovich-desktop:/usr/local/bin$ vtkpython
vtk version 7.0.0
Python 2.7.10 (default, Oct 14 2015, 16:09:02)
[GCC 5.2.1 20151010] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import vtk
>>> vtk
<module 'vtk' from '/usr/local/lib/python2.7/site-packages/vtk/__init__.py'>
>>>
Thats a bit irritating because i am expecting to run my default python environement and the vtk bindings are available.
so the bad news:
if I type python in my shell or vtkpython from another location on my system the shell says "no modulen named vtk found" on calling import vtk .
markovich#markovich-desktop:~$ vtkpython
vtk version 7.0.0
Python 2.7.10 (default, Oct 14 2015, 16:09:02)
[GCC 5.2.1 20151010] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import vtk
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named vtk
>>>
Question 1: Maybe I missed something in the make configuration ?
Question 2: If I take the actual status (which is somehow working): Is it possible integrate the "vtkpython" bindings in my default python environment? If I am not totally wrong. The binding is correctly loaded out of my python2.7 path like you can see in the terminal:
<module 'vtk' from '/usr/local/lib/python2.7/site-packages/vtk/__init__.py'>
So how can I add this module to be loaded in Python environment?

Since loading vtkpython clearly shows that you have the module available somewhere on your system, you should be able to add the location of the vtk module to your PYTHONPATH variable.
Find where the vtk module is installed (try /usr/local/lib/python2.7/site-packages, you should see a /vtk folder). If you're unsure, you could try to find it in vtkpython with
import vtk
import imp
imp.find_module('vtk')
You can check what paths are stored in PYTHONPATH by entering in terminal:
echo $PYTHONPATH
(In my install, it was empty by default.)
Then you can add the vtk folder location to your PYTHONPATH in terminal:
export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/site-packages
Check if vtk is availabe:
$ python
>>> import vtk
If it works, you can add the export... line above into your ~/.bashrc or ~/.profile (as appropriate per your distro installation) to permanently load the option in PYTHONPATH.

Installing python

I have tried to install Python 3.4 on Windows 7 using the following guide
I have added the following to my Path in system environmental variables
C:\Python34\;C:\Python34\Scripts;
When I open up the Python command line and type the following (as instructed in the tutorial) I receive an error message printed below
Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (In
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
python --version <- what i type
Traceback (most recent call last):
File "", line 1, in
NameError: name 'python' is not defined
Can anyone help me out?

You need to type python --version from the command line. Not when you are already running python.

As has been mentioned, you need to run your command from the command prompt:
python --version
However, if you are in the python interpreter, you can find the current version with this code:
import sys
print (sys.version)

Make Emacs use UTF-8 with Python Interactive Mode

When I start Python from Mac OS' Terminal.app, python recognises the encoding as UTF-8:
$ python3.0
Python 3.0.1 (r301:69556, May 18 2009, 16:44:01)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdout.encoding
'UTF-8'
This works the same for python2.5.
But inside Emacs, the encoding is US-ASCII.
Python 3.0.1 (r301:69556, May 18 2009, 16:44:01)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdout.encoding
'US-ASCII'
How do I make Emacs communicate with Python so that sys.stdout knows to use UTF-8?
Edit: Since I don't have the rep to edit the accepted answer, here is precisely what worked for me on Aquaemacs 1.6, Mac OS 10.5.6.
In the python-mode-hook, I added the line
(setenv "LANG" "en_GB.UTF-8")
Apparently, Mac OS requires "UTF-8", while dfa says that Ubuntu requires "UTF8".
Additionally, I had to set the input/output encoding by doing C-x RET p and then typing "utf-8" twice. I should probably find out how to set this permanently.
Thanks to dfa and Jouni for collectively helping me find the answer.
Here is my final python-mode-hook:
(add-hook 'python-mode-hook
(lambda ()
(set (make-variable-buffer-local 'beginning-of-defun-function)
'py-beginning-of-def-or-class)
(define-key py-mode-map "\C-c\C-z" 'py-shell)
(setq outline-regexp "def\\|class ")
(setenv "LANG" "en_GB.UTF-8"))) ; <-- *this* line is new

check your environment variables:
$ LANG="en_US.UTF8" python -c "import sys; print sys.stdout.encoding"
UTF-8
$ LANG="en_US" python -c "import sys; print sys.stdout.encoding"
ANSI_X3.4-1968
in your python hook, try:
(setenv "LANG" "en_US.UTF8")