WScript.GetDirectory() & WScript.GetFileName() #1399
Conversation
|
@dotnet-bot test this please |
| @@ -5,6 +5,7 @@ | |||
| JsAddRef | |||
| JsRelease | |||
| JsCreateContext | |||
| JsGetContextUrl | |||
There was a problem hiding this comment.
Exposing a new JSRT API? Is this intentional and API reviewed?
There was a problem hiding this comment.
This is the only way for a ChakraCore host to get the url I guess? Probably want to run this by @curtisman if haven't already.
There was a problem hiding this comment.
Yes new API needs to be reviewed.
In this case, I don't think a new API is necessary. ch should be able to keep track of the script file name it is running, and get the filename and directory.
It is not the "current" script file, but it should be enough for what you need.
There was a problem hiding this comment.
Alright, I'll see what I can do. I just don't know what kind of information I can get in ch regarding the caller of a WScript method.
Since there can be multiple file after various WScript.LoadScriptFile(). Maybe I can make it that the methods returns the path of the initial script (ie from argv) and that might be good enough for the time being.
|
I used the existing APIs JsSetContextData and JsGetContextData instead. |
Cellule
force-pushed
the
__dirname
branch
4 times, most recently
from
1114c05 to
f3ce76a
Compare
|
I had to save the path before lowering the case because paths are case sensitive on Unix systems. |
|
Ping |
| @@ -402,13 +405,23 @@ HRESULT CreateAndRunSerializedScript(const char* fileName, LPCSTR fileContents, | |||
| IfJsErrorFailLog(ChakraRTInterface::JsGetCurrentContext(¤t)); | |||
| IfJsErrorFailLog(ChakraRTInterface::JsSetCurrentContext(context)); | |||
|
|
|||
| // canonicalize that path name to lower case for the profile storage | |||
| // REVIEW: Assuming no utf8 characters here | |||
There was a problem hiding this comment.
how much effort would it be to handle unicode characters? this seems like it could easily bite someone in the future, particularly folks in non-english speaking regions
There was a problem hiding this comment.
Oh I see this is already a review comment from below elsewhere in the code. I suppose it hasn't been reported as a problem yet then and is okay to leave for now.
…ce when trying to execute a file that needs to refer to another file with a relative path. Will be able to do ``` WScript.LoadScriptFile(WScript.GetDirectory() + "../TestHarness.js"); ```
|
I rebased my change and remove the change for linux build script. When I'll have some more time I'll open another issue for that purpose. |
|
@Cellule any update on this issue? |
|
It's still something I want to do, but I haven't had the time to finish the implementation in the private repo and it is low priority right now |
|
@dilijev Well it is related, it doesn't fix it in the sense it doesn't change WScript.LoadScriptFile, but it adds enough functionality to achieve the desired result, ie: load a script file with relative path by using current script's path |
|
Closing this for now, there is no point really to keep it open until I find the time to fix what is left. |
Add WScript.GetFileName() and WScript.GetDirectory(), similar to __filename and __dirname in node.js.
Too often when trying to debug a file, you end up needing to either move to the script's directory or change your debugger to start in that script's directory.
Currently, there is no way to workaround this problem.
Will be able to do
Then run that script from anywhere.
Additionally, we could append the script's current directory to
WScript.LoadScriptFilereadreadbufferif it uses relative paths.This change is