From: Jeff King <peff@peff.net>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] gpg-interface: reflect stderr to stderr
Date: Wed, 7 Sep 2016 04:39:47 -0400 [thread overview]
Message-ID: <20160907083947.b7q7ebe62xsr6447@sigill.intra.peff.net> (raw)
In-Reply-To: <655b42d8-baa9-e649-2b3c-5b7bfc914bc5@drmicha.warpmail.net>
On Wed, Sep 07, 2016 at 10:27:34AM +0200, Michael J Gruber wrote:
> Now, I can't reproduce C on Linux[*], so there is more involved. It
> could be that my patch just exposes a problem in our start_command()
> etc.: run-command.c contains a lot of ifdefing, so possibly quite
> different code is run on different platforms.
Maybe, though my blind guess is that it is simply that on Linux we can
open /dev/tty directly, and console-IO on Windows is a bit more
complicated.
You might also check your GPG versions; between gpg1.x and gpg2, the
passphrase input handling has been completely revamped.
> It would be great if someone with a Windows environment could help our
> efforts in resolving issue C, by checking what is actually behind[**]: I
> can't believe that capturing stderr keeps gpg from reading stdin, but
> who knows. Maybe Jeff of pipe_command() fame? I'll put him on cc.
I know nothing about Windows, but I'd be surprised if gpg is reading
from stdin, as opposed to /dev/tty. It's probably more to do with how
gpg finds the "tty" on Windows (presumably it looks at stderr for that).
Anyway, I wrote pipe_command() in such a way as to be prepared for
exactly this kind of thing, so it would be trivial to extend it to an
extra descriptor. The trouble is that run_command() doesn't understand
anything except stdin/stdout/stderr. We can open an extra pipe() before
calling run_command(), and make sure it is not marked CLOEXEC. I don't
know if there are other portability concerns, though.
-Peff
next prev parent reply other threads:[~2016-09-07 8:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-06 8:01 [PATCH] Unbreak interactive GPG prompt upon signing Johannes Schindelin
2016-09-06 12:32 ` Michael J Gruber
2016-09-06 13:13 ` [PATCH] gpg-interface: reflect stderr to stderr Michael J Gruber
2016-09-06 16:30 ` Johannes Schindelin
2016-09-06 16:42 ` Johannes Schindelin
2016-09-06 16:43 ` Johannes Schindelin
2016-09-07 8:27 ` Michael J Gruber
2016-09-07 8:39 ` Jeff King [this message]
2016-09-07 9:32 ` Michael J Gruber
2016-09-08 18:20 ` Junio C Hamano
2016-09-08 20:03 ` Jeff King
2016-09-08 21:36 ` Junio C Hamano
2016-09-12 13:39 ` Michael J Gruber
2018-10-02 13:02 ` Johannes Schindelin
2016-09-09 7:28 ` Johannes Schindelin
2016-09-06 16:39 ` [PATCH] Unbreak interactive GPG prompt upon signing Johannes Schindelin
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=20160907083947.b7q7ebe62xsr6447@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.