[ python-Bugs-1233785 ] getpass.getpass() performs differently on Windows vs *nix

[SourceForge.net]

Bugs item #1233785, was opened at 2005-07-06 23:36
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Darryl Dixon (esrever_otua)
Assigned to: Nobody/Anonymous (nobody)
Summary: getpass.getpass() performs differently on Windows vs *nix

Initial Comment:
getpass.getpass() on *nix platforms allows users to
input unicode characters and other NLS input. 
getpass.getpass() on Windows only allows ASCII input in
the 0-127 codepage range.  This means that getpass can
not be used cross-platform for complex passwords.

----------------------------------------------------------------------

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-07 12:01

Message:
Logged In: YES 
user_id=1188172

First of all, don't accuse me of lying. If I wanted to lie
professionally, I would have become politician, not programmer.
I'm German, and using a German keyboard layout which does
have the ü, so it can be perfectly input.

Your problem is that you cannot input characters which don't
directly create keycodes on the keyboard, but must be copied
to the console in some way.

In python-dev, you said that msvcrt.getch() would have to
call _getch() a second time in the case that it returns 0x00
or 0xe0 the first time and/or return a Unicode string.

First, the documentation for _getch() says that this is a
special case for arrow and function keys (such as F1 or
<Up>). These keys don't have a representation in any
character set, as they are control keys, so how would you
represent them as Unicode?
Second: In my console, pressing F7 yields the return values
"\x00" and "A".
When the 0x00/0xe0 read the first time is secretly
swallowed, the user of msvcrt.getch() can't know whether the
user pressed "A" or F7.
That said, the behaviour of getch() is documented and correct.


But how does that all help you with your original problem,
which is that _getch() doesn't help you with Alt+XXXX
sequences or console window Copy-Paste? In my understanding
_getch() only works with characters directly input to the
console. Sorry, but then this is not a Python problem but a
Windows one.

----------------------------------------------------------------------

Comment By: Darryl Dixon (esrever_otua)
Date: 2005-07-07 11:18

Message:
Logged In: YES 
user_id=567623

I think that, because I've read the source, and
getpass.getpass() uses msvcrt.getch() on Windows, which
doesn't support anything at all above ASCII 255.

Also because I have a bug report pending against one of the
projects that I maintain from a user that is experiencing a
problem because of exactly this issue.

See:
https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=69259&atid=523935

Also, I call shenanigans on your claim of successfully
inputting an umlaut-u into getpass.getpass(); this character
can *theoretically* be input, as it's below ASCII 255, but
in practice I can neither input it directly, nor COPY+PASTE
it from the clipboard on my WinXP SP2 with Python 2.4.1
installed.

Finally, regardless of whether "ü" works or not, other
characters that live solely in unicode, such as "¿" most
certainly do not (and never will) work (not even theoretically).

Regards,
D

----------------------------------------------------------------------

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-07 10:46

Message:
Logged In: YES 
user_id=1188172

What makes you think that? I tried it on Windows XP, in a
cmd.exe session.

I could enter, for example, an ü (umlauted u), which in the
resulting string came out encoded as \x81, as is correct in
the encoding used by the console window, namely cp850. I
could then convert this to latin1 by using
s.decode(sys.stdin.encoding).encode("latin-1").

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1233785&group_id=5470