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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Haoqian He

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"

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.

Reply | Threaded
Open this post in threaded view
|

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

Reinder Feenstra
Hi,

Did you try with another command? e.g. "dir z:" (or another drive that doesn't exist)

To verify if it is just the exit command or all.

You can also run the exit command with the /B option to see if that makes a difference.

Reinder

On Sun, 6 May 2018, 08:45 Haoqian He, <[hidden email]> 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"

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.

Reply | Threaded
Open this post in threaded view
|

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

KHMan
In reply to this post by Haoqian He
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



Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
2018-05-06 11:48 GMT+02:00 KHMan <[hidden email]>:

> If I want a shell like a Unix shell, I just use Cygwin.

It's All Fixed™ on Windows 10 with the Linux Bash Shell.

Reply | Threaded
Open this post in threaded view
|

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

KUBO Takehiro
In reply to this post by Haoqian He
On Sun, May 6, 2018 at 3:44 PM, Haoqian He <[hidden email]> 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 guess that this issue will be fixed by the following patch.
(The patch is for lua 5.3.x. Replace LUA_USE_WINDOWS with LUA_WIN for Lua 5.2.)

https://gist.github.com/kubo/28a8a3c66858f6126ffc28f363c9e55f

Well, I have not tested it...

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

There is third case as far as I checked the lua source code.

text representation of errno: the system function itself fails; the
following number is the value of ISO C variable errno.

"No error" is the text representation of errno zero.
The patch checks errno in order not to go into the third case when the
executed command's exit code is -1.

Reply | Threaded
Open this post in threaded view
|

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

Russell Haley


On Sun, May 6, 2018 at 4:58 AM, Kubo Takehiro <[hidden email]> wrote:
On Sun, May 6, 2018 at 3:44 PM, Haoqian He <[hidden email]> 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 guess that this issue will be fixed by the following patch.
(The patch is for lua 5.3.x. Replace LUA_USE_WINDOWS with LUA_WIN for Lua 5.2.)

https://gist.github.com/kubo/28a8a3c66858f6126ffc28f363c9e55f

Well, I have not tested it...
I tried applying your patch using get git apply with no success (though the working directory is not a git repo. I used --unsafe-paths). Can you recommend a patch tool on Windows or should I just apply it manually to test?  

C:\Users\russh\git\WinLua-VS2017\work\lua-5.3.4 [master ≡ +6 ~12 -1 !]> git apply --unsafe-paths .\patch-exit.patch
error: patch failed: work/lua-5.3.4/src/lauxlib.c:273
error: work/lua-5.3.4/src/lauxlib.c: patch does not apply
error: patch failed: work/lua-5.3.4/src/liolib.c:264
error: work/lua-5.3.4/src/liolib.c: patch does not apply
error: patch failed: work/lua-5.3.4/src/loslib.c:140
error: work/lua-5.3.4/src/loslib.c: patch does not apply

Thanks
Russ

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

There is third case as far as I checked the lua source code.

text representation of errno: the system function itself fails; the
following number is the value of ISO C variable errno.

"No error" is the text representation of errno zero.
The patch checks errno in order not to go into the third case when the
ex 
ecuted command's exit code is -1.


Reply | Threaded
Open this post in threaded view
|

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

KUBO Takehiro
On Sun, May 6, 2018 at 11:26 PM, Russell Haley <[hidden email]> wrote:

>
> On Sun, May 6, 2018 at 4:58 AM, Kubo Takehiro <[hidden email]> wrote:
>>
>> On Sun, May 6, 2018 at 3:44 PM, Haoqian He <[hidden email]> 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 guess that this issue will be fixed by the following patch.
>> (The patch is for lua 5.3.x. Replace LUA_USE_WINDOWS with LUA_WIN for Lua
>> 5.2.)
>>
>> https://gist.github.com/kubo/28a8a3c66858f6126ffc28f363c9e55f
>>
>> Well, I have not tested it...
>
> I tried applying your patch using get git apply with no success (though the
> working directory is not a git repo. I used --unsafe-paths). Can you
> recommend a patch tool on Windows or should I just apply it manually to
> test?

I uploaded three patched files to the same location.
https://gist.github.com/kubo/28a8a3c66858f6126ffc28f363c9e55f

Click the [Download ZIP] button at the upper right corner.

Reply | Threaded
Open this post in threaded view
|

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

KUBO Takehiro
On Sun, May 6, 2018 at 11:41 PM, Kubo Takehiro <[hidden email]> wrote:
> I uploaded three patched files to the same location.
> https://gist.github.com/kubo/28a8a3c66858f6126ffc28f363c9e55f
>
> Click the [Download ZIP] button at the upper right corner.

Sorry, I uploaded incorrect file.
If the line 278 of lauxlib.c is "&& errno == 0", download the file
again or replace == with !=.

Reply | Threaded
Open this post in threaded view
|

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

Russell Haley


On Sun, May 6, 2018 at 7:51 AM, Kubo Takehiro <[hidden email]> wrote:
On Sun, May 6, 2018 at 11:41 PM, Kubo Takehiro <[hidden email]> wrote:
> I uploaded three patched files to the same location.
> https://gist.github.com/kubo/28a8a3c66858f6126ffc28f363c9e55f
>
> Click the [Download ZIP] button at the upper right corner.

Sorry, I uploaded incorrect file.
If the line 278 of lauxlib.c is "&& errno == 0", download the file
again or replace == with !=.

Thank you. I patched 5.4 work1 by accident but got away with it! There are also a few places in you files that are "initb" instead of "init.b". My kids are flanking me, I don't have time to produce a patch. I'll add that to my up-coming WinLua release. 

Russ
Reply | Threaded
Open this post in threaded view
|

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

Russell Haley



On Sun, May 6, 2018 at 1:25 PM, Russell Haley <[hidden email]> wrote:


On Sun, May 6, 2018 at 7:51 AM, Kubo Takehiro <[hidden email]> wrote:
On Sun, May 6, 2018 at 11:41 PM, Kubo Takehiro <[hidden email]> wrote:
> I uploaded three patched files to the same location.
> https://gist.github.com/kubo/28a8a3c66858f6126ffc28f363c9e55f
>
> Click the [Download ZIP] button at the upper right corner.

Sorry, I uploaded incorrect file.
If the line 278 of lauxlib.c is "&& errno == 0", download the file
again or replace == with !=.

Thank you. I patched 5.4 work1 by accident but got away with it! There are also a few places in you files that are "initb" instead of "init.b". My kids are flanking me, I don't have time to produce a patch. I'll add that to my up-coming WinLua release. 

sorry, output from my tests:

#patched 5.4 lua test build
C:\Users\russh\projects\desktopLua> .\bin\dtlua.exe
The function address is valid: 00007FF9832B5810

Lua 5.4.0 (work1)  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> os.execute("exit -1")
nil     exit    -1
>
C:\Users\russh\projects\desktopLua> lua
Lua 5.3.4  Copyright (C) 1994-2017 Lua.org, PUC-Rio
> os.execute("exit -1")
nil     No error        0
>
 

Russ