path (extname, parse) cannot handle extension correctly for directory

[francisl]

• Version: v5.10.1
• Platform: Darwin Kernel Version 15.3.0
• Subsystem: path

On OS X and Linux its perfectly legal to use dot '.' in directory name.
Currently path.extname and path.parse handle . in directory name as a file extension.

e.g.

ext.extname('/Users/Bob.Dev')
> '.Dev'

ext.parse('/Users/John.Smith')
> { root: '/',
  dir: '/Users',
  base: 'Bob.Dev',
  ext: '.Dev',
  name: 'Bob' }

I understand that path don't do any validation. But this behavior is confusing an error prone.

[jasnell]

the challenge here is that the path module does not know that it's parsing a directory vs. a file. There's really nothing that can be done here other than perhaps documenting the limitation. /cc @nodejs/documentation

[mscdex]

This is why in general it's typically a good idea to append a trailing path separator to indicate a directory. However that won't help with parsing this path (which could possibly be viewed as a bug).

[francisl]

if you put a slash at the end, you will have the same results.

[mscdex]

Right, I noted that. It could perhaps be viewed as a bug in that case shrug.

[jasnell]

Actually, that does sound like a bug. /foo/bar/ and /foo/bar are two different paths and yet path.parse returns the same results for each. (quick test confirms that this is the way it works in v4 also... sigh... definitely should get that documented then)

[tniessen]

I think we are talking about two unrelated problems. @francisl suggests that the result of extname() and parse() is incorrect for directories, but I do not think that is true.

Currently path.extname and path.parse handle . in directory name as a file extension.

No modern file system relies on file extensions (let's not talk about 8.3) and all major operating systems support (almost) arbitrary combinations of . and other characters. File name extensions have become a rather abstract concept and I think it is reasonable not to put any meaning into extensions when parsing paths.

I cannot think of any problems related to this behavior, maybe close this issue?

@jasnell I think it is a little awkward to break with traditional path resolution, but I see you already pulled that. See man 3 basename:

Trailing '/' characters are not counted as part of the pathname.

[bnoordhuis]

I agree. The path.extname('/Users/Bob.Dev') example cannot know if Bob.Dev is a directory or a file because it doesn't (and shouldn't) query the file system, it only operates on the string.

The fact that trailing slashes are ignored might be surprising to some but it's consistent with how basename(1) and basename(3) work. It should probably be documented but that's all, pull requests welcome. I'll go ahead and close this out.

[moshfeu]

For future readers, if the path can only be folder, we can use path.basename