getpass and IDEs

[Andrew]

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.

 

[Wolfgang Rohdewald]

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.

I'd say your IDE redirects stdout/stderr so it can show
output within the IDE

http://docs.python.org/library/getpass.html
reading python docs lets me believe you are using
python pre 2.6

if so, you could try to open a stream to /dev/tty and pass
that to getpass.getpass()

 

[Andrew]

On Freitag 25 Februar 2011, Andrew wrote:

I'd say your IDE redirects stdout/stderr so it can show
output within the IDE

http://docs.python.org/library/getpass.html
reading python docs lets me believe you are using
python pre 2.6

3.2. Though maybe you're right anyway. Does IDLE redirect in that
fashion? Why would that interfere with getpass?

I'm less concerned about how to get around it as with figuring out why
it does it. More curiosity than practicality.

 

[Nobody]

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).