Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

print(package.path) != %LUA_PATH% ( 1.38.0 on Win10, 64bit ) #136

Closed
hemmerling opened this issue Jun 22, 2021 · 10 comments
Closed

print(package.path) != %LUA_PATH% ( 1.38.0 on Win10, 64bit ) #136

hemmerling opened this issue Jun 22, 2021 · 10 comments

Comments

@hemmerling
Copy link

@hemmerling hemmerling commented Jun 22, 2021

When executing a LUA script.
print(package.path)
should print the contents of the environment variable LUA_PATH. On Win10pro, 64-bit, this should be - on my Win10 system, my choice for LUA_PATH -
./;.\?.lua;.\?\init.lua;C:\Users\Administrator\AppData\Roaming\luarocks\share\lua\5.3\?.lua;C:\Users\Administrator\AppData\Roaming\luarocks\share\lua\5.3\?\init.lua;
By this, the LUA script may process
require("module")
statements, both of local modules and of modules installed by LuaRocks.
This is true on my computer when running LUA scripts by POWERSHELL or CMD shell, or if I use some other VSC LUA debugger plugins.
( Some other VSC LUA debuggers add some extra string data to this string, by this a LUA script may find out that it is running in VSC and not in a shell.. ).


Indeed, VisualStudioCode with "lua-debug 1.38.0" prints the LUA style path to the current working directory, with "/?.lua" added.
Example:
C:\Users\Administrator\MyLuaWorkingDirectory/?.lua
, while executing the LUA script
C:\Users\Administrator\MyLuaWorkingDirectory/test.lua

ISSUE:
By this, VisualStudioCode with "lua-debug 1.38.0" fails to process
require("module")
statements, if the module was installed by LuaRocks.


Just by special trick to add
./;
to the LUA_PATH string,
I am able to process
require("module")
statements, if the module is a local module, situated in the LUA working directory where the LUA script is situated which "requires" a module. Please note that "/" and not "" and neither "\" is needed so that this trick works.

WORKAROUND, but no solution:
if I add the statement
package.path = package.path .. ";C:\\Users\\Administrator\\AppData\\Roaming\\luarocks\\share\\lua\\5.3\\?.lua"
to my code,
require("module")
statements are processed properly also for modules installed by LuaRocks.

FIX NEEDED:
Please implement that
print(package.path)
prints the contents of the environment variable LUA_PATH

@hemmerling hemmerling changed the title print(package.path) != "LUA_PATH" ( 1.38.0 on Win10 ) print(package.path) != %LUA_PATH% ( 1.38.0 on Win10 ) Jun 22, 2021
@actboy168
Copy link
Owner

@actboy168 actboy168 commented Jun 22, 2021

Add path in launch.json, it can specify package.path.

@hemmerling hemmerling changed the title print(package.path) != %LUA_PATH% ( 1.38.0 on Win10 ) print(package.path) != %LUA_PATH% ( 1.38.0 on Win10, 64bit ) Jun 22, 2021
@hemmerling
Copy link
Author

@hemmerling hemmerling commented Jun 22, 2021

  1. Thanks for another workaround, might you specify a working example of launch.json?
  2. But it would be great to fix this, without help of launch.json anyhow, ok ?! :-). Some other VSC debuggers do it right.

I need your debug plugin, as the VSC LuaUnit plugin depends on it...

@actboy168
Copy link
Owner

@actboy168 actboy168 commented Jun 22, 2021

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lua",
            "request": "launch",
            "name": "debug",
            "program": "${workspaceFolder}/test.lua",
            "path": "${env:LUA_PATH}
        }
    ]
}

@hemmerling
Copy link
Author

@hemmerling hemmerling commented Jun 22, 2021

Thanks, it works!

But as using such launch.json files is not comfortable, please fix your code too, please.

@actboy168
Copy link
Owner

@actboy168 actboy168 commented Jun 23, 2021

Nothing needs to be fixed, the design is just that.

@hemmerling
Copy link
Author

@hemmerling hemmerling commented Jul 5, 2021

On Windows, with LuaDebug 1.40.0,
Your fix with "path" works by the VSC debug option "Debug (Script)".

With the JSON debugging configuration "Debug Current Script", this does not work.
Maybe you could upgrade your launch.json file
a) for a valid "Debug Current Script" configuration
b) for all configurations, attach the path fix, which works well.

But if I change the debugger or change the file to be debugged, its most easy to start with a new launch.json file, and so I don´t like to fix it each time...

@actboy168
Copy link
Owner

@actboy168 actboy168 commented Jul 5, 2021

You can modify the default value of path in the settings.

@hemmerling
Copy link
Author

@hemmerling hemmerling commented Jul 5, 2021

THANKS alot, LUA_PATH problem solved.

( I beg your pardon, I am newbie to VSC, especially for configuration with extension settings & launch.json )

I just discovered your LUA_CPATH Extension settings :-), great.

I am still confused, that the setting

${env:path}

which is a total POWERSHELL-WINDOWS statement, also works for DebianLinux, if entered in the Extension Settings or in launch.json.
Might you be so kind and explain how you did it, and why it works with your plugin?
I thought I must enter different syntax for Linux...

Extension Settings, suggestion
Lua / Debug / Settings: CPath => Lua / Debug / Settings:LUA_CPATH
Lua / Debug / Settings: Path => Lua / Debug / Settings:LUA_PATH
to make it more clear that thats the place for the LUA variables, not for the standard os path :-)

And please mention the Powershell-alike Syntax which is also valid for Linux, in the documentation.

@actboy168
Copy link
Owner

@actboy168 actboy168 commented Jul 6, 2021

@hemmerling
Copy link
Author

@hemmerling hemmerling commented Jul 6, 2021

Cool !
Thanks for the comprehensive answer :-)

@actboy168 actboy168 closed this Aug 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants