Re: [PATCH 3/4] am: drop tty requirement for --interactive

[Jeff King <peff@peff.net>]

On Thu, May 23, 2019 at 08:44:31AM +0200, Johannes Schindelin wrote:

> >   perl test-terminal.perl sh -c '
> > 	for i in 0 1 2; do
> > 		echo $i is $(test -t $i || echo not) a tty
> > 	done
> >   ' </dev/null
> >
> > it _usually_ says "0 is a tty", but racily may say "not a tty". If you
> > put a sleep into the beginning of the shell, then it will basically
> > always lose the race and say "not".
> 
> This is just another nail in the coffin for `test-terminal.perl`, as far
> as I am concerned.

I think it's only broken for stdin, but yeah, it's not great. I think
the fact that test-terminal is not available everywhere (and thus many
people are skipping a bunch of tests) is much more damning. :)

> In the built-in `add -i` patch series, I followed a strategy where I move
> totally away from `test-terminal`, in favor of using some knobs to force
> Git into thinking that we are in a terminal.

I'm in favor of this. The current "add -i" is pretty accepting of
reading from stdin, and I think we can do that in most places. The main
use of test_terminal has been to check color and progress decisions. I'd
be just as happy to see something like this:

  int git_isatty(int fd)
  {
	static int override[3];
	static int initialized;
	if (!initialized) {
		const char *x = getenv("GIT_PRETEND_TTY");
		if (x) {
			for (; *x; x++) {
				int n = *x - '0';
				if (n > 0 && n < ARRAY_SIZE(override)
					override[n] = 1;
			}
		}
		initialized = 1;
	}
	if (fd > 0 && fd < ARRAY_SIZE(override) && override[fd])
		return 1;
	return isatty(fd);
  }

> But at the same time, I *also* remove the limitation (for most cases) of
> "read from /dev/tty", in favor of reading from stdin, and making things
> testable, and more importantly: scriptable.

As far as I know, apart from this git-am fix, the only thing that reads
from the terminal is the credential prompt. That one has to be a bit
picky, because:

  - we need to prompt from processes which have no stdio connected to
    the user (e.g., remote-curl).

  - we need to put the terminal into no-echo mode for passwords (and
    probably should bail if that fails, to be paranoid)

In the case of credentials we already have multiple mechanisms for
scripting the input (credential helpers and askpass). It would be nice
to be able to test the terminal-level code automatically, but I'm just
not sure how that would work.

-Peff