More configurable (choose what sys.__std*__/sys.std* to patch on connect time)

[ionelmc]

No description provided.

[nirs]

This is not something that should be configurable. We can avoid patching stdin, by taking input directly from the socket - but you cannot avoid patching stdout and stderr - otherwise you loose some output.

If you look into twisted.manhole.telnet.py, you can see that they patch only stdout and stderr. I think this is good enough, as daemons that may use the manhole never take input from stdin.

[ionelmc]

I'm thinking what happens if you do import pdb; pdb.set_trace() in the session. It won't work if stdin is not redirected ...

[nirs]

I never tried it. I think that the safest way would be to use all sys.stdxxx files as you do now.

I would close this issue for now.

[ionelmc]

I still wanna make it configurable one day, don't close it 😬

[ionelmc]

Another trick we could do it do a thread-local proxy for inputs/outputs (like here https://github.com/py-eww/eww/blob/master/eww/ioproxy.py). Worth noting eww is very similar to manhole.

[nirs]

I think it is incorrect - you want output from all threads to go to your console.

For example, you may call a function that start a thread and run a subprocess, reading from the process stdout and printing. If we use thread local, I will not see the output from the new thread in my console.

[ionelmc]

I was pointing out the technique - as it would allow multiple client
connections (#7). There are tradeoffs ofcourse - so it could be something
configurable.

Eg, have an option multiple_clients=False; if it's True then the
threadlocal redirection is used.

Thanks,
-- Ionel M.

On Wed, Sep 3, 2014 at 4:57 PM, Nir Soffer [email protected] wrote:

I think it is incorrect - you want output from all threads to go to your
console.

For example, you may call a function that start a thread and run a
subprocess, reading from the process stdout and printing. If we use thread
local, I will not see the output from the new thread in my console.

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

[nirs]

It will not work for multiple connections. It will allow each connection to run code like:
print "foo"
But again if you start another thread, no connection will get the other thread output.

Do you see a use case where 2 people connect in the same time to the same process?

If there is a reall need for this, I think the solution is that stdin will use the connection socket, and stdout/err will send output to all connected clients.

[ionelmc]

I don't have an usecase right now, I'm just writing down ideas.

In the future we could build some specialized client (to get interesting info from the process). You'd still want to be able to run that tool while you have an open session.

[ionelmc]

Ref #23

[nirs]

I still think closing this issue is the best way. 3 years passed and nobody asked for this feature :-)