Skip to content

Git Bash replaces forward slashes with backslashes when running "node" #740

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

Closed
1 task done
seishun opened this issue Apr 21, 2016 · 7 comments
Closed
1 task done
Labels

Comments

@seishun
Copy link

seishun commented Apr 21, 2016

  • 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? 32-bit or 64-bit? Include the
    output of git version as well.

2.8.1, 64-bit

$ git --version
git version 2.8.1.windows.1
  • Which version of Windows are you running? 32-bit or 64-bit?

Windows 10, 64-bit

  • What options did you set as part of the installation? Or did you choose the
    defaults?

Defaults

  • Any other interesting things about your environment that might be related
    to the issue you're seeing?

No

Details

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

Git Bash

Compile the following C program, save it as node.exe, make a copy named node2.exe, make sure they're both in PATH.

#include <stdio.h>

int main(int argc, char* argv[]) {
    for (int i = 0; i < argc; i++) {
        puts(argv[i]);
    }
}

Then run the following:

node a/b
node.exe a/b
node2 a/b
node2.exe a/b
  • What did you expect to occur after running these commands?

Same output for all four commands, printing out the executable path and the argument as-is.

  • What actually happened instead?
Nikolai@DESKTOP-BF4LIO9 MINGW64 ~
$ node a/b
node.exe
a\b

Nikolai@DESKTOP-BF4LIO9 MINGW64 ~
$ node.exe a/b
C:\Users\Nikolai\Desktop\node.exe
a/b

Nikolai@DESKTOP-BF4LIO9 MINGW64 ~
$ node2 a/b
C:\Users\Nikolai\Desktop\node2.exe
a/b

Nikolai@DESKTOP-BF4LIO9 MINGW64 ~
$ node2.exe a/b
C:\Users\Nikolai\Desktop\node2.exe
a/b
  • If the problem was occurring with a specific repository, can you provide the
    URL to that repository to help us with testing?

N/A

@dscho
Copy link
Member

dscho commented Apr 21, 2016

This is not Git's behavior, most likely, but Bash's, and it is inherited from the MSYS2 runtime that is used by Git's Bash to emulate POSIX functionality. The reason for this behavior is that Bash expects POSIX paths (forward slashes) and when calling non-MSYS2 programs, it expects them not to be able to handle them correctly, but instead to prefer Windows' native directory separators (backslashes).

So it is very much by design what you are seeing.

If you need to pass options containing forward slashes, there are several ways to do that:

  • use Git CMD instead of Git Bash.
  • if you need to pass an option with a leading slash, you can double it to tell MSYS2 that you really want to keep that slash.
  • you can set the MSYS_NO_PATHCONV variable (use with caution), as per our known issues (yes, I know, nobody reads release notes, except the poor soul writing them).

@dscho dscho closed this as completed Apr 21, 2016
@dscho dscho added the wontfix label Apr 21, 2016
@seishun
Copy link
Author

seishun commented Apr 21, 2016

This is not Git's behavior, most likely, but Bash's, and it is inherited from the MSYS2 runtime that is used by Git's Bash to emulate POSIX functionality.

No, MSYS2 doesn't have the behavior I described.

The reason for this behavior is that Bash expects POSIX paths (forward slashes) and when calling non-MSYS2 programs, it expects them not to be able to handle them correctly, but instead to prefer Windows' native directory separators (backslashes).

The behavior I described only happens in the specific case where the program being run is "node" and not in the generic case, so you're thinking of something else.

if you need to pass an option with a leading slash, you can double it to tell MSYS2 that you really want to keep that slash.

As you can see in the example I provided, Git Bash replaces slashes regardless of their position.

@Radrik5
Copy link

Radrik5 commented Apr 21, 2016

This is probably caused by winpty: git-for-windows/build-extra@44ed99b

@dscho
Copy link
Member

dscho commented Apr 22, 2016

No, MSYS2 doesn't have the behavior I described.

@seishun are you absolutely certain? I ask because I'd like you to point me to code in winpty that converts slashes.

This is probably caused by winpty: git-for-windows/build-extra@44ed99b

@Radrik5 good conjecture. If that is the problem, using node.exe on the command-line will work around the problem. And break interactive consoles again.

@seishun
Copy link
Author

seishun commented Apr 22, 2016

@seishun are you absolutely certain? I ask because I'd like you to point me to code in winpty that converts slashes.

https://github.com/rprichard/winpty/blob/a22f493982bb9847c48200912df7a66d23750a02/src/unix-adapter/main.cc#L152 would be my guess.

@dscho
Copy link
Member

dscho commented Apr 22, 2016

@seishun
Copy link
Author

seishun commented Apr 22, 2016

Well what do you know. Indeed, vanilla winpty doesn't replace slashes in the remaining arguments. But MSYS2 provides a patched version that does. I can see the intention behind it, but it's inconsistent with how MSYS2 itself handles path conversions when running non-MSYS2 programs.

mjcheetham pushed a commit to mjcheetham/git that referenced this issue Apr 8, 2025
…updater (git-for-windows#740)

As pointed out in microsoft#739, the VS
registry settings are added only if the autoupdater feature is enabled.
This was unintentional; Just like the corresponding part in the
uninstaller, these two things should be apart.

So let's decouple the VS registry settings from the autoupdater.

Let's do that by ensuring that we put the function calls _outside_ of
the autoupdater blocks.

For good measure, we add checks to verify that both calls _were_ added,
i.e. that the expected patterns were found.

This fixes microsoft#739
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants