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

path.parse: result differs between Windows and macOS for Windows-style paths #9019

Closed
stelcheck opened this issue Oct 11, 2016 · 2 comments
Closed

Comments

@stelcheck
Copy link

  • Version: 6.7
  • Platform: Windows 10, macOS
  • Subsystem: path

On macOS:

> path.parse('/i/love/node')
{ root: '/', dir: '/i/love', base: 'node', ext: '', name: 'node' }
> path.parse('C:\\i\\love\\node')
{ root: '',
  dir: '',
  base: 'C:\\i\\love\\node',
  ext: '',
  name: 'C:\\i\\love\\node' }

On Windows:

> path.parse('/i/love/node')
{ root: '/', dir: '/i/love', base: 'node', ext: '', name: 'node' }
> path.parse('C:\\i\\love\\node')
{ root: 'C:\\',
  dir: 'C:\\i\\love',
  base: 'node',
  ext: '',
  name: 'node' }

While the Linux-style path is correctly and equally processed across both platform, the Windows path is not.

@Trott
Copy link
Member

Trott commented Oct 11, 2016

On OS X, the path is parsed as if it is a POSIX file name because filenames of the format C:\stuff\otherstuff are valid. Note that it's a single file in that case and the \ characters are part of the filename, not delimiters for parts of the path.

$ touch C:\\i\\love\\node
$ ls C\:\\i\\love\\node 
C:\i\love\node`
$

\ is a legitimate character in a filename (although you have to escape it to use it):

$ touch \\
$ ls \\
\
$ 

If you know you want Windows behavior, you can use path.win32.parse().

@stelcheck
Copy link
Author

Thank you for the clarification!

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