Repository navigation
__filename (and thus __dirname) have undefined behaviour for symlinks. #22602
Description
Activity
These values do have defined behaviour in the sense that symlinks are resolved.
It’s not clear what you are asking for here – if you think that this behaviour is wrong, then be aware that “just” changing it would be too much of a breaking change to Node.js.
If this is defined, then the API documentation should probably need to explain what that behaviour is. That is not currently the case, so as a developer I have every reason to believe
__filenameis doing completely the wrong thing and is deep-resolving a symlink it should not be deep resolving (since the value of symlinks is that their paths appear as local paths).So at the very least: please update the docs for
__filenamefor each API version in which its behaviour was already defined?Also I am well aware of the fact that nothing in developer land is "just" something, that is very much one of my own pet peeves, so you'll note that my writing does not contain a request to "just" do anything, anywhere. Basically: If the behaviour is not actually defined anywhere (except in code, which people cannot be expected to read through in order to learn what expected behaviour should be), and people have been writing code that takes advantage of undocumented behaviour, then we might be able to change its behaviour and document the now explicitly expected behaviour. If, on the other hand, the behaviour is defined already, then the docs definitely need updating, because right now as a developer I do not see any mention about what
__filenamedoes with symlinks/junctions just by reading the API docs on nodejs.org). I only see it do what appears to be the wrong thing (initially revealed through #22592 (comment))It does seem that
bashreturns the symlink name if you doecho $0in a symlinked file whilenodedoes not if you doconsole.log(__filename).$ ls -l fhqwhgads.js lrwxr-xr-x 1 trott staff 7 Nov 21 19:14 fhqwhgads.js -> test.js $ cat fhqwhgads.js console.log(__filename); $ node fhqwhgads.js /Users/trott/io.js/test.js $ ls -l fhqwhgads.sh lrwxr-xr-x 1 trott staff 7 Nov 21 19:21 fhqwhgads.sh -> test.sh $ cat fhqwhgads.sh echo $0 $ bash fhqwhgads.sh fhqwhgads.sh $
Behaves as documented.
This is the resolved absolute path of the current module file.
"Resolved" is the key, here. Its easy to not notice, or not know that the
fsAPI docs use "resolve" to describe what occurs viafs.realpath().The docs can always be improved, perhaps the OP has time to take a shot at this?
I'm already overextending myself in that respect, but maybe someone else who has more familiarity with the docs as a whole knows how to rephrase that such that it's clear to new (and long time?) users of Nodejs, there as well as in any other place where "resolve" is used to mean the absolute path.
- added a commit that references this issue
on Nov 27, 2018 - added a commit that references this issue
on Nov 28, 2018 - added a commit that references this issue
on Jan 14, 2019 - added a commit that references this issue
on Feb 11, 2019 - added a commit that references this issue
on Feb 28, 2019 The docs now say "This is the current module file's absolute path with symlinks resolved." So I think this can be closed? Comment or re-open if I'm wrong about that.
That's exactly the kind of clarification that no dev can misinterpret anymore. Thank you so much!
Not sure if I have to open a new issue, but there is exactly the same problem with
process.cwd(). It resolves symlinks if there are any and this is not documented. I believe this also should at least be clarified in the docs.Also, I think there should be a way to have the ability to find out both
cwdand__filename/__dirnamewithout symlinks resolved. Forcwd()that can be an optional argument, for__dirnamethat can be some new module variables like__dirnamePreserveSymlinks.Or maybe these things should respect
--preserve-symlinkscli option. They are not doing this at least on mac os.Reacted by brontolosone and nozwock
the
__filename(and so also__dirname) values do not report the correct paths for files and dirs that have been symlinked/junctioned, given that their behaviour is currently undefined in the API, thus not officialy having a correct behaviour in these cases.Reading through https://nodejs.org/docs/latest/api/modules.html#modules_filename the only description is that referencing the value will yield an absolute path, but the conventional absolute path for a symlink or junction is that path, as seen locally. Instead,
__filename/__dirnameyield the original resource path, which can be on completely different drives or even network shares.Given that
__filename's behaviour is currently undefined for symlinks/junctions, and that the actual behaviour that manifests is contrary to normal, expected behaviour for symlink/junction, what it's currently doing is close enough to a bug to merit fixing.__filenameto return the proper absolute path, local to the filesystem path that the file was loaded from, and,I know about the https://nodejs.org/api/cli.html#cli_preserve_symlinks flag, but this should not be the exception to the rule: not following a symlink to its original resource unless explicitly told to is the whole reason symlinks and junctions work, where code that checks for locality should not break just because symlinks are suddenly resolved to wildly remote paths ("am I running in a dir parallel to my owner?", "is this resource in a subdir of my dir?", "is this web asset being loaded from the dir that my config says is my asset dir?" etc. etc.)