lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 8/10/2009, at 1:50 AM, Jerome Vuarand wrote:

2009/10/7 Geoff Leyland <geoff_leyland@fastmail.fm>:

On 7/10/2009, at 11:17 PM, Jerome Vuarand wrote:


2009/10/7 Robert G. Jakabosky <bobby@sharedrealm.com>:


On Wednesday 07, Geoff Leyland wrote:


On 7/10/2009, at 10:24 PM, Jerome Vuarand wrote:


2009/10/7 Geoff Leyland <geoff_leyland@fastmail.fm>:


Is there a way to return an exit code from a Lua script without
calling
os.exit()?
I'm using luacov, and if you call os.exit(), it doesn't write any statistics. I'd also like my script to return 1 or 0. As far as I 
can
tell, the return value from a top-level script does not seem to be 
used for
an exit code, but hopefully someone can tell me I'm wrong.
Looking at the code in lua.c, it seems the return value of the script is ignored. It should be easy to patch if a custom Lua executable is 
an option to you.


Thanks, I thought someone might say that.  Shame really, it'd be a
nice feature to have in standard Lua (mind you this is the first time 
it's come up in a good few years of using Lua)


luacov should wrap os.exit() and dump that stats before calling the
normal
os.exit().
The very same issue has been discussed recently on the list, and iirc 
Lua 5.2 will have a kind of atexit facility to handle that (or maybe
that was just a request?).

But being able to return a value to the OS without os.exit woulf be
nice though. Since you're not limited to return a single integer in
your Lua scripts (and actually you can return anything and have it
passed out by dofile for example), finding what value to to pass to
the OS might be tricky. As non-zero return values are error codes, we could use the nil+msg error reporting mechanism often used in Lua: if 
the first return value is true (ie. non-nil and non-false) we return
0, and otherwise if the first return value is false (ie. nil or
false), we try to convert the second return value to an integer and
return that (or 1 if the second value is not convertible to an
integer). That's just an idea though.


I think it'd be safer to break that convention and return
0 on nil and 0,
a number on a number
some tortured logic for true and false
1 on any other value
That way, if you didn't return anything, the os would get 0 - success, and 
if you returned 1 or a string, the os would get 1 - failure.
The logic's contorted either way, but I don't think that returning nil (which most scripts would do by not having a return statement) should mean failure, and I don't think (nil) and (nil, message) should mean different 
things.


You can differentiate between a nil return value and no return value.
That way you can continue to treat (nil) or (nil,msg) as an error (and
return 1), and treat no return value as success (and return 0).


I didn't know that!  You mean like this?

> function a() end
> function b() return nil end
> =select("#", a())
0
> =select("#", b())
1

Or is there another way?

Cheers,
Geoff