Hi folks,I struggled to get the exit status (integer) of a command executed with os/exec. I followed the documentation through ExitError and ProcessState, but could only find the ProcessState.Success() boolean. After searching Google+StackOverflow I found you *can* get it, but it requires importing syscall and converting to a syscall type -- pretty klunky.Here's roughly the code snippet that I'm using:
It's the "import syscall" and the "exitErr.Sys().(syscall.WaitStatus)" bits that get me. Syscall is platform-specific (though from reading SO, this actually works on all platforms), and it's an extra type conversion and if statement that seems unnecessary once you have the ExitError.Am I missing something, and is there a simpler way?
If not, I propose that we add an ExitStatus() method to os.ProcessState. Then you could just call exitErr.ExitStatus() directly, or even cmd.ProcessState.ExitStatus(). We'd have to document what value it returns if the process hasn't exited (but the same issue is true for ProcessState.Success()).
The reason ExitStatus is not defined is probably because plan9 does not support it. Instead of a status code it returns a message.
You can look at WaitMsg.ExitStatus implementation in https://golang.org/src/syscall/syscall_plan9.go.
If not, I propose that we add an ExitStatus() method to os.ProcessState. Then you could just call exitErr.ExitStatus() directly, or even cmd.ProcessState.ExitStatus(). We'd have to document what value it returns if the process hasn't exited (but the same issue is true for ProcessState.Success()).Yes, probably ExitStatus can be implemented directly for ProcessState. But there should be a reason why it has not been implemented.Probably because ExitStatus is a low level detail. You don't usually need it, and if you really need it you will need to use the syscall package for more details.
The reason ExitStatus is not defined is probably because plan9 does not support it. Instead of a status code it returns a message.You can look at WaitMsg.ExitStatus implementation in https://golang.org/src/syscall/syscall_plan9.go.I realize some of the Go core devs have a strong connection to plan9, but in reality Linux+macOS+Windows are what people are using. Also, with implementing ExitStatus(), syscall_plan9.go itself is acknowledging it's important enough to fulfill that contract even for plan9 (even when it's defined as a hack to look at the message length and return a 0 or 1 status based on that).If not, I propose that we add an ExitStatus() method to os.ProcessState. Then you could just call exitErr.ExitStatus() directly, or even cmd.ProcessState.ExitStatus(). We'd have to document what value it returns if the process hasn't exited (but the same issue is true for ProcessState.Success()).Yes, probably ExitStatus can be implemented directly for ProcessState. But there should be a reason why it has not been implemented.Probably because ExitStatus is a low level detail. You don't usually need it, and if you really need it you will need to use the syscall package for more details.I disagree. I'm using it, many others have asked on StackOverflow. You might use it to display the status code in a different font or in bold, or in a UI label.
You might use it because you're "scripting" with Go, calling sub-processes and switching on the well-defined status codes of a particular program to determine what to do next (eg, 1=file not found, 2=invalid format, 3=other exception).
You might use it because you're "scripting" with Go, calling sub-processes and switching on the well-defined status codes of a particular program to determine what to do next (eg, 1=file not found, 2=invalid format, 3=other exception).AFAIK, this is not portable:
Seems reasonable to me, though you'd have to specify what to do on
Plan 9. See https://golang.org/s/proposal.