Repository navigation
docs: explain why path.posix.normalize does not replace windows slashes #12298
Description
Activity
If I get this right,
win32methods can process both separators, whileposixmethods don't consider\a valid separator. Compare how otherwin32methods parse paths with/properly, while theposixmethods do not this for\:const path = require('path'); const win32ToPosix = '\\win32\\to\\posix'; const posixToWin32 = '/posix/to/win32'; console.log(` ${path.posix.basename(win32ToPosix)} ${path.win32.basename(posixToWin32)} ${path.posix.dirname(win32ToPosix)} ${path.win32.dirname(posixToWin32)} ${path.posix.normalize(win32ToPosix)} ${path.win32.normalize(posixToWin32)} ${JSON.stringify(path.posix.parse(win32ToPosix))} ${JSON.stringify(path.win32.parse(posixToWin32))} ${path.posix.resolve(win32ToPosix)} ${path.win32.resolve(posixToWin32)} `);
c:\>node test.js \win32\to\posix win32 . /posix/to \win32\to\posix \posix\to\win32 {"root":"","dir":"","base":"\\win32\\to\\posix","ext":"","name":"\\win32\\to\\posix"} {"root":"/","dir":"/posix/to","base":"win32","ext":"","name":"win32"} c:\/\win32\to\posix c:\posix\to\win32 c:\>Answered. Closing, working as intended.
the docs say:
When multiple, sequential path segment separation characters are found (e.g. / on POSIX and \ on Windows), they are replaced by a single instance of the platform specific path segment separator. Trailing separators are preserved.
which is a little weird so I skimmed it with my understanding, but for postarity this this doesn't work either:
console.log('1', path.posix.normalize("\\\\some\\\\thing\\\\like\\\\this")) console.log('2', path.posix.normalize("/\\some/\\thing/\\like/\\this"))
To be fair it is vague enough to have concluded to my understanding... but on a more conceptual/abstract/module angle a conversion looking like this is intended / not available in a path manipulation library or am I missing something?
path.normalize(file).split(/[\\\/]/g).join(path.posix.sep)
Reacted by Brian Burns@Seudein On POSIX,
\\is not a path separator, so I thinkpath.posix.normalizeis right in that/\shouldn’t get contracted into a single/… what would your expected output for that be?Maybe we need a
posix2windows/windows2posixmethodsReacted by Adam Mróz, Lorenzo Dalla Vecchia, Alexander Löhr, Tatsunori Uchino, David Edey, Daniel, Milan Raj, Busticated, Tomáš Hübelbauer, Ger Roza and 11 more@refack Sorry, could you explain how those methods would behave?
posix2windowswould assume the input is a posix path and flip the/
(then do some voodoo to try and find on which drive the file exists
[or not])windows2posixwould assume that the input is windows and make sure all\are turned into/I think what @Seudein assumed was that using
path.posix.*on a windows platform will act likewindows2posix
Answered. Closing, working as intended.
@bnoordhuis I believe that if a user open an issue based on wrong assumptions that are not addressed in the docs, it should be treated as a bug in the docs.
Reacted by Brian Burns- changed the title
[-]path.posix.normalize does not replace windows slashes[/-][+]docs: explain why path.posix.normalize does not replace windows slashes[/+]on Apr 10, 2017 Reopened as a
docbugthen do some voodoo to try and find on which drive the file exists
pathmethods generally don’t actually query the file system, I would like to keep it that way.I would like to keep it that way.
I agree. Super important!
I was sarcastic, I was hoping the huge emoji and [or not] would convey that, sorry...- added a commit that references this issue
on May 7, 2017 - added a commit that references this issue
on May 19, 2017 - added a commit that references this issue
on Jun 20, 2017 - added a commit that references this issue
on Jul 11, 2017
output:
1 output should be the same as 2s thoughDocs need to explain why this is the expected output