getpass and IDEs

[Nobody]

On Fri, 25 Feb 2011 11:50:35 -0500, Andrew wrote:

> I find that calling getpass produces a warning noting that it can't
> suppress output, if I'm using idle, wingide, or a few others. If I'm
> running from the console it works fine, but then I can't make use of
> ide-integrated debugging. 
> 
> I know I could just set up a test account for development purposes if
> I'm concerned about shoulder surfers, and that's probably a good idea
> anyway. But I'm curious what's different about IDE environments that
> makes it impossible to suppress output on them, and if there's anything
> that might be done about this.

This suggests that the Python interpreter isn't getting a controlling
terminal when spawned from the IDE.

If I run IDLE from a shell, IDLE inherits the shell's controlling
terminal, which the interpreter inherits from IDLE. So getpass() works
correctly, but it uses the original terminal not the IDLE window. If IDLE
is spawned from a desktop environment, there probably won't be any
controlling terminal.

The odd thing is that the Python interpreter spawned from IDLE inherits
its (real) std{in,out,err} from IDLE. If IDLE was started from a terminal,
the interpreter will have that its standard descriptors associated with
the terminal. But the Python sys.std{in,out,err} objects are of
type idlelib.rpc.RPCProxy. This means that anything written via
e.g. "print" or "sys.stdout.write()" will be sent to IDLE, while
e.g. os.write() or child process will use the inherited descriptors.

This behaviour isn't inevitable; it's just the way IDLE works. If an IDE
allocates a pty for the interpreter, and the IDE doesn't already have a
controlling terminal, the pty will become the controlling terminal unless
it explicitly prevents this (by openeing it with the O_NOCTTY flag).