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

> 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!

> 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.