On Tue, Feb 14, 2012 at 02:35:23PM -0800, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > export SSH_ASKPASS=whatever
> >
> > # this will try the terminal first, then SSH_ASKPASS, because it is
> > # ssh doing the asking
> > git push ssh://example.com/repo.git
>
> Sorry, you lost me here. Does "ssh example.com" consult the terminal
> first and then fall back to SSH_ASKPASS environment variable?
Yes. Try:
SSH_ASKPASS=cat ssh example.com
where cat is any program whose running you could detect (in this case,
because cat will complain to stderr about not being able to open its
argument). And "example.com" must be something that you can actually
make an ssh connection to.
Compare with:
SSH_ASKPASS=cat setsid ssh example.com
which will realize it has no controlling tty, and fallback to
SSH_ASKPASS.
I actually find the behavior slightly annoying (because sometimes you do
have a controlling terminal, but it is not accessible or obvious to the
user). But I think it's important to be consistent, and provide
GIT_ASKPASS for people who really want to say "no, don't even bother
with the terminal".
> I was under the impression that SSH_ASKPASS was to either give hands-free
> access to the keychain or give GUI experience so that people do not have
> to type from their terminals...
Not exactly. It's useful in two situations (in my experience):
1. A GUI program spawns an ssh tunnel, and there is no tty on which to
prompt the user.
2. Populating an ssh-agent via ssh-add during the user's login
sequence.
It doesn't work to give a GUI experience to creating a remote terminal
session, since if you have a terminal, it will always prefer to prompt
on the terminal.
-Peff
--
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