Re: os.execute bug on Windows when the program returns -1

[KHMan <keinhong@...>]

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 
> "https://sourceforge.net/projects/luabinaries/files/5.3.4/Tools%20Executables/lua-5.3.4_Win32_bin.zip/download"; 
> <https://sourceforge.net/projects/luabinaries/files/5.3.4/Tools%20Executables/lua-5.3.4_Win32_bin.zip/download>
>
> 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 Lua.org, PUC-Rio
>  > print(os.execute("exit -1"))
> nil     No error        0
>
>
> Lua 5.2.1  Copyright (C) 1994-2012 Lua.org, 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:


https://stackoverflow.com/questions/29760811/msvcrt-system-function-return-code-is-always-1

  https://ss64.com/nt/exit.html


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.

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia