In the general case we can't recreate the right exit status, but I suppose we could pass along an ordinary exit code.

I think the exit code would be enough, just to be able to use go run ... from other tools, without requiring a go build first. Context: we do this for smaller scripts, where we use Go like a scripting language, instead of Ruby / Python / etc.

CL https://golang.org/cl/18271 mentions this issue.

Not for Go 1.6.

From code review:

What if it crashed due to a signal? Now it's exit(someRandomNumber).
I am not convinced this needs to be done at all.

It won't exit with some random number if it fails with a signal.
It will exit with status 1 as it did before.

Fair enough, let me try again:

What if it crashed due to a signal?
It used to print information about the exit reason and exit 1.
Now it's a silent exit(someRandomNumber).

The real question is whether 'go run x.go' is supposed to be just an interpreter for Go programs, like 'python x.py' or whether it is a tool that runs a subprocess and reports the results itself, like make. To date, the answer has been the latter. So it's not obvious the behavior is wrong, unless 'go run' is supposed to be some kind of interactive go command, which we've said in the past it is not.

$ cat makefile
exit5:
    exit 5
$ make exit5
exit 5
make: *** [exit5] Error 5
$ echo $?
2
$ 

(Make happens to use 2 instead of 1, but it's always 2 on my system.)

$ cat x.go
package main

import "os"

func main() {
    os.Exit(5)
}
$ go run x.go
exit status 5
$ echo $?
1
$ 

I agree with Russ for the reasons he stated.

An exit code is a single-dimensional value. When doing go run, there are 2 processes that run and 2 exit codes one may want to know.

However, go run is only able to report a single exit code value, not two. It's not possible to losslessly combine two exit codes into one. If it reported the exit code of the program it ran verbatim, then information about the go run exit code would be shadowed and effectively lost.

IMO, if one cares about the exact exit code of the program that is executed, they need to build it and execute it themselves. go run is a convenience feature for when your needs are not as demanding and you're okay with less information, because it's unable to communicate more information than it already does.

I think this is effectively closed.

I updated the CL to fix only windows and unix. Still wrong?

@shurcooL how about to add new flag to return status code (non-1) of the exit code from go run?

Please, no more flags. Go run is for toy programs, if you have a serious
program then build and run it seriously.

On Wed, 11 May 2016, 13:26 mattn, notifications@github.com wrote:

@shurcooL https://github.com/shurcooL how about to add new flag to
return status code (non-1) of the exit code from go run?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#13440 (comment)

@davecheney So do you think https://github.com/sno6/gommand this should do go build -o myapp && ./myapp it self if he want exit code of the program?

My advice that Go run is a toy, and adding more features to it to make it
more capable is moving in the wrong direction. The rest of the go tool is
focused on code placed in packages and built and tested as such.

On Wed, 11 May 2016, 13:32 mattn, notifications@github.com wrote:

@davecheney https://github.com/davecheney So do you think
https://github.com/sno6/gommand this should do go build -o myapp &&
./myapp it self if he want exit code of the program?

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#13440 (comment)

Okay, agreed. Thanks.