mjhjmtu

As far as I understand if i type the following...

 python -i

... the python-interpreter will now read from stdin, behaving (obviously) like this:

 >>> print "Hello"
 Hello

I would expect it to do the same thing if I do this:

 echo 'print "Hello"' > /proc/$(pidof python)/fd/0

But this is the output ( beeing an actual empty line):

 >>> print "Hello"
 <empyline>

This to me looks like, it just took the print "Hello"n and wrote it to stdout, yet did not interpret it. Why is that not working and what would I have to do to make it working?

Sending input to shells/interpreters in this way is very problem-prone and very difficult to get working in any reliable way.

The proper way is to use sockets, this is why they were invented, you can do this in command line using ncat nc or socat to bind a python process to a simple socket. Or write a simple python application that binds to port and listens for commands to interpret on a socket.

sockets can be local and not exposed to any web interface.

The problem is that if you start python from the command line, it is typically attached to your shell which is attached to a terminal, in fact we can see

$ ls -al /proc/PID/fd
lrwxrwxrwx 1 USER GROUP 0 Aug 1 00:00 0 -> /dev/pty1

so when you write to stdin of python, you are actually writing to the pty psuedo-terminal, which is a kernel device, not a simple file. It uses ioctl not read and write, so you will see output on your screen, but it will not be sent to the spawned process (python)

One way to replicate what you are trying is with a fifo or named pipe.

# make pipe
$ mkfifo python_i.pipe
# start python interactive with pipe input
# Will print to pty output unless redirected
$ python -i < python_i.pipe &
# keep pipe open 
$ sleep infinity > python_i.pipe &
# interact with the interpreter
$ echo "print "hello"" >> python_i.pipe

You can also use screen for input only

# start screen 
$ screen -dmS python python
# send command to input
$ screen -S python -X 'print "hello"'
# view output
$ screen -S python -x

Accessing /proc/PID/fd/0 doesn't access file descriptor 0 of process PID, it accesses the file which PID has open on file descriptor 0. This is a subtle distinction, but it matters. A file descriptor is a connection that a process has to a file. Writing to a file descriptor writes to the file regardless of how the file has been opened.

If /proc/PID/fd/0 is a regular file, writing to it modifies the file. The data isn't necessarily what the process will read next: it depends on the position attached to the file descriptor that the process is using to read the file. When a process opens /proc/PID/fd/0, it gets the same file as the other process, but the file positions are independent.

If /proc/PID/fd/0 is a pipe, then writing to it appends the data to the pipe's buffer. In that case, the process that's reading from the pipe will read the data.

If /proc/PID/fd/0 is a terminal, then writing to it outputs the data on a terminal. A terminal file is bidirectional: writing to it outputs the data, i.e. the terminal displays the text; reading from a terminal inputs the data, i.e. the terminal transmits user input.

Python is both reading and writing to the terminal. When you run echo 'print "Hello"' > /proc/$(pidof python)/fd/0, you're writing print "Hello" to the terminal. The terminal displays print "Hello" as instructed. The python process doesn't see anything, it's still waiting for input.

If you want to feed input to the Python process, you have to get the terminal to do it. See crasic's answer for ways to do that.