[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Return an exit code without os.exit()?
- From: Geoff Leyland <geoff_leyland@...>
- Date: Wed, 7 Oct 2009 23:59:10 +1300
On 7/10/2009, at 11:17 PM, Jerome Vuarand wrote:
2009/10/7 Robert G. Jakabosky <firstname.lastname@example.org>:
On Wednesday 07, Geoff Leyland wrote:
On 7/10/2009, at 10:24 PM, Jerome Vuarand wrote:
2009/10/7 Geoff Leyland <email@example.com>:
Is there a way to return an exit code from a Lua script without
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
tell, the return value from a top-level script does not seem to be
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
is ignored. It should be easy to patch if a custom Lua executable
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
it's come up in a good few years of using Lua)
luacov should wrap os.exit() and dump that stats before calling the
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