Develop Reference

Python os.environ doesn't show empty environment variables

After an environment variable is exported and set to empty, I can't get its value in Python with os.environ. Is it expected?
Examples:
## export TEST_ENV_VAR
(base) ➜ Code export | grep TEST_ENV_VAR
TEST_ENV_VAR=''
(base) ➜ Code python
Python 3.8.12 (default, Oct 12 2021, 13:49:34)
[GCC 7.5.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> 'TEST_ENV_VAR' in os.environ
False
## export TEST_ENV_VAR=''
(base) ➜ Code export | grep TEST_ENV_VAR
TEST_ENV_VAR=''
(base) ➜ Code python
Python 3.8.12 (default, Oct 12 2021, 13:49:34)
[GCC 7.5.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> 'TEST_ENV_VAR' in os.environ
True
## export TEST_ENV_VAR='TEST'
(base) ➜ Code export | grep TEST_ENV_VAR
TEST_ENV_VAR=TEST
(base) ➜ Code python
Python 3.8.12 (default, Oct 12 2021, 13:49:34)
[GCC 7.5.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> 'TEST_ENV_VAR' in os.environ
True
The three samples above run in three different new terminals. I modified the .zshrc file to export different values. What's the difference between export foo and export foo=''?

There is a difference between "Shell variables" and "Environment Variables" - see here - A shell variable is only available to the shell setting it whereas an environment variable is available to all child processes as well.
In bash - you can get the list of environment variables with env, and add to the environment variables with export
SHELL_VAR="10"
env | grep SHELL_VAR # No result
export ENV_VAR=100
env | grep ENV_VAR # ENV_VAR=100
Python shell (child process) picks the environment variables when you try an os.environ
'SHELL_VAR' in os.environ # False
'ENV_VAR' in os.environ # True

The issue is the way you are defining your variables.
When you just do:
export FOO
no variable is actually exported unless FOO has been defined previously:
FOO=''
export FOO
or concomitantly:
export FOO=''
If FOO appears in env | grep FOO, it should appear in os.environ.

Using pwntools process interactive mode to control python3

I am trying to use pwntools to control a python3 session. Here is my code:
from pwn import process
r = process(['python3'])
r.interactive()
However, after I enter r.interactive(), when I type into the terminal, the python3 sub-process has strange reactions. At least I do not see my commands echoed back most of the times.
I also tried to call python3 in a bash session, but the same thing happens.
$ python3
Python 3.8.5 (default, Jan 27 2021, 15:41:15)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pwn import process
>>> r = process(['bash'])
[x] Starting local process '/usr/bin/bash'
[+] Starting local process '/usr/bin/bash': pid 119080
>>> r.interactive()
[*] Switching to interactive mode
echo hello
hello
echo this is bash
this is bash
python3
print(1)
print(2)
print(3)
exit
echo hello
File "<stdin>", line 5
echo hello
^
SyntaxError: invalid syntax
Why is this happening? Is it a bug in pwntools, or are there some configurations I overlook?

You need to specify the PTY in your shell, so like this:
$ python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pwn import *; r = process(['python3'], stdin=PTY, raw=False); r.interactive()
[x] Starting local process '/usr/bin/python3'
[+] Starting local process '/usr/bin/python3': pid 2984281
[*] Switching to interactive mode
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1+1
1+1
2
>>>

Disable python auto-escaping for environment variables

I am having the following problem with python, being used to generate
files on Linux, that are being read on Windows. Python is auto-escaping
the strings, so that when written to a file, they are incorrect.
In my shell I have the environment variable set to a UNC path:
camd011> setenv python_error "\\\\a\\b\\c"
camd011> echo $python_error
\\a\b\c
I then retrieve this in python, as it will be used to generate C code
and a #include directive. However when I retrieve the value in python:
camd011> python
Python 1.6.1 (#1, Oct 17 2013, 15:08:20) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Copyright (c) 1995-2001 Corporation for National Research Initiatives.
All Rights Reserved.
Copyright (c) 1991-1995 Stichting Mathematisch Centrum, Amsterdam.
All Rights Reserved.
>>> import os
>>> value = os.environ['python_error']
>>> value
'\\\\\\\\a\\\\b\\\\c'
As you can see above it has been auto-escaped, thus when I write it to a file:
>>> f = open("temp.txt", "w")
>>> f.write(value)
>>> f.close()
I end up with double-slashes, instead of a proper UNC path, and the code
now fails to compile. File:
\\\\a\\b\\c
i.e. the code includes a #include which now fails:
#include "\\\\a\\b\\c\file.h"
How do I stop python from auto-escaping my environment variable?

This appears to be a problem with quoting and dequoting in tcsh. It has nothing to do with Python -- Python gets the same variable that you can print out with the env command.
It appears that in tcsh, echo $FOO de-quotes the value of $FOO before printing. This seems to have misled you about what is really in your environment variable, so you've added an extra layer of quoting.
unaha-closp:~> setenv FOO "\\hello\world"
unaha-closp:~> echo $FOO
\hello\world
unaha-closp:~> env | grep FOO
FOO=\\hello\world
unaha-closp:~> python
Python 2.7.3 (default, Sep 26 2013, 20:03:06)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> print os.environ["FOO"]
\\hello\world
>>>
unaha-closp:~> bash
svk#unaha-closp:~$ echo $FOO
\\hello\world
The proper setenv command should simply be setenv python_error "\\a\b\c".

python interative mode does not work when reading from std in

Given the following python script....
$ cat readStdin.py
#!/usr/bin/python
import sys
var = "".join(sys.stdin.readlines()).rstrip()
print var
... I get the follwing output:
$ echo hello | python -i readStdin.py
hello
>>>
$
... in other words it does not hang in the python console, but goes back to bash. Does anyone out there know how to make it stay in the python console???

Consider this -
$ echo print 4*2 | python -i
Python 2.7.2 (default, Jun 20 2012, 16:23:33)
Type "help", "copyright", "credits" or "license" for more information.
>>> 8
>>>
$
Echo produces print 4*2. Python even in interactive mode, considers this as input to be interpreted. Hence we see the 8 there. After this, the interpreter encounters an EOF, so it quits. Consider what you press to quit the interpreter - Ctrl+d or ^D. This is just another way to produce EOF on *nix.

Unknown screen output of manually installed Python 2.7

I installed Python 2.7 today using:
./configure --prefix=/home/zhanwu/local --enable-shared --enable-profiling --with-pydebug
make install
Then I keep getting something like "[37745 refs]" on screen after each function call:
[zhanwu#cluster ~]$ ~/local/bin/python
Python 2.7.1 (r271:86832, Jun 16 2011, 17:45:05)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
[37745 refs]
>>> print 'test'
test
[37745 refs]
>>> sys.exit()
[18048 refs]
[zhanwu#cluster ~]$
What does those numbers mean? Anything wrong here and can I get rid of them?
uname -a result:
[zhanwu#cluster ~]$ uname -a
Linux cluster.xxx.xxx.xxx 2.6.18-128.1.14.el5 #1 SMP Wed Jun 17 06:38:05 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

You get these because you configured the build with --with-pydebug. They denote the number of references Python is currently keeping track of. To get rid of them, configure without --with-pydebug.