Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Perl: Git.pm cannot handle arguments with spaces #1602

Closed
1 task done
ColMelvin opened this issue Mar 31, 2018 · 3 comments
Closed
1 task done

Perl: Git.pm cannot handle arguments with spaces #1602

ColMelvin opened this issue Mar 31, 2018 · 3 comments

Comments

@ColMelvin
Copy link

  • I was not able to find an open or closed issue matching what I'm seeing

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
    Git for Windows v2.10.2 32-bit
C:\>git --version --build-options
git version 2.10.2.windows.1
sizeof-long: 4
machine: x86
  • Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
    Windows 8.1 64-bit
C:\>cmd /c ver

Microsoft Windows [Version 6.3.9600]
  • What options did you set as part of the installation? Or did you choose the
    defaults?
    IIRC, mostly the defaults, but I selected to add git.exe (but not the commands themselves) to the PATH.
C:\>type "C:\Program Files (x86)\Git\etc\install-options.txt"
Path Option: Cmd
SSH Option: OpenSSH
CRLF Option: CRLFAlways
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
  • Any other interesting things about your environment that might be related
    to the issue you're seeing?

None I can think of

Details

  • Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

CMD

C:\example>perl -MGit -e "$f = q{directory with spaces}; mkdir $f; Git::command(q{init}, $f)"
  • What did you expect to occur after running these commands?

Directory is created and repository is initialized.

  • What actually happened instead?
usage: git init [-q | --quiet] [--bare] [--template=<template-directory>] [--shared[=<permissions>]] [<directory>]
init directory with spaces: command returned error: 129

It seems the code never accounted for spaces in the first place, as the FIXME will attest.

  • If the problem was occurring with a specific repository, can you provide the
    URL to that repository to help us with testing?

N/A

  • Workaround

Run in git-bash

ColMelvin added a commit to ColMelvin/git that referenced this issue Jul 5, 2018
On a native Windows build of Perl (where $^O equals 'MSWin32'), like
Strawberry or ActiveState Perl, the Git.pm module follows a unique code
path, one that alters the behavior of piped Git commands.  This special
path failed to handle spaces contained in an argument to Git.  Remove
that limitation by improving Windows command line support.

On Windows, the command line is part of the operating system; it is not
provided by a shell.  This system requires certain characters (\, ") to
be escaped (in certain cases).  The cmd.exe command prompt rests on top
of the command line and it has its own, additional escaping mechanism.
When creating pipes, an MSWin32 build of Perl will either use the system
call, CreateProcess (which takes the command line), or, if interpreted
characters are detected, the command prompt, cmd.exe.

Add a function to unescape command line arguments, one that will work
with CreateProcess or with cmd.exe, as appropriate.  This ensures any
Git command will have its arguments parsed correctly, regardless of
content.

Additionally, include tests to verify that Perl's system() behavior
remains unchanged -- notably, that the list of interpreted characters
(for selecting cmd.exe) does not change.  These tests need an MSWin32
build of Perl in the PATH to work; otherwise, they are skipped.

This change will improve commands (or batch scripts) run in CMD, where
native (MSWin32) builds of Perl are all that is available in the PATH
(unless the user opts to install Unix utils in the PATH, which is not
recommended in the Git for Windows installer).  Commands run in MSYS
Perl, which is included with Git for Windows, will not change (as it
never had a problem).

Closes: git-for-windows#1602
Signed-off-by: Chris Lindee <[email protected]>
ColMelvin added a commit to ColMelvin/git that referenced this issue Oct 15, 2018
On a native Windows build of Perl (where $^O equals 'MSWin32'), like
Strawberry or ActiveState Perl, the Git.pm module follows a unique code
path, one that alters the behavior of piped Git commands.  This special
path failed to handle spaces contained in an argument to Git.  Remove
that limitation by improving Windows command line support.

On Windows, the command line is part of the operating system; it is not
provided by a shell.  This system requires certain characters (\, ") to
be escaped (in certain cases).  The cmd.exe command prompt rests on top
of the command line and it has its own, additional escaping mechanism.
When creating pipes, an MSWin32 build of Perl will either use the system
call, CreateProcess (which takes the command line), or, if interpreted
characters are detected, the command prompt, cmd.exe.

Add a function to unescape command line arguments, one that will work
with CreateProcess or with cmd.exe, as appropriate.  This ensures any
Git command will have its arguments parsed correctly, regardless of
content.

Additionally, include tests to verify that Perl's system() behavior
remains unchanged -- notably, that the list of interpreted characters
(for selecting cmd.exe) does not change.  These tests need an MSWin32
build of Perl in the PATH to work; otherwise, they are skipped.

This change will improve commands (or batch scripts) run in CMD, where
native (MSWin32) builds of Perl are all that is available in the PATH
(unless the user opts to install Unix utils in the PATH, which is not
recommended in the Git for Windows installer).  Commands run in MSYS
Perl, which is included with Git for Windows, will not change (as it
never had a problem).

Closes: git-for-windows#1602
Signed-off-by: Chris Lindee <[email protected]>
@dscho
Copy link
Member

dscho commented Oct 13, 2019

Is this ticket still relevant?

@ColMelvin
Copy link
Author

Please clarify "relevant".

The bug still exists and it causes an issue on one of my projects in a very limited setting. Pull request #1604 addresses this issue so it should be an easy win.

@dscho
Copy link
Member

dscho commented Oct 14, 2019

Please clarify "relevant".

I meant "does this bug still exist, and is the fix being worked on?", and you provided "yes" as an answer to both.

Sorry, I had missed the update to #1604, I have left some comments there.

@dscho dscho closed this as completed Mar 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants