threads / bug / 53049

GIT_ASKPASS absolute path detection bug on Windows

Subject: GIT_ASKPASS absolute path detection bug on Windows

## tl;dr

9 messages between Mar 21, 2020 and Mar 23, 2020.

replies: 8people: 4as markdown or json

András Kucsma· Mar 21, 2020, 11:42 UTC · lore
Hi All,

I believe to have found an issue regarding properly executing the GIT_ASKPASS binary. I'm using Windows Server 2019, with git 2.21.0 installed using cygwin.

## To reproduce:

Assume you have the askpass binary at C:\askpass.bat. In CMD the following commands reproduce the issue:

C:\> set GIT_ASKPASS=C:\askpass.bat C:\> git clone https://<private_repository>.git Cloning into '<private_repository>'... error: cannot run C:\askpass.bat: No such file or directory [... proceeds to interactively ask for username and password ...]

On the other hand, if we change the GIT_ASKPASS environment variable slightly, so that there is a forward slash (/) instead of a backslash (\), things work as expected:

C:\> set GIT_ASKPASS=C:/askpass.bat C:\> git clone https://<private_repository>.git Cloning into '<private_repository>'... [... success ...]

## Some context:

The source of the problem, is that if git doesn't find a forward slash anywhere in the path, it assumes it is not a real path and has to look for the binary using the PATH environment variable. See in prepare_cmd(): https://github.com/git/git/blob/98cedd0233e/run-command.c#L429-L439

You can see that the "cannot run" error message is printed here, just after prepare_cmd() returned -1: https://github.com/git/git/blob/98cedd0233e/run-command.c#L749-L753

I believe this was introduced in late 2018 around git v2.19.2, although I did not actually bisect the issue: https://github.com/git/git/commit/321fd823897#diff-7577a5178f8cdc0f719e580577889f04R401-R415

I hope I'm sharing this bug at the right forum. Please direct me to the proper place if not.

Thank you, Andras

Torsten Bögershausen· Mar 22, 2020, 07:31 UTC · re: András Kucsma · lore

Re: GIT_ASKPASS absolute path detection bug on Windows

On Sat, Mar 21, 2020 at 12:42:50PM +0100, András Kucsma wrote:
Show 45 quoted lines
> Hi All,
>
> I believe to have found an issue regarding properly executing the
> GIT_ASKPASS binary. I'm using Windows Server 2019, with git 2.21.0
> installed using cygwin.
>
> ## To reproduce:
>
> Assume you have the askpass binary at C:\askpass.bat. In CMD the
> following commands reproduce the issue:
>
> C:\> set GIT_ASKPASS=C:\askpass.bat
> C:\> git clone https://<private_repository>.git
> Cloning into '<private_repository>'...
> error: cannot run C:\askpass.bat: No such file or directory
> [... proceeds to interactively ask for username and password ...]
>
> On the other hand, if we change the GIT_ASKPASS environment variable
> slightly, so that there is a forward slash (/) instead of a backslash
> (\), things work as expected:
>
> C:\> set GIT_ASKPASS=C:/askpass.bat
> C:\> git clone https://<private_repository>.git
> Cloning into '<private_repository>'...
> [... success ...]
>
> ## Some context:
>
> The source of the problem, is that if git doesn't find a forward slash
> anywhere in the path, it assumes it is not a real path and has to look
> for the binary using the PATH environment variable. See in
> prepare_cmd():
> https://github.com/git/git/blob/98cedd0233e/run-command.c#L429-L439
>
> You can see that the "cannot run" error message is printed here, just
> after prepare_cmd() returned -1:
> https://github.com/git/git/blob/98cedd0233e/run-command.c#L749-L753
>
> I believe this was introduced in late 2018 around git v2.19.2,
> although I did not actually bisect the issue:
> https://github.com/git/git/commit/321fd823897#diff-7577a5178f8cdc0f719e580577889f04R401-R415
>
>
> I hope I'm sharing this bug at the right forum. Please direct me to
> the proper place if not.

Yes, you came to the rigth place. Thanks for the report and the detailed analysis.

A quick fix, and a begin of a patch, could be to use has_dos_drive_prefix() which will look for C: and will therefore even work with C:\

	/*
	 * If there are no '/' characters in the command then perform a path
	 * lookup and use the resolved path as the command to exec.  If there
	 * are '/' characters, we have exec attempt to invoke the command
	 * directly.
	 */
	if ((!strchr(out->argv[1], '/')) ||
	    (has_dos_drive_prefix(out->argv[1]))) {
		char *program = locate_in_PATH(out->argv[1]);
[]

If you want to play around with the code a little bit, and send us a "git diff", we can convert that into a patch.

Wellcome to the Git community.
>
> Thank you,
> Andras
András Kucsma· Mar 22, 2020, 11:44 UTC · re: Torsten Bögershausen · lore

Re: GIT_ASKPASS absolute path detection bug on Windows

On Sun, Mar 22, 2020 at 8:31 AM Torsten Bögershausen <tboegi@web.de> wrote:
Show 74 quoted lines
>
> On Sat, Mar 21, 2020 at 12:42:50PM +0100, András Kucsma wrote:
> > Hi All,
> >
> > I believe to have found an issue regarding properly executing the
> > GIT_ASKPASS binary. I'm using Windows Server 2019, with git 2.21.0
> > installed using cygwin.
> >
> > ## To reproduce:
> >
> > Assume you have the askpass binary at C:\askpass.bat. In CMD the
> > following commands reproduce the issue:
> >
> > C:\> set GIT_ASKPASS=C:\askpass.bat
> > C:\> git clone https://<private_repository>.git
> > Cloning into '<private_repository>'...
> > error: cannot run C:\askpass.bat: No such file or directory
> > [... proceeds to interactively ask for username and password ...]
> >
> > On the other hand, if we change the GIT_ASKPASS environment variable
> > slightly, so that there is a forward slash (/) instead of a backslash
> > (\), things work as expected:
> >
> > C:\> set GIT_ASKPASS=C:/askpass.bat
> > C:\> git clone https://<private_repository>.git
> > Cloning into '<private_repository>'...
> > [... success ...]
> >
> > ## Some context:
> >
> > The source of the problem, is that if git doesn't find a forward slash
> > anywhere in the path, it assumes it is not a real path and has to look
> > for the binary using the PATH environment variable. See in
> > prepare_cmd():
> > https://github.com/git/git/blob/98cedd0233e/run-command.c#L429-L439
> >
> > You can see that the "cannot run" error message is printed here, just
> > after prepare_cmd() returned -1:
> > https://github.com/git/git/blob/98cedd0233e/run-command.c#L749-L753
> >
> > I believe this was introduced in late 2018 around git v2.19.2,
> > although I did not actually bisect the issue:
> > https://github.com/git/git/commit/321fd823897#diff-7577a5178f8cdc0f719e580577889f04R401-R415
> >
> >
> > I hope I'm sharing this bug at the right forum. Please direct me to
> > the proper place if not.
>
> Yes, you came to the rigth place.
> Thanks for the report and the detailed analysis.
>
> A quick fix, and a begin of a patch, could be to use
> has_dos_drive_prefix() which will look for C: and will therefore even work
> with C:\
>
>         /*
>          * If there are no '/' characters in the command then perform a path
>          * lookup and use the resolved path as the command to exec.  If there
>          * are '/' characters, we have exec attempt to invoke the command
>          * directly.
>          */
>         if ((!strchr(out->argv[1], '/')) ||
>             (has_dos_drive_prefix(out->argv[1]))) {
>                 char *program = locate_in_PATH(out->argv[1]);
> []
>
> If you want to play around with the code a little bit, and send us a "git diff",
> we can convert that into a patch.
>
> Wellcome to the Git community.
>
> >
> > Thank you,
> > Andras
Thanks Torsten!

I believe it is not enough to test only for the drive specifier, as GIT_ASKPASS has to work with relative paths as well: C:\SomeDirectory> set GIT_ASKPASS=.\SomeOtherDirectory\askpass.bat C:\SomeDirectory> git clone https://<some_private_repository>.git

My proposal patch is to take advantage of find_last_dir_sep function's OS specific directory separator knowledge. I posted the diff below, which is also available on github here: https://github.com/git/git/compare/maint...r0mai:fix-prepare_cmd-windows-maint

diff --git a/run-command.c b/run-command.c
index f5e1149f9b..9fcc12ebf9 100644
--- a/run-command.c
+++ b/run-command.c
@@ -421,12 +421,12 @@ static int prepare_cmd(struct argv_array *out,
const struct child_process *cmd)
     }

     /*
-     * If there are no '/' characters in the command then perform a path
-     * lookup and use the resolved path as the command to exec.  If there
-     * are '/' characters, we have exec attempt to invoke the command
-     * directly.
+     * If there are no dir separator characters in the command then perform
+     * a path lookup and use the resolved path as the command to exec. If
+     * there are dir separator characters, we have exec attempt to invoke
+     * the command directly.
      */
-    if (!strchr(out->argv[1], '/')) {
+    if (find_last_dir_sep(out->argv[1]) == NULL) {
         char *program = locate_in_PATH(out->argv[1]);
         if (program) {
             free((char *)out->argv[1]);
brian m. carlson· Mar 22, 2020, 16:59 UTC · re: András Kucsma · lore

Re: GIT_ASKPASS absolute path detection bug on Windows

On 2020-03-22 at 11:44:33, András Kucsma wrote:
Show 26 quoted lines
> My proposal patch is to take advantage of find_last_dir_sep function's
> OS specific directory separator knowledge.
> I posted the diff below, which is also available on github here:
> https://github.com/git/git/compare/maint...r0mai:fix-prepare_cmd-windows-maint
> 
> diff --git a/run-command.c b/run-command.c
> index f5e1149f9b..9fcc12ebf9 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -421,12 +421,12 @@ static int prepare_cmd(struct argv_array *out,
> const struct child_process *cmd)
>      }
> 
>      /*
> -     * If there are no '/' characters in the command then perform a path
> -     * lookup and use the resolved path as the command to exec.  If there
> -     * are '/' characters, we have exec attempt to invoke the command
> -     * directly.
> +     * If there are no dir separator characters in the command then perform
> +     * a path lookup and use the resolved path as the command to exec. If
> +     * there are dir separator characters, we have exec attempt to invoke
> +     * the command directly.
>       */
> -    if (!strchr(out->argv[1], '/')) {
> +    if (find_last_dir_sep(out->argv[1]) == NULL) {
>          char *program = locate_in_PATH(out->argv[1]);

This function (locate_in_PATH) specifically says it is not to be used on Windows because it doesn't work properly there due to file extensions. I'm pretty sure a proper solution would involve touching that as well, although your solution does indeed fix the issue you reported. That function also uses a colon-separated PATH, which I'm not sure will work in all cases on Windows (although maybe it will).

From looking at this earlier, I think the problem here is that we're trying to use the Unix codepaths (on Cygwin) and then expecting those to handle Windows-style paths, which they aren't intended to do. This is likely one of many problems on Cygwin.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Torsten Bögershausen· Mar 22, 2020, 18:07 UTC · re: brian m. carlson · lore

Re: GIT_ASKPASS absolute path detection bug on Windows

On Sun, Mar 22, 2020 at 04:59:15PM +0000, brian m. carlson wrote:
Show 30 quoted lines
> On 2020-03-22 at 11:44:33, András Kucsma wrote:
> > My proposal patch is to take advantage of find_last_dir_sep function's
> > OS specific directory separator knowledge.
> > I posted the diff below, which is also available on github here:
> > https://github.com/git/git/compare/maint...r0mai:fix-prepare_cmd-windows-maint
> >
> > diff --git a/run-command.c b/run-command.c
> > index f5e1149f9b..9fcc12ebf9 100644
> > --- a/run-command.c
> > +++ b/run-command.c
> > @@ -421,12 +421,12 @@ static int prepare_cmd(struct argv_array *out,
> > const struct child_process *cmd)
> >      }
> >
> >      /*
> > -     * If there are no '/' characters in the command then perform a path
> > -     * lookup and use the resolved path as the command to exec.  If there
> > -     * are '/' characters, we have exec attempt to invoke the command
> > -     * directly.
> > +     * If there are no dir separator characters in the command then perform
> > +     * a path lookup and use the resolved path as the command to exec. If
> > +     * there are dir separator characters, we have exec attempt to invoke
> > +     * the command directly.
> >       */
> > -    if (!strchr(out->argv[1], '/')) {
> > +    if (find_last_dir_sep(out->argv[1]) == NULL) {
> >          char *program = locate_in_PATH(out->argv[1]);
>
> This function (locate_in_PATH) specifically says it is not to be used on
> Windows because it doesn't work properly there due to file extensions.

My reading is, that it dows work if you specify "foo.exe", "foo.bat". And when you specify "foo" it may use "foo.exe", but there may be a shell script called "foo". But I may be wrong.

Show 9 quoted lines
> I'm pretty sure a proper solution would involve touching that as well,
> although your solution does indeed fix the issue you reported.  That
> function also uses a colon-separated PATH, which I'm not sure will work
> in all cases on Windows (although maybe it will).
>
> From looking at this earlier, I think the problem here is that we're
> trying to use the Unix codepaths (on Cygwin) and then expecting those to
> handle Windows-style paths, which they aren't intended to do.  This is
> likely one of many problems on Cygwin.

Yes and no. C:/MyTool.BAT is a valid Windows file name even under Windows. Cygwin preferres /cygdrive/cMyTool.BAT Git under Cygwin should handle C:/MyTool.BAT correctly, and to my understanding it does.

Some interesting reading can be found here: https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats#path-normalization

> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204
András Kucsma· Mar 22, 2020, 18:33 UTC · re: Torsten Bögershausen · lore

Re: GIT_ASKPASS absolute path detection bug on Windows

On Sun, Mar 22, 2020 at 7:07 PM Torsten Bögershausen <tboegi@web.de> wrote:
Show 8 quoted lines
> On Sun, Mar 22, 2020 at 04:59:15PM +0000, brian m. carlson wrote:
> > This function (locate_in_PATH) specifically says it is not to be used on
> > Windows because it doesn't work properly there due to file extensions.
>
> My reading is, that it dows work if you specify "foo.exe", "foo.bat".
> And when you specify "foo" it may use "foo.exe", but there may be
> a shell script called "foo".
> But I may be wrong.

Other than the extension appending, I believe the other difference is that on native Windows the PATH separator is ';' (semi-colon). In cygwin and mingw, PATH is translated to use ':' (colon).

Show 17 quoted lines
>
> > I'm pretty sure a proper solution would involve touching that as well,
> > although your solution does indeed fix the issue you reported.  That
> > function also uses a colon-separated PATH, which I'm not sure will work
> > in all cases on Windows (although maybe it will).
> >
> > From looking at this earlier, I think the problem here is that we're
> > trying to use the Unix codepaths (on Cygwin) and then expecting those to
> > handle Windows-style paths, which they aren't intended to do.  This is
> > likely one of many problems on Cygwin.
>
> Yes and no.
> C:/MyTool.BAT is a valid Windows file name even under Windows.
> Cygwin preferres /cygdrive/cMyTool.BAT
> Git under Cygwin should handle C:/MyTool.BAT correctly, and to my
> understanding it does.
>

Indeed, the Cygwin shell tools recognize C:/Users style and even C:\\Users style paths as well.

Looking at the code a bit more, I feel like git is only supposed to work within a Unix compatibility layer (like Cygwin or Mingw shell) on Windows. Beside the PATH and directory separator characters, the code makes other Unix like assumptions, for example that /bin/sh (a.k.a. SHELL_PATH), or /dev/null exists. If native Windows support is a goal, I'm happy to help a bit to improve the situation, but I wouldn't want to swim against the current. Note that other than this GIT_ASKPASS related edge case, cygwin built git has been working in this environment for me.

Achim Gratz· Mar 22, 2020, 18:59 UTC · re: Torsten Bögershausen · lore

Re: GIT_ASKPASS absolute path detection bug on Windows

Torsten Bögershausen writes:
> C:/MyTool.BAT is a valid Windows file name even under Windows.
Not all Windows programs handle that correctly, though.
> Cygwin preferres /cygdrive/cMyTool.BAT

The /cygdrive prefix can be changed, however. If you want to be independent of such vagaries, use /proc/cygdrive instead (use cygpath -U instead of cygpath -u).

> Git under Cygwin should handle C:/MyTool.BAT correctly, and to my
> understanding it does.

Yes, but there is always the possiblity of some shell script somewhere missing that boat. You are best off normalizing to POSIX conventions as early as possible and keep it that way until you hand off to a Windows program.

Regards, Achim.

-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Torsten Bögershausen· Mar 23, 2020, 16:58 UTC · re: András Kucsma · lore

Re: GIT_ASKPASS absolute path detection bug on Windows

On Sun, Mar 22, 2020 at 12:44:33PM +0100, András Kucsma wrote:
Show 111 quoted lines
> On Sun, Mar 22, 2020 at 8:31 AM Torsten Bögershausen <tboegi@web.de> wrote:
> >
> > On Sat, Mar 21, 2020 at 12:42:50PM +0100, András Kucsma wrote:
> > > Hi All,
> > >
> > > I believe to have found an issue regarding properly executing the
> > > GIT_ASKPASS binary. I'm using Windows Server 2019, with git 2.21.0
> > > installed using cygwin.
> > >
> > > ## To reproduce:
> > >
> > > Assume you have the askpass binary at C:\askpass.bat. In CMD the
> > > following commands reproduce the issue:
> > >
> > > C:\> set GIT_ASKPASS=C:\askpass.bat
> > > C:\> git clone https://<private_repository>.git
> > > Cloning into '<private_repository>'...
> > > error: cannot run C:\askpass.bat: No such file or directory
> > > [... proceeds to interactively ask for username and password ...]
> > >
> > > On the other hand, if we change the GIT_ASKPASS environment variable
> > > slightly, so that there is a forward slash (/) instead of a backslash
> > > (\), things work as expected:
> > >
> > > C:\> set GIT_ASKPASS=C:/askpass.bat
> > > C:\> git clone https://<private_repository>.git
> > > Cloning into '<private_repository>'...
> > > [... success ...]
> > >
> > > ## Some context:
> > >
> > > The source of the problem, is that if git doesn't find a forward slash
> > > anywhere in the path, it assumes it is not a real path and has to look
> > > for the binary using the PATH environment variable. See in
> > > prepare_cmd():
> > > https://github.com/git/git/blob/98cedd0233e/run-command.c#L429-L439
> > >
> > > You can see that the "cannot run" error message is printed here, just
> > > after prepare_cmd() returned -1:
> > > https://github.com/git/git/blob/98cedd0233e/run-command.c#L749-L753
> > >
> > > I believe this was introduced in late 2018 around git v2.19.2,
> > > although I did not actually bisect the issue:
> > > https://github.com/git/git/commit/321fd823897#diff-7577a5178f8cdc0f719e580577889f04R401-R415
> > >
> > >
> > > I hope I'm sharing this bug at the right forum. Please direct me to
> > > the proper place if not.
> >
> > Yes, you came to the rigth place.
> > Thanks for the report and the detailed analysis.
> >
> > A quick fix, and a begin of a patch, could be to use
> > has_dos_drive_prefix() which will look for C: and will therefore even work
> > with C:\
> >
> >         /*
> >          * If there are no '/' characters in the command then perform a path
> >          * lookup and use the resolved path as the command to exec.  If there
> >          * are '/' characters, we have exec attempt to invoke the command
> >          * directly.
> >          */
> >         if ((!strchr(out->argv[1], '/')) ||
> >             (has_dos_drive_prefix(out->argv[1]))) {
> >                 char *program = locate_in_PATH(out->argv[1]);
> > []
> >
> > If you want to play around with the code a little bit, and send us a "git diff",
> > we can convert that into a patch.
> >
> > Wellcome to the Git community.
> >
> > >
> > > Thank you,
> > > Andras
>
> Thanks Torsten!
>
> I believe it is not enough to test only for the drive specifier, as
> GIT_ASKPASS has to work with relative paths as well:
> C:\SomeDirectory> set GIT_ASKPASS=.\SomeOtherDirectory\askpass.bat
> C:\SomeDirectory> git clone https://<some_private_repository>.git
>
> My proposal patch is to take advantage of find_last_dir_sep function's
> OS specific directory separator knowledge.
> I posted the diff below, which is also available on github here:
> https://github.com/git/git/compare/maint...r0mai:fix-prepare_cmd-windows-maint
>
> diff --git a/run-command.c b/run-command.c
> index f5e1149f9b..9fcc12ebf9 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -421,12 +421,12 @@ static int prepare_cmd(struct argv_array *out,
> const struct child_process *cmd)
>      }
>
>      /*
> -     * If there are no '/' characters in the command then perform a path
> -     * lookup and use the resolved path as the command to exec.  If there
> -     * are '/' characters, we have exec attempt to invoke the command
> -     * directly.
> +     * If there are no dir separator characters in the command then perform
> +     * a path lookup and use the resolved path as the command to exec. If
> +     * there are dir separator characters, we have exec attempt to invoke
> +     * the command directly.
>       */
> -    if (!strchr(out->argv[1], '/')) {
> +    if (find_last_dir_sep(out->argv[1]) == NULL) {
>          char *program = locate_in_PATH(out->argv[1]);
>          if (program) {
>              free((char *)out->argv[1]);

András, The patch looks good to me. If you want, you can submit it here to the list, either with git send-mail

or may be
https://gitgitgadget.github.io/
And please don't forget to sign-off the patch
András Kucsma· Mar 23, 2020, 18:13 UTC · re: Torsten Bögershausen · lore

Re: GIT_ASKPASS absolute path detection bug on Windows

Thanks Torsten! I submitted it as https://github.com/gitgitgadget/git/pull/587 I believe someone has to /allow me to be able to submit it.

On Mon, Mar 23, 2020 at 5:58 PM Torsten Bögershausen <tboegi@web.de> wrote:
Show 124 quoted lines
>
> On Sun, Mar 22, 2020 at 12:44:33PM +0100, András Kucsma wrote:
> > On Sun, Mar 22, 2020 at 8:31 AM Torsten Bögershausen <tboegi@web.de> wrote:
> > >
> > > On Sat, Mar 21, 2020 at 12:42:50PM +0100, András Kucsma wrote:
> > > > Hi All,
> > > >
> > > > I believe to have found an issue regarding properly executing the
> > > > GIT_ASKPASS binary. I'm using Windows Server 2019, with git 2.21.0
> > > > installed using cygwin.
> > > >
> > > > ## To reproduce:
> > > >
> > > > Assume you have the askpass binary at C:\askpass.bat. In CMD the
> > > > following commands reproduce the issue:
> > > >
> > > > C:\> set GIT_ASKPASS=C:\askpass.bat
> > > > C:\> git clone https://<private_repository>.git
> > > > Cloning into '<private_repository>'...
> > > > error: cannot run C:\askpass.bat: No such file or directory
> > > > [... proceeds to interactively ask for username and password ...]
> > > >
> > > > On the other hand, if we change the GIT_ASKPASS environment variable
> > > > slightly, so that there is a forward slash (/) instead of a backslash
> > > > (\), things work as expected:
> > > >
> > > > C:\> set GIT_ASKPASS=C:/askpass.bat
> > > > C:\> git clone https://<private_repository>.git
> > > > Cloning into '<private_repository>'...
> > > > [... success ...]
> > > >
> > > > ## Some context:
> > > >
> > > > The source of the problem, is that if git doesn't find a forward slash
> > > > anywhere in the path, it assumes it is not a real path and has to look
> > > > for the binary using the PATH environment variable. See in
> > > > prepare_cmd():
> > > > https://github.com/git/git/blob/98cedd0233e/run-command.c#L429-L439
> > > >
> > > > You can see that the "cannot run" error message is printed here, just
> > > > after prepare_cmd() returned -1:
> > > > https://github.com/git/git/blob/98cedd0233e/run-command.c#L749-L753
> > > >
> > > > I believe this was introduced in late 2018 around git v2.19.2,
> > > > although I did not actually bisect the issue:
> > > > https://github.com/git/git/commit/321fd823897#diff-7577a5178f8cdc0f719e580577889f04R401-R415
> > > >
> > > >
> > > > I hope I'm sharing this bug at the right forum. Please direct me to
> > > > the proper place if not.
> > >
> > > Yes, you came to the rigth place.
> > > Thanks for the report and the detailed analysis.
> > >
> > > A quick fix, and a begin of a patch, could be to use
> > > has_dos_drive_prefix() which will look for C: and will therefore even work
> > > with C:\
> > >
> > >         /*
> > >          * If there are no '/' characters in the command then perform a path
> > >          * lookup and use the resolved path as the command to exec.  If there
> > >          * are '/' characters, we have exec attempt to invoke the command
> > >          * directly.
> > >          */
> > >         if ((!strchr(out->argv[1], '/')) ||
> > >             (has_dos_drive_prefix(out->argv[1]))) {
> > >                 char *program = locate_in_PATH(out->argv[1]);
> > > []
> > >
> > > If you want to play around with the code a little bit, and send us a "git diff",
> > > we can convert that into a patch.
> > >
> > > Wellcome to the Git community.
> > >
> > > >
> > > > Thank you,
> > > > Andras
> >
> > Thanks Torsten!
> >
> > I believe it is not enough to test only for the drive specifier, as
> > GIT_ASKPASS has to work with relative paths as well:
> > C:\SomeDirectory> set GIT_ASKPASS=.\SomeOtherDirectory\askpass.bat
> > C:\SomeDirectory> git clone https://<some_private_repository>.git
> >
> > My proposal patch is to take advantage of find_last_dir_sep function's
> > OS specific directory separator knowledge.
> > I posted the diff below, which is also available on github here:
> > https://github.com/git/git/compare/maint...r0mai:fix-prepare_cmd-windows-maint
> >
> > diff --git a/run-command.c b/run-command.c
> > index f5e1149f9b..9fcc12ebf9 100644
> > --- a/run-command.c
> > +++ b/run-command.c
> > @@ -421,12 +421,12 @@ static int prepare_cmd(struct argv_array *out,
> > const struct child_process *cmd)
> >      }
> >
> >      /*
> > -     * If there are no '/' characters in the command then perform a path
> > -     * lookup and use the resolved path as the command to exec.  If there
> > -     * are '/' characters, we have exec attempt to invoke the command
> > -     * directly.
> > +     * If there are no dir separator characters in the command then perform
> > +     * a path lookup and use the resolved path as the command to exec. If
> > +     * there are dir separator characters, we have exec attempt to invoke
> > +     * the command directly.
> >       */
> > -    if (!strchr(out->argv[1], '/')) {
> > +    if (find_last_dir_sep(out->argv[1]) == NULL) {
> >          char *program = locate_in_PATH(out->argv[1]);
> >          if (program) {
> >              free((char *)out->argv[1]);
>
> András,
> The patch looks good to me.
> If you want, you can submit it here to the list,
> either with git send-mail
>
> or may be
>
> https://gitgitgadget.github.io/
>
> And please don't forget to sign-off the patch

← back to recent threads