#7 stdin from terminal don't close properly

[Frank Tobin]

When reading stdin from the terminal, readyexec takes
EOF to mean simply 'flush', with a double EOF causing
the desired effect of actually closing the stdin.

Furthermore, if readyexec is interrupted while reading
from stdin, the terminal seems to keep sending the
charaters to readyexecd, and the chars aren't displayed
on the terminal. The terminal is rendered useless.

[Jonathan Paisley]

Logged In: YES
user_id=624739

Can you give specific steps to reproduce this (first para)?

Re: second para -- even if the readyexec stub dies, the server
child still has copies of the terminal's file descriptors, so can still
read and write. It might be worth experimenting with forwarding
of signals from the stub. The server child could send its pid over
the socket and the stub could handle and forward selected
signals. Can you give specific steps to reproduce this (first para)

[Frank Tobin]

Logged In: YES
user_id=7577

The EOF problem seems to only occur on gnu/linux system, and
not on freebsd. Specifically, it can be triggered with the
test.printit function:
./readyexecd.py testsock test.printit
and in another terminal...
./readyexec testsock

The first line that is read into stdin that you enter via
terminal input is pulled in by the shell 'read' via
os.system that you introduced. So enter anything for that
line. After that line is read, enter anything for the
second line of stdin (ending the line with a newline), and
then hitting ctrl-d. The only thing that happens is that
the stdin gets 'flushed' to the server (maybe because
something thinks that stdin is being closed), which you can
tell because test.printit echoes what it reads on stdin to
stdout and stderr. However, you can still enter more data
into stdin after the ctrl-d, and it also gets echoed back to
the client.

With regards to the second para, you're correct; the server
still holds the fd, and once you kill the server, you regain
control of your terminal (e.g., the terminal input fd is no
longer held by the server).

Interesting idea to have the stub forward some signals. I
don't think it'd be hard to implement, either. I'll opena
feature request for it.

[Jonathan Paisley]

Logged In: YES
user_id=624739

The stdin from terminal problem (first paragraph) isn't due to
readyexec. Try running the test script directly.

The reason for the behaviour you're seeing is as follows: the
code 'for line in sys.stdin' boils down to something like this
(though it's implemented in C):

while 1:
lines = sys.stdin.readlines(8192)
if not lines: break
for line in lines:
<main code here>

Thus, if an EOF is reached before 8192 lines have been read,
the outer loop will repeat.

I think that's it...

[Frank Tobin]

Logged In: YES
user_id=7577

My head is spinning in circles thinking about this. Let me
just write stuff so that it might become clearer.

Both the server and the terminal have the 'same' fd (passing
fd's is supposed to be like dup2). So sending ctrl-d via
the terminal (EOF), one would think that this closes the fd
'everywhere'. AAAAHH, but EOF != closing the fd. It can
only be closed by the process holding it open for reading
(the server). ctrl-d doesn't close, only sends an EOF. So
it *can* read more (just like tail -f). As to the flushing
by EOF, EOF will cause read(2) finish blocking.

So it seems that the first paragraph's problems are
unresolvab.e (It was really silly of me to group the two
problems together; I thought they were related, but aren't).