Re: Return an exit code without os.exit()?

[Jerome Vuarand <jerome.vuarand@...>]

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).