Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/go: allow "go run" to run command in current directory #5164

Closed
titanous opened this issue Mar 30, 2013 · 22 comments
Closed

cmd/go: allow "go run" to run command in current directory #5164

titanous opened this issue Mar 30, 2013 · 22 comments
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Unplanned

Comments

@titanous
Copy link
Member 

1. go run *.go

What is the expected output?

[program runs]

What do you see instead?

go run: cannot run *_test.go files (foo_test.go)

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

OS X 10.8.2

Which version are you using?  (run 'go version')

go version devel +946f0a049860 Sat Mar 30 11:18:56 2013 -0700 darwin/amd64

Please provide any additional information below.

This worked with the 1.0.3 go tool.
@robpike
Copy link
Contributor

robpike commented Mar 30, 2013

Comment 1:

Labels changed: added priority-soon, go1.1, removed priority-triage.

@titanous
Copy link
Member Author

Comment 2:

Initial attempt: https://golang.org/cl/8119049

@titanous
Copy link
Member Author

titanous commented Apr 4, 2013

Comment 3:

This issue was fixed by revision 2fc72d55ed99 but I didn't get the syntax to auto-close
quite right.

@adg
Copy link
Contributor

adg commented Apr 4, 2013

Comment 4:

Picky picky google code.

Status changed to Fixed.

@rsc
Copy link
Contributor

rsc commented Apr 29, 2013

Comment 5:

I rolled back the CL. I'd like the semantics to be a bit different. See comment on
https://golang.org/cl/8119049

Labels changed: added priority-later, removed priority-soon, go1.1.

Status changed to Accepted.

@adg
Copy link
Contributor

adg commented Apr 30, 2013

Comment 6:

This issue was updated by revision e2b2e0d.

R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/9049043

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 7:

Labels changed: added go1.2maybe.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 8:

Labels changed: added feature.

@robpike
Copy link
Contributor

robpike commented Aug 20, 2013

Comment 9:

Won't happen for 1.2. Not clear it will happen at all.

Labels changed: added go1.3maybe, removed go1.2maybe.

@robpike
Copy link
Contributor

robpike commented Aug 20, 2013

Comment 10:

Labels changed: removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Sep 3, 2013

Comment 11:

I'd like to see this happen.

Labels changed: added go1.3, removed feature.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 12:

Labels changed: added release-go1.3.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 13:

Labels changed: removed go1.3.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 14:

Labels changed: added repo-main.

@kelseyhightower
Copy link
Contributor

Comment 15:

I've submitted a CL for this issue: https://golang.org/cl/73350043
My CL is based off the conversation in the previous CL:
https://golang.org/cl/8119049

@minux
Copy link
Member

minux commented Mar 10, 2014

Comment 16:

FYI, the current CL under review is https://golang.org/cl/50970043/

@gopherbot
Copy link

Comment 17:

CL https://golang.org/cl/50970043 references this issue.

@rsc
Copy link
Contributor

rsc commented May 13, 2014

Comment 18:

The CL is out but I can't decide about what command line we really want, if any.
Postponing to 1.4.

Labels changed: added release-go1.4, removed release-go1.3.

@rsc
Copy link
Contributor

rsc commented Sep 15, 2014

Comment 19:

Labels changed: added release-go1.5, removed release-go1.4.

@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014
mattbostock added a commit to mattbostock/leavediary that referenced this issue Mar 23, 2015
@mattbostock
Move route registration to routes.go
33c4c87 
Move route registration to the `init()` function of `routes.go` (still
part of the main package).

Also, create a new `handler` package which will contain functions
implementing `http.HandlerFunc` that `routes.go` will refer to when
registering routes.

Note that splitting the main package over two files (`main.go` and
`routes.go`) means that `go run main.go` no longer runs the application
correctly as it ignores `routes.go` entirely. Instead, we have to run
`go run main.go routes.go` or `go build && ./timeoff`. See this issue
for more details:
golang/go#5164

Keep the route registration for `/debug/vars` (as provided by the
`expvar` package) in `main.go` as it's not part of the main application
functionality.

One thing I still need to work out is how to expose `l`, i.e.
`*logrus.Logger`, to the handler functions now that they're part of the
`handler` package instead of `main`.
mattbostock added a commit to mattbostock/leavediary that referenced this issue Mar 23, 2015
@mattbostock
Update Procfile to use TIMEOFF_ADDR
9a88734 
The HTTP server port is now defined using the `TIMEOFF_ADDR` environment
variable.

Also, run `go build` rather than `go run` to ensure that both `main.go`
and `routes.go` are taken into account by the compiler; see:
golang/go#5164
@rsc rsc removed accepted labels Apr 14, 2015
@rsc rsc modified the milestones: Unplanned, Go1.5 Jun 8, 2015
@titanous titanous added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jan 7, 2017
@myml
Copy link

myml commented Feb 9, 2017

@rsc This is simple and Forgotten

@rsc
Copy link
Contributor

rsc commented Feb 9, 2017

Forgotten, maybe, but not simple.

@rsc
Copy link
Contributor

rsc commented Feb 9, 2017

I reread the discussion on https://golang.org/cl/50970043/, and I still don't see a way to integrate this. Obviously the command-line 'go run' could run the program in the current directory, but then 'go run arg' and 'go run arg.go' behave completely differently. I think this is probably OK to leave as is. For single-file programs people know about 'go run foo.go', and for larger programs 'go build && ./myprog' seems to be working fine.

@rsc rsc closed this as completed Feb 9, 2017
@ahmetb ahmetb mentioned this issue May 19, 2017
Closed
@rsc rsc mentioned this issue Nov 20, 2017
Closed
@golang golang locked and limited conversation to collaborators Feb 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
9 participants
@bradfitz @titanous @rsc @minux @kelseyhightower @robpike @adg @gopherbot @myml