lua-users home
lua-l archive

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

On 5/6/2018 2:44 PM, Haoqian He wrote:
I have found a bug in the API "os.execute" when it runs a program that returns -1 on Lua 5.3.4 on Windows (Windows 10Home 64Bit, Version 10.0.16229 Build 16229)

I didn't compile it on Windows myself. I downloaded the binary from ""; <>

According to my tests, Linux and OSX are not affected by this.

The bug exists on Windows at least since Lua 5.2.1 (Very likely since 5.2.0, but I didn't test it)

Lua 5.3.4  Copyright (C) 1994-2017, PUC-Rio
 > print(os.execute("exit -1"))
nil     No error        0

Lua 5.2.1  Copyright (C) 1994-2012, PUC-Rio
 > print(os.execute("exit -1"))
nil     No error        0

According to the Lua documentation

os.execute ([command])
This function is equivalent to the ISO C function system. It passes command to be executed by an operating system shell. Its first result is true if the command terminated successfully, or nil otherwise. After this first result the function returns a string plus a number, as follows: "exit": the command terminated normally; the following number is the exit status of the command. "signal": the command was terminated by a signal; the following number is the signal that terminated the command. When called without a command, os.execute returns a boolean that is true if a shell is available.

For the above test case. The first return value is "nil" as intended. However, the second return value "No error" is not specified in the documentation. Furthermore, it is incorrect that the 3rd return value is 0. Non-zero value is expected.

For those who want to experiment, here are some links:

Unclear what is actually going on.

I tried the thing on a Lua 5.3.4 compiled on a recent 32-bit MinGW distro and got the same thing.

IMHO, MSVCRT is its own quirky dialect. Plus, can we expect cmd.exe to work like a Unix shell? Plus, it's obsolete. It's still linked to because it's the lowest common denominator. It works well enough for a lot of things, until, bam! we run into something like this.

It's legacy, won't be fixed. MSVC++ apps are supposed to supply the redistributable, etc. so that's how it's supposed to be fixed. But it's a problem with something like MinGW or many F/LOSS software obviously.

If I want a shell like a Unix shell, I just use Cygwin. In order to use system() like a Unix shell, I think you would have to audit everything you plan to do to make sure the behaviours are acceptable. Then maybe look into replacing system()... ha ha.

Besides, a lot of other things don't fully work on MSVCRT too.

Kein-Hong Man (esq.)
Selangor, Malaysia