git_getpass regression?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Since 9b4b894 ("Makefile: linux has /dev/tty", 2011-12-10) we're
reading input from the terminal using strbuf_getline instead of
getpass. But at least on my linux-box, getpass treats the
backspace-key ('\b') as an actual deletion. strbuf_getline obviously
shouldn't do this, as it's a utility function. But I think as a
user-interface feature, it would be much more pleasant to be allowed
to edit the entered text ;)

I can't find anything in POSIX that standardize this behavior, but for
most text-input use-cases it's probably what the user intended.

I guess this is technically a regression, but probably not a very important one.

I think we have multiple possible solutions:
 1) Read a character at the time, and special-case '\r' to erase the
previously entered character.
 2) Post-process the strbuf to explicitly perform the erasing.
 3) Do nothing.

I'm in favor of 2) because I'm a Windows-user, and we never had the
erasing-behavior to begin with. And it's a nice feature, so we could
make the post-processing a function that can be reusable by the
Windows-version of git_terminal_prompt. We could even use it on the
plain getpass-fallback, to unify the user-experience across platforms.

We can probably also be do 1) in a reusable form by adding some kind
of on_char-callback, but it's probably something that'd end up more
confusing than than the alternative.

Thoughts?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]