git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Erik Faye-Lund <kusmabite@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: git_getpass regression?
Date: Fri, 29 Jun 2012 13:39:55 -0400	[thread overview]
Message-ID: <20120629173954.GA3804@sigill.intra.peff.net> (raw)
In-Reply-To: <CABPQNSa4uvgijjGCSJDXDMqHC3UkqQKKujG3xDFqnQ13LNrKdQ@mail.gmail.com>

On Fri, Jun 29, 2012 at 12:06:31PM +0200, Erik Faye-Lund wrote:

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

Backspace shouldn't be making it to git at all; it should be handled at
the terminal input layer, because we are not putting the terminal into
raw mode. It works just fine for me here, both on the linux console and
in an xterm. What terminal are you using? Are you ssh-ing to a remote
linux box? If that is the case, I wonder if your 'stty erase' settings
do not match what your terminal emulator is sending.

If you run "stty erase ^H" and then run git, does it work?

> 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 assume you meant '\b' in (1).  I think (3) is the only sane thing,
though. Even if we handled \b, that is not what all terminals generate.
In particular, most linux terminal emulators these days will generate
DEL (aka ^? or 0x7f) on backspace. This problem needs to be solved at
the terminal layer, and I suspect is just a configuration issue in your
setup.

-Peff

  reply	other threads:[~2012-06-29 17:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-29 10:06 git_getpass regression? Erik Faye-Lund
2012-06-29 17:39 ` Jeff King [this message]
     [not found]   ` <CABPQNSZ4NhEA1CBiCBD_YNJZcnK8u=NtQ3PeDa5c0NDROPDyrQ@mail.gmail.com>
2012-06-29 20:30     ` Jeff King
2012-06-30 11:27       ` Erik Faye-Lund
2012-06-30 18:36         ` Jeff King
     [not found]           ` <CABPQNSYP6mUZb-1dCifytRxqP7_grzYzON2bjevK2zsGawb-yg@mail.gmail.com>
2012-07-03 16:28             ` Erik Faye-Lund
2012-07-03 17:11               ` Jeff King
2012-07-03 17:37                 ` Erik Faye-Lund
2012-07-18  5:53                   ` Junio C Hamano
2012-07-18 14:23                     ` Erik Faye-Lund

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120629173954.GA3804@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=kusmabite@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).