os/exec: .Run() should not return as error on non-zero status on *NIX-like platforms #51123
Comments
|
The result of the |
|
The process state return is tertiary to the actual issue of non-zero exit statuses being treated as golang errors. |
|
Even in your example, a non zero exit code indicates a partial success/failure, deviating from a complete success, and potentially requiring extra actions. Reporting it as an error seems reasonable; in |
|
Adding new methods like |
|
By this logic, why not return an
The |
|
@johnnybubonic It seems to me that you are basically making a style argument. The same information is available either way. The os/exec package has picked a style. We would need a very good reason to change that style at this point. A good reason would be "I can't write this kind of code." An argument about the intended meaning of the |
|
Go 1.12 added func exitCode(err error) int {
if e, ok := err.(interface{ExitCode() int}); ok {
return e.ExitCode()
}
return -1
}Using something like Absent a pre-existing API, I agree an argument could be made the processes that return an exit status do exit "successfully". However, there is an API and adding further complexity doesn't seem like an improvement. Perhaps it might be useful to add a |
Missed this, thanks. This does at least make things a little less cumbersome/a little more clean and readable.
I think this is a good and fair approach. I do have my doubts that any PR/patch I submitted would be accepted, as it seems to be something endemic to the Golang core team (no offense intended, of course) - I have a CL in go-review that's seen no human activity since November (when I submitted it), so if it's going to be implemented, I suspect it'd have to be by someone who's already had commits accepted. |
|
For API changes (including adding new API), it needs to go through the proposal process, see https://golang.org/s/proposal . Would you like to make this a proposal, by editing the title and the first message to reflect your latest proposed API? Thanks. |
cherrymui
added
the
WaitingForInfo
|
@johnnybubonic Sorry your CL has not received any attention. It's fine to ping a CL. |
|
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
N/A; bug in design.
exec.Cmd.Run() currently returns an error on non-zero exit status.
This is not only poor design logic as many commands return non-zero even upon success, but it hampers access to getting the status code of a command- requiring
.Wait()to be invoked instead.A careful note is that it's common assumption that POSIX or some other standard defines
0as success andn > 0as failure. To stress, this is erroneous - it is convention, not standard.An immediate example that comes to mind is sendmail's
EX_TEMPFAIL, status code 75. This indicates that a message was deferred, not failed, and will be retried (or the user should retry, depending on your MTA spooling or lack thereof).What did you expect to see?
N/A
What did you see instead?
N/A
Proposed Resolution
I propose the following.
Obviously changing e.g.
exec.Run()execution with a non-zero exit code flagging anerroris not the proper way forward, as that's a significant API interface change that likely many people are depending on.Instead, there should be "non-erroring" methods added, e.g.
.RunNonZero()and.WaitNonZero()(I'm not crazy about the names, but...) that will return the*os.ProcessState(nil if error NOT related to command exit code) and error (NOT returned if command has non-zero exit code).The text was updated successfully, but these errors were encountered: