# git-remote-helper behavior on Windows, not recognizing blank line as terminator

3 messages from 2015-08-23 to 2015-08-25. Participants: Anish Athalye, John Keeping.
Thread: https://gitlist.dev/t/40162

## Anish Athalye, 2015-08-23 18:40

Subject: git-remote-helper behavior on Windows, not recognizing blank line as terminator
Message-ID: <CAFQ6zU1bdUwn+P3=1v2DoyVubMFz29ZuxHmnZ0pfezA-0MB+mQ@mail.gmail.com>
URL: https://gitlist.dev/e/CAFQ6zU1bdUwn%2BP3%3D1v2DoyVubMFz29ZuxHmnZ0pfezA-0MB%2BmQ%40mail.gmail.com

```
Hello,

I'm having some issues with git remote helper behavior on Windows.

According to the protocol
(https://www.kernel.org/pub/software/scm/git/docs/gitremote-helpers.html),
when doing things like listing capabilities, git expects the remote
helper to send back a blank line when it's done.

I'm having trouble having git recognize the blank line (see
https://github.com/anishathalye/git-remote-dropbox/issues/13#issuecomment-133894730
for details).

Has anyone come across this behavior before? Am I doing something
wrong, or could there be a bug in git? What's the best way to proceed?


Any help or suggestions would be greatly appreciated!

Regards,
Anish

```

## John Keeping, 2015-08-24 09:24

Subject: Re: git-remote-helper behavior on Windows, not recognizing blank line as terminator
Message-ID: <20150824092418.GF1412@serenity.lan>
URL: https://gitlist.dev/e/20150824092418.GF1412%40serenity.lan
In-Reply-To: <CAFQ6zU1bdUwn+P3=1v2DoyVubMFz29ZuxHmnZ0pfezA-0MB+mQ@mail.gmail.com>

```
On Sun, Aug 23, 2015 at 11:40:17AM -0700, Anish Athalye wrote:
> I'm having some issues with git remote helper behavior on Windows.
> 
> According to the protocol
> (https://www.kernel.org/pub/software/scm/git/docs/gitremote-helpers.html),
> when doing things like listing capabilities, git expects the remote
> helper to send back a blank line when it's done.
> 
> I'm having trouble having git recognize the blank line (see
> https://github.com/anishathalye/git-remote-dropbox/issues/13#issuecomment-133894730
> for details).
> 
> Has anyone come across this behavior before? Am I doing something
> wrong, or could there be a bug in git? What's the best way to proceed?
> 
> 
> Any help or suggestions would be greatly appreciated!

The remote-helper parser tends to be very strict about its input.  I
suspect that on Windows you are sending CRLF rather than LF, so Git sees
a line containing CR.

By default the stdio streams are probably open in "text" mode, which
will convert "\n" to "\r\n".  You probably need to reopen stdout in
binary mode to make sure the output is correct.

```

## Anish Athalye, 2015-08-25 01:52

Subject: Re: git-remote-helper behavior on Windows, not recognizing blank line as terminator
Message-ID: <304662DC-3759-4482-A06C-3286FD45457F@gmail.com>
URL: https://gitlist.dev/e/304662DC-3759-4482-A06C-3286FD45457F%40gmail.com
In-Reply-To: <20150824092418.GF1412@serenity.lan>

```
Wow, yeah, that was it. Thanks for your help!



> On Aug 24, 2015, at 2:24 AM, John Keeping <john@keeping.me.uk> wrote:
> 
>> On Sun, Aug 23, 2015 at 11:40:17AM -0700, Anish Athalye wrote:
>> I'm having some issues with git remote helper behavior on Windows.
>> 
>> According to the protocol
>> (https://www.kernel.org/pub/software/scm/git/docs/gitremote-helpers.html),
>> when doing things like listing capabilities, git expects the remote
>> helper to send back a blank line when it's done.
>> 
>> I'm having trouble having git recognize the blank line (see
>> https://github.com/anishathalye/git-remote-dropbox/issues/13#issuecomment-133894730
>> for details).
>> 
>> Has anyone come across this behavior before? Am I doing something
>> wrong, or could there be a bug in git? What's the best way to proceed?
>> 
>> 
>> Any help or suggestions would be greatly appreciated!
> 
> The remote-helper parser tends to be very strict about its input.  I
> suspect that on Windows you are sending CRLF rather than LF, so Git sees
> a line containing CR.
> 
> By default the stdio streams are probably open in "text" mode, which
> will convert "\n" to "\r\n".  You probably need to reopen stdout in
> binary mode to make sure the output is correct.

```
