[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Lua Stand-Alone changes in 5.0-alpha
- From: Philippe Lhoste <PhiLho@...>
- Date: Fri, 20 Sep 2002 09:35:11 +0000 (UTC)
I just have found time to recompile Lua 5.0-alpha since my return from
After seing a strange behavior, I checked lua.c code, then the
documentation, and found that the command line options have quite changed.
-c option is deprecated and lua_close(L) is inconditionally called. That's a
good thing :-)
-s option (stack size) is deprecated too, and it make sense in the light of
-f option is replaced by -l. Well, that's what I thought first...
Actually, "lua a.lua -f b.lua t1 t3" is replaced by "lua -la.lua b.lua t1
The problem, for which I write, is that it somehow breaks the compatibility.
Well, I am not sure if it is really an issue...
Say we use the old syntax: lua -c -f foo.lua
On -c, Lua will display a "deprecated" message.
On -f, Lua will stop because it is an unknown option.
Should you treat the -f option like the -c one (deprecated) or will that
raise issues I don't see?
The previous Windows registry settings (I associated .lua extension to
lua.exe -c -f "%1" %*) or Unix shbang (#!) lines are no longer working.
Now, of course, for unixers (?), it can be a mean to specify different
interpreters, belonging to the old version or the new one, as long as the
path is different... On Windows, unless using a different extension, it
becomes hard to allow peaceful cohabitation. Unless specifying each time
which interpreter to use, forbidding quick double-click runs.
Actually, I am working on a solution, started before I discovered this
issue: a Windows program that will read the shbang line and run the correct
interpreter. It became necessary as I am starting to have various
interpreters: lua (5.0), lua40, luaPDF, LuaWin32, etc.
I will announce/release it when I think it is usable.
Perhaps this change of command line syntax is a non issue (I must admit I am
a bit confused), but I felt I should warn users of the change (for those who
haven't noticed before :-).
BTW, if I go in picky mode, I would frown at the following lines:
status = handle_argv(argv, &interactive);
if (status == 0 && interactive) manual_input();
handle_argv returns either EXIT_SUCCESS or EXIT_FAILURE.
I believe you should write "if (status == EXIT_SUCCESS" instead, to be
End of picky mode :-)
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist