Add os.exePath #1029
Add os.exePath #1029
Conversation
| size_t len = sizeof(buf); | ||
| if (js_exepath(buf, &len)) | ||
| return JS_UNDEFINED; | ||
| return JS_NewStringLen(ctx, buf, len); |
There was a problem hiding this comment.
I'm sure you aware but paths that aren't proper UTF-8 are going to get mangled.
There was a problem hiding this comment.
When could that happen? On Windows? We utf8 encode the result there...
There was a problem hiding this comment.
On Linux file paths are really just byte strings and can have any encoding. macOS's HFS+ uses UTF-8 but in NFD1 so filenames don't round-trip the way you would expect them to.
1 Not even canonical NFD, I think, so even if you pass in a path that's fully decomposed to NFD, you're still not guaranteed to get back a byte-for-byte copy.
There was a problem hiding this comment.
Let's solve that when it arises ;-)
There was a problem hiding this comment.
On Linux file paths are really just byte strings and can have any encoding. macOS's HFS+ uses UTF-8 but in NFD1 so filenames don't round-trip the way you would expect them to.
1 Not even canonical NFD, I think, so even if you pass in a path that's fully decomposed to NFD, you're still not guaranteed to get back a byte-for-byte copy.
Yes filenames on macOS are converted to a form where accented letters are decomposed into the base character followed by the modifier codepoints. My understanding is it simplifies the case independent filename matching for file systems that support it. This becomes a problem when trying to match filenames returned by opendir/readdir with known filenames, and when trying to detect if 2 pathnames refer to the same file, which can fail for so many other reasons that nobody sane should try and rely on pathnames for this.
It gets the current executable path. Implementation lifted from libuv. Currently implemented for the following platforms: - Linux - macOS - Windows
It gets the current executable path. Implementation lifted from libuv. Currently implemented for the following platforms: