child_process, expose a raw exit code

[Cloudef]

I'd like to have a feature in node to access the raw exit status of the program, for a better emscripten system() implementation. Right now emscripten's system implementation is repacking the exit code to return it in the "waitpid" format as required by POSIX. However, this only POSIX specific and doesn't make much sense e.g. on Windows, but we also don't want to return values that doesn't match when compiling and running the C program natively since it could cause incompatibility. Thus having access to raw exit code of a child program from node would be best approach to go here!

See the emscripten system implementation and related node / libuv discussion here:
emscripten-core/emscripten#10547

[bnoordhuis]

Node.js never sees the raw exit code because that's captured by libuv.

It's available as process->status but that's a private implementation detail because it's POSIX-only - uv_spawn() on Windows works differently.

Besides the technical roadblocks, your feature request also conflicts with Node's general philosophy of providing platform-neutral APIs.

[Cloudef]

Besides the technical roadblocks, your feature request also conflicts with Node's general philosophy of providing platform-neutral APIs.

In this case, I don't think it matters since exit codes and spawning processes is not platform-neutral in the first place.

[bnoordhuis]

Node.js and libuv go to considerable lengths to shield users from platform differences. That includes process management.

You're asking for the POSIX exit status but it's not clear to me what you expect it to do on Windows, or why.

(The rule of thumb is we only implement features that can be reasonably supported on all supported platforms, Windows included.)

Also, per your original comment, you have a working solution that, while perhaps not entirely elegant or satisfactory, is good enough to get the job done.

I'm reluctant to add a new API for a single user when it's just a nice-to-have, the bar for API additions is higher than that. It needs a compelling argument.

[Cloudef]

Node.js and libuv go to considerable lengths to shield users from platform differences. That includes process management.

While it's nice node unpacks the signal and exit code bit on POSIX systems and hands them out for user like that, there's already a "platform differences" here, in the fact that windows doesn't have exit_signal or signal support whatsoever #12378

While of course, normal node applications should use the unwrapped exit code for their things, there are applications such as emscripten, that just want the raw exit code to offer best possible support for converting native code to javascript and acting as if it would if it was native.

Note that, while process management can be abstracted into certain lengths, to be somewhat portable. Assuming all systems have some sort of PATH, and the identically named binary is there, and they all launch with the same executable name, use the same flags etc.. Most big programs that call any sort of processes, assume some sort of environment such as POSIX. Point being, processes inherently aren't platform-neutral.

You're asking for the POSIX exit status but it's not clear to me what you expect it to do on Windows, or why.

I'm not asking for a POSIX status code, but for a raw status code. Whatever the operating system happens to return.

[bnoordhuis]

I'm not asking for a POSIX status code, but for a raw status code. Whatever the operating system happens to return.

Possible, but it needs to be implemented in libuv first. I won't block it (I'm a libuv maintainer) but I'm not going to work on it either and it's not a given other maintainers will accept such a change.

the fact that windows doesn't have exit_signal or signal support whatsoever #12378

While that's a bit of a tangent, I think you're misunderstanding that issue - the support exists, it's just partial (you can only send a subset of signals.)

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.