Hi Junio,
On Mon, 23 Mar 2020, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx>
> writes:
>
> > From: Johannes Schindelin <johannes.schindelin@xxxxxx>
> >
> > In Git for Windows' SDK, we use the MSYS2 version of OpenSSH, meaning
> > that the `gpg-agent` will fail horribly when being passed a `--homedir`
> > that contains colons.
> >
> > Previously, we did pass the Windows version of the absolute path,
> > though, which starts in the drive letter followed by, you guessed it, a
> > colon.
> >
> > Let's use the same trick found elsewhere in our test suite where `$PWD`
> > is used to refer to the pseudo-Unix path (which works only within the
> > MSYS2 Bash/OpenSSH/Perl/etc, as opposed to `$(pwd)` which refers to the
> > Windows path that `git.exe` understands, too).
>
> Makes sense.
>
> Do we have a short/concise instruction, e.g. "You should use $(pwd)
> in most cases, but for such and such purposes use $PWD instead", in
> t/README for test writers, who are not familiar with the distinction
> between $(pwd) and $PWD, to help them decide which one to use in
> what situation? I see this kind of fix-ups from time to time, and
> am wondering if there is a way to reduce the need for you or J6t to
> spot and fix the new ones.
I fear that this distinction really is lost on anybody who does not have
to deal with MSYS2 on Windows.
It is subtle enough a distinction, too: whenever Bash or Perl is
concerned, we _might_ run into this issue. I say _might_ because _some_
scripts actually handle Windows paths correctly, but others don't (testing
for absolute paths by looking for a slash at the beginning would be an
example, and it gets really hairy when you slap Windows paths at the end
of `PATH`, separated by, you guessed it, a colon).
It gets even worse: you might think that you have to use `$(pwd)` when
passing the path to `git.exe` (because it is a non-MSYS2 program). But you
don't, in many cases. For example, when you call
git config my.pwd "$PWD"
it totally works (because the MSYS2 runtime on top of which Bash runs will
convert the parameters that are passed to a non-MSYS2 program when they
look like paths).
The problem solved by _this here_ patch is the opposite, of course: we are
passing a Windows path (`$(pwd)` implicitly calls `$(pwd -W)` in our test
suite on Windows) to an _MSYS2_ program: `gpg.exe`. And how would
contributors whose main development platform isn't Windows be able to
guess that `gpg.exe` is an MSYS2 program as opposed to, say, `tclsh.exe`
which is a non-MSYS2 program? They wouldn't.
In short: I am convinced that this is a subtlety in our test suite that we
cannot reasonably expect any contributors other than Windows-based ones to
get right, and I am fairly certain that we will just have to keep
monitoring the CI/PR builds for similar issues and then help the
contributors by suggesting the appropriate fixes.
Ciao,
Dscho
> Thanks.
>
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
> > ---
> > t/lib-gpg.sh | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
> > index 8d28652b729..11b83b8c24a 100755
> > --- a/t/lib-gpg.sh
> > +++ b/t/lib-gpg.sh
> > @@ -29,7 +29,7 @@ then
> > # > lib-gpg/ownertrust
> > mkdir ./gpghome &&
> > chmod 0700 ./gpghome &&
> > - GNUPGHOME="$(pwd)/gpghome" &&
> > + GNUPGHOME="$PWD/gpghome" &&
> > export GNUPGHOME &&
> > (gpgconf --kill gpg-agent >/dev/null 2>&1 || : ) &&
> > gpg --homedir "${GNUPGHOME}" 2>/dev/null --import \
>
