-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
Inconsistent resolution of path "C:" with spawn on Windows #7215
Comments
Generally that's how DOS / Windows always worked - there are separate current working directories per-disk, so when you were not specifying some path (even if However, I agree that it might be confusing behavior in context of Node. |
Yeah, I get that |
I have same problem when scripts resolves path via npm run. You may use path.join instead of path.resolve, this solves issue. |
The `path.resolve()` function when given just a drive letter such as "C:" tries to get a drive-specific CWD, but that isn't available in cases when the process is not launched via cmd.exe and the process CWD has not been explicitly set on that drive. This change adds a fallback to the process CWD, if the process CWD happens to be on the resolved drive letter. If the process CWD is on another drive, then a drive-specific CWD cannot be resolved and defaults to the drive's root as before. Based on experimentation, the fixed behavior matches that of other similar path resolution implementations on Windows I checked: .NET's `System.IO.Path.GetFullPath()` and Python's `os.path.abspath()`. In the automated path test cases the issue doesn't occur when the tests are run normally from cmd.exe. But it did cause an assertion when running the tests from PowerShell, that is fixed by this change. Fixes: nodejs#7215
I love how that commit/PR explains and answers everything I was wondering about how and why this was happening, as well as confirming the expected behavior based on other systems (including Microsoft's own .Net!) and providing a simple fix. 👍 |
The `path.resolve()` function when given just a drive letter such as "C:" tries to get a drive-specific CWD, but that isn't available in cases when the process is not launched via cmd.exe and the process CWD has not been explicitly set on that drive. This change adds a fallback to the process CWD, if the process CWD happens to be on the resolved drive letter. If the process CWD is on another drive, then a drive-specific CWD cannot be resolved and defaults to the drive's root as before. Based on experimentation, the fixed behavior matches that of other similar path resolution implementations on Windows I checked: .NET's `System.IO.Path.GetFullPath()` and Python's `os.path.abspath()`. In the automated path test cases the issue doesn't occur when the tests are run normally from cmd.exe. But it did cause an assertion when running the tests from PowerShell, that is fixed by this change. PR-URL: #8541 Fixes: #7215 Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The `path.resolve()` function when given just a drive letter such as "C:" tries to get a drive-specific CWD, but that isn't available in cases when the process is not launched via cmd.exe and the process CWD has not been explicitly set on that drive. This change adds a fallback to the process CWD, if the process CWD happens to be on the resolved drive letter. If the process CWD is on another drive, then a drive-specific CWD cannot be resolved and defaults to the drive's root as before. Based on experimentation, the fixed behavior matches that of other similar path resolution implementations on Windows I checked: .NET's `System.IO.Path.GetFullPath()` and Python's `os.path.abspath()`. In the automated path test cases the issue doesn't occur when the tests are run normally from cmd.exe. But it did cause an assertion when running the tests from PowerShell, that is fixed by this change. PR-URL: #8541 Fixes: #7215 Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: James M Snell <jasnell@gmail.com>
On Windows, when Node is run from another Node instance using
child_process.spawn
,path.resolve("C:")
yields "C:". Callingpath.resolve("C:")
from a Node script run directly yields the current working directory. Changing directories, even to the current working directory, causes further calls topath.resolve("C:")
to yield the current working directory.This issue was originally reported by @sttk to mochajs/mocha#2242
Reproduce with the following code:
Calling
node test.js
prints the current working directory four times; callingnode wrap.js
prints "C:" once followed by the current working directory three times.The text was updated successfully, but these errors were encountered: