Re: git_getpass regression?

[Jeff King <peff@peff.net>]

On Fri, Jun 29, 2012 at 10:14:35PM +0200, Erik Faye-Lund wrote:

> > 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.
> 
> I don't get it. How can the terminal ever interpret the backspace, when
> we've already put the character it's supposed to erase in a strbuf? Sure,
> the echo can be correctly dealt with (probably with the exception of the
> border case of erasing characters from the prompt text), but once we've put
> the characters into a buffer, the terminal cannot erase it.

Because a terminal in non-raw mode is typically line-oriented, and your
program doesn't get to see any input at all until the user hits enter.

Try this on your linux box:

  strace -e read cat

You should be able to type characters and backspace erase them, all
without seeing any activity from strace. When you hit enter, you should
see the full text you typed read as a single syscall.

If the backspacing doesn't work, then there is a configuration mismatch
between what linux's tty driver expects and what your terminal emulator
is sending (the former is probably expecting ^? as the erase character,
and the latter is sending ^H).

> > If that is the case, I wonder if your 'stty erase' settings
> > do not match what your terminal emulator is sending.
> 
> I have no idea what that even means. And having to fiddle around with
> terminal settings just makes git feel cheap.

But it's not git that is broken. It's your configuration. Fixing git is
a band-aid, and other programs will still be broken. Of course, I may be
mis-diagnosing your problem. Did you try this:

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

?

> >  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.
>
> As I already said, I don't think this is the case. Inserting 0x7f in a
> strbuf does not delete the preceding char...

Of course not. Control characters should be handled by the terminal
driver, and shouldn't make it to git at all. Backspacing works perfectly
well on correctly configured systems, and it should not be git's
responsibility to care about it at all for line-oriented input (and if
we _did_ want to handle it ourselves, we should use a real terminal
library like readline or curses).

-Peff