os.exit(0) is not processed properly

[hemmerling]

The statement “os.exit()” is not processed properly, both on Windows and Linux.

• Version 1.40.0 does not work properly in “Run Without Debugging” mode: No debug console output.
• Version 1.40.0 works properly in “Start Debugging” mode, just if in the step mode. But if the button “Continue(F5)” is pressed, i.e. the debugger turns into “Run Without Debugging” mode, all debug console output is supressed .

This simple code makes reproducable effect, both on Linux and Windows.

print(package.path)
print("Hello")
print(package.path)
print("Hello")
os.exit(0)

I also checked that the workspace directory is the directory where this script is located ( must not be important, but good to know ).

For comparison, another VSC Lua debugger
http://marketplace.visualstudio.com/items?itemName=tomblind.local-lua-debugger-vscode
processes os.exit(0) always properly.
But I need your debugger, as the "Lua Test Adapter" depends on it...

[actboy168]

You can use os.exit(0, true).

[hemmerling]

The problem is not 0 or false, 1 or true. Its not the return value.
The problem is that the output is supressed by os.exit(), with any or no value, when executed in VSC with your debugger.

The problem with any workaround - avoiding to use os.exit() is, that all published standard code doesn´t use

local result = 1
os.exit(result)

but something like this

os.exit(class.functioncall(a,b))

and I must modifiy this code to make it run in VSC. And as you see, its not just putting a comment "--" in front of the os.exit(result) statement,
but creating a code like

local result = class.functioncall(a,b)
os.exit(result)

Many Lua code is badly written, so there is not just one os.exit() statement, which are usually not idential but have different parameters ect.
Indeed it is a question of coding style, to allow several os.exit() or not. So there are some people who agree to several os.exit() in simple 1-file script projects.

So the next developer will argue, why did I modify the script so heavily at many code positions, just to separate the os.exit() from the real one and only "main" function call.

Vice versa, if I publish code into a code repository ( on GitHub..), if I publish my original code, I can´t follow the standard rules... if I use the last-tested code I run in VSC. I still must uncomment the os.exit(result) statement...

You even suggest me to use a different syntax, which is not standard with given Lua code.

So I would be pleased about a fix, so that standard code runs properly within VSC and your debugger.

Btw, whats the reason for the os.exit() problem ?

[actboy168]

I don't think os.exit(0) is a standard usage. The second parameter of os.exit determines whether to call lua_close. A lua program can only exit correctly when it finally calls lua_close. Exit without lua_close is no different from crash.

[hemmerling]

a)
exit()'s origin is from Unix, C:
https://man7.org/linux/man-pages/man3/exit.3.html

So there is just ONE parameter.
Any Unix shell knows these exit codes
This is even implemented in COMMAND / CMD / Powershell from MSDOS to Win10.

So a batch file ( the script running in a shell ) can react to the return codes.
0 = ok
1, 2,... = something is wrong.

As this is basic knowledge and common culture since 50 years ( since Unix & C started ), swapped to the PC with MSDOS ( and later Windows ), ATARI-ST GEM & COMMODORE-AMIGA OS shells, later to Linux on PC, everybody is using an exit() with no or one parameter.

I know exit() since about 1987, when I had first C experiences on MSDOS.

b)

Exit without lua_close is no different from crash.

os.exit()
os.exit(0)
os.exit(1)
no os.exit() at all
...

works fine both on Linux and Windows command line, with LUA script files.

c)
So my LUA application which I ported from Linux / Windows to the CORE games platform ( which does not know about os.exit at all, as it is a sandbox LUA implementation ), is

http://www.github.com/bluebird75/luaunit

There are the following os.exit() statements in the core files

** luaunit.lua **

os.exit(-1)
os.exit(0)
os.exit(0)
os.exit(-2)
os.exit(-1)

** test_luaunit.lua **

lu.assertFailure(os.exit, 0)

this requires hard code modification, I am even confused, as the delicate function is transfered to another function.... and not the result

** run_unit_tests.lua **

os.exit( lu.LuaUnit.run() )

so this last line is where I must modify the code, not just put a "--" in front of.

Especially, LUA is the first programming language, where "everywhere" the script is ended with an os.exit() at all, all other programming languages don´t require such explicte statement,
of course it is possible with most programming languages with command line (non-graphical) to give a return status.

d)
How to exit a Lua script's execution
https://stackoverflow.com/questions/20188458/how-to-exit-a-lua-scripts-execution

How do you cleanly exit interactive Lua?
https://stackoverflow.com/questions/4961444/how-do-you-cleanly-exit-interactive-lua/4961458

Why and when im gonna use the parameter “code” of the os.exit() function in Lua
https://stackoverflow.com/questions/63332954/why-and-when-im-gonna-use-the-parameter-code-of-the-os-exit-function-in-lua

https://www.lua.org/pil/1.1.html

To exit the interactive mode and the interpreter, just type end-of-file (ctrl-D in Unix, ctrl-Z in DOS/Windows), or call the exit function, from the Operating System library (you have to type os.exit()).

.. nobody mentions a mandatory second parameter.

e)
I even had problems to find a reference for a second parameter at all!
I found it after all:

How to end script execution gracefully?
http://underpop.online.fr/l/lua/faq/how-to-end-script-execution-gracefully.htm

(In Lua 5.2 there is an optional second argument to os.exit which does close the Lua state and force proper cleanup.)

http://www.lua.org/manual/5.3/manual.html#pdf-os.exit
Lua.org "Lua 5.3 Reference Manual" - "os.exit ([code [, close]])"

Calls the ISO C function exit to terminate the host program. If code is true, the returned status is EXIT_SUCCESS; if code is false, the returned status is EXIT_FAILURE; if code is a number, the returned status is this number. The default value for code is true.
If the optional second argument close is true, closes the Lua state before exiting.

Exit without lua_close is no different from crash.

Obviously, VSC requires that the Lua state is closed before exiting.
Because in comparison to shell operation, where there is a forced closing and so the output is flushed to the standard-io devices, it does not work like this with VSC.
Nobody wants to modify code so that it runs with VSC.

Exit without lua_close is no different from crash.

So you have to add the lua_close to avoid the crash. Standard LUA applications don´t use this 2nd. parameter.
Any other question?

How can the default friendly behaviour of an non-given optional parameter ( the value which is taken if the optional parameter is not used ), which was introduced "lately" ( Roblox Lua is 5.1, Core Lua is 5.3., many Lua frameworks and applications are started with LUA 5.0 or even earlier ), be irrelevant for the developer of a VSC debugger plugin ?

Please modify your VSC plugin, so that
os.exit()
os.exit(1)
no os.exit at all
works fine and does not kills the output

[actboy168]

a) b)
We are talking about os.exit in lua, not exit in c.
c)
Luaunit use os.exit is wrong. lua-debug also uses a fork of luaunit, which fixes os.exit.
https://github.com/actboy168/bee.lua/blob/3c6764ad21d20cf279aea3077e823363f045e854/test/test.lua#L59
d)
When you just want to exit and don't care about anything, you don't need the second parameter. But you just want to exit decently, you need the second parameter.
e)
Unfortunately lua51's os.exit does not support safe exit, which is why lua later solved this problem.

[hemmerling]

a)

We are talking about os.exit in lua, not exit in c.

Yes, standard is that Lua has ONE parameter for exit(), as with most other computer languages.
As Lua is often included in bare C/C++ applications, and written in C/C++, it is in this tradition.

Most other known programming languages with shell application option for their applications offer an exit() too, I don´t know any other than LUA where a second parameter is implemented.

And as the OPTIONAL parameter of os.exit() is implemented recently, it can´t be that all given OpenSource Lua code must be modified....

b)
Well your plugin has to terminate a Lua session properly,
when the Lua code ends with

either nothing
os.exit()
os.exit(1)

As such the code is written since 20 years of Lua, and for any other programming language since 50 years.

The shells don´t crash if Lua is terminated this way,
you crash the Lua process, with the effect that the output is consumed and not displayed.

VSC plugins don´t have to crash the applications they are debugging, if the application follow the standard rules.

c)
Luaunit is popular
https://www.google.com/search?q=lua+unittest
top #1 position.

It is one of 100s of Lua applications, which end by

os.exit()
os.exit(1)
no os.exit()

Why do you make your VSC plugin worthless, as I must comment "you must modify given OpenSource code heavily to let it run in this debugger ?

Why do you insist - as VSC plugin developer - to urge developers of your target language Lua for certain irrelevant code rules ?
Do you do Lua coding at all?
Did you debug given OpenSource Lua code in your own debugger?

d)
Thanks for pointing me to a fork of LuaUnit.
But its your fork, and its not even a fork.

As the title is
Lua runtime and toolset
https://github.com/actboy168/bee.lua

its a complete new runtime?!
I don´t want another Lua runtime, nor patches for Lua runtime.

I even don´t see now a "fork",
as a fork would be a complete new GitHub project ( especially due to the non-MIT license of LuaUnit, it should not be mixed with standard MIT-licensed Lua code ),
or at least a sub-project, in a folder.
I don´t see anything of that.
You just pointed me to a "test page" of your GitHub account...

e)
Why it is wrong to URGE people to modify OpenSource code without reason?
Because they "fork" at that moment.
With a new release of the software, they have to do the useless and unnecessary patches again....

f)
Just tell me in which way you use in "your" Lua applications
os.exit(0, false)
os.exit(1, false)
which is obviously the default for your VSC plugin,

, and if possible name references ( web articles...) about this.

And by keeping the Lua state open, though the debug session ends,
what kind of application is that?

I would be pleased about an article by you,
how to attach VSC with your plugin to a "running Lua application" like a webserver or database,
where the debug session is ended,
but the application is still running, and for this the Lua state must not be closed.

For 99% of Lua applications:
As finishing a debug sesssion by ending a script is a final action,
same as when called by a shell,
why should there be something left open?

[actboy168]

I don't want to engage in such meaningless arguments anymore. You can use the solution I provide you, or find a solution by yourself.