[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: os.exit()/os.execute() behaviour (Lua 5.1)
- From: Gyepi SAM <self-lua@...>
- Date: Fri, 17 May 2013 12:16:31 -0400
On Fri, May 17, 2013 at 09:48:06AM -0400, Brad Jorsch wrote:
> On Fri, May 17, 2013 at 9:06 AM, Thijs Schreijer
> <email@example.com> wrote:
> > The results (see below) are what I expected for Windows. But on Ubuntu, I
> > can’t explain it.
> > The exitcodes are supposed to be between 0 and 255. So the os.exit(-5) and
> > os.exit(400) are out of range, but the valid test; os.exit(25) also gives me
> > a return value in os.execute() of 6400.
> 6400 == 25 * 256.
> The status returned by C functions such as system() and wait() encodes
> the actual exit status, the signal that terminated the program, and
> whether the program dumped core. POSIX specifies macros to extract
> these bits of information from the returned status value.
> On my system, the exit status is encoded in the high byte (read with
> (status & 0xff00) >> 8), the signal in the low byte (read with status
> & 0x7f), and the core-dumped flag in status & 0x80. Also, status &
> 0xff == 0x7f indicates the child is stopped, and status == 0xffff
> indicates that the child continued from being stopped.
> But it doesn't look like this is standardized beyond just "these
> macros should be provided" and that status == 0 means a normal exit(0)
> or the equivalent. So other systems could encode this information in
> different ways.
We need to make a distinction here between wait() and system().
Everything written here applies to wait, but does differ for system()
because system calls "/bin/sh -c" (or the moral equivalent) and returns
the shell's exit code. When a process terminates normally, the shell returns
its exit code. However, when the process is terminated by a signal, it
returns 128 + the signal number.
wait is defined by POSIX and system is defined by C89, C99 and POSIX.
However, the C standard leaves the return value as an implementation detail
whereas POSIX requires wait semantics (with the tepid note that its requirements are
aligned with C). Mind the gap.
Finally, keep in mind that system is just a convenience wrapper around fork, exec and
waitpid. If you MUST have portable behaviour, it might make sense to call the
trio directly. I frequently prefer this option in C since I can use the appropriate
exec* function depending on my needs and not the shell's. But YMMV in lua.