golang cli option to run on all .go files within directory

1,449 views
Skip to first unread message

berser...@gmail.com

unread,
May 15, 2014, 10:46:11 AM5/15/14
to golan...@googlegroups.com
I know the Unix people here have the convenient option of using something along the lines of

go run *.go

yet, us Window guys don't have the luxury of token expansions on the cli.

It would be nice if there could be an option added to the cli to run, build, etc. 
all .go files within the current directory.

With projects getting larger, I divide my package main into multiple files - it's just
terribly cumbersome to have to type in all the .go file names into the cli.

Tamás Gulácsi

unread,
May 15, 2014, 1:46:16 PM5/15/14
to golan...@googlegroups.com
What about go build && xx.exe ?

Gyepi SAM

unread,
May 15, 2014, 2:47:17 PM5/15/14
to berser...@gmail.com, golan...@googlegroups.com
Isn't there a utility for this problem already?
Something like:

glob go run *.go

where glob expands all tokens and execs the resulting command.

Should be a nice, simple go program if it doesn't exist.

-Gyepi


Nate Finch

unread,
May 15, 2014, 3:42:31 PM5/15/14
to golan...@googlegroups.com, berser...@gmail.com
I think you're misunderstanding how the go tool works.  You can do "go build" in a directory, and it'll build the whole package (a package is defined as all .go files in a directory).  Same for go install, go test, etc.  Go run is the only one that requires you to specify specific files... it's really only meant to be used on very small programs, which generally only need a single file.

Added note, if you want to build all packages in this directory and all subdirectories, you can do "go build ./..."  (same for go install and go test)

John Souvestre

unread,
May 15, 2014, 4:34:37 PM5/15/14
to Gyepi SAM, berser...@gmail.com, golan...@googlegroups.com
Try

for %a in (*.go) do go run %a

John

    John Souvestre - New Orleans LA
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

StalkR

unread,
May 15, 2014, 5:50:31 PM5/15/14
to berser...@gmail.com, golang-nuts
On Thu, May 15, 2014 at 4:46 PM, <berser...@gmail.com> wrote:
With projects getting larger, I divide my package main into multiple files - it's just
terribly cumbersome to have to type in all the .go file names into the cli.
If main is growing, maybe some parts could be in libraries?
As good practice I try to keep my main packages as small as possible (and therefore in a single file), with all re-usable parts in libraries.

On Thu, May 15, 2014 at 4:46 PM, <berser...@gmail.com> wrote:
yet, us Window guys don't have the luxury of token expansions on the cli.
I sometimes use Windows and have this luxury because I use bash with cygwin and mintty - I recommend it.

Gyepi SAM

unread,
May 16, 2014, 1:18:11 AM5/16/14
to John Souvestre, berser...@gmail.com, golan...@googlegroups.com
On Thu, May 15, 2014 at 03:34:37PM -0500, John Souvestre wrote:
> Try
>
> for %a in (*.go) do go run %a
>
> John

Close, but not quite the same.

berser...@gmail.com

unread,
May 16, 2014, 3:45:44 AM5/16/14
to golan...@googlegroups.com
@johns

The approach doesn't work if I've spread out my functions across different files
and use them in files other than where they've been defined.

@Nate Finch

I've confirmed that go build ./ indeed works on the entire directory, 
but it's nonetheless cumbersome to have to build through the command line 
and then click on the application .exe to get the program started. 

Run is great in these aspects because it both compiles and runs the program
removing the need for two actions. 

I may have misunderstood how the go tool currently works as you've stated,
but nonetheless having an added option for Run to apply itself on the entire
directory (package) would be immensely convenient.

On a side note, even with small programs, I prefer to divide my files if I feel they work on
different aspects of the program, just so that I can get my head around them more easier
- along with the added advantage of being able to infer from just the file names I see in 
the directory what kind of program I've built.

In summary though, my main point is purely in the fact that this would be immensely convenient,
nothing else. I think the fact that people are already using "go run *.go" in systems where it's
possible to do so plainly shows how convenient this is.



Gyepi SAM

unread,
May 16, 2014, 7:38:45 AM5/16/14
to berser...@gmail.com, golan...@googlegroups.com
On Fri, May 16, 2014 at 12:45:44AM -0700, berser...@gmail.com wrote:
> I may have misunderstood how the go tool currently works as you've stated,
> but nonetheless having an added option for Run to apply itself on the entire
> directory (package) would be immensely convenient.
> .....
> In summary though, my main point is purely in the fact that this would be
> immensely convenient,
> nothing else. I think the fact that people are already using "go run *.go"
> in systems where it's
> possible to do so plainly shows how convenient this is.

A convenience that can be easily acquired.

http://play.golang.org/p/K4RXYkzMCX

Solving this problem outside of the go tool has the advantage of not
cluttering it with unnecessary options and makes the solution immediately
available for other tools. This is an essential aspect of the unix approach.

-Gyepi

Tamás Gulácsi

unread,
May 16, 2014, 7:44:47 AM5/16/14
to golan...@googlegroups.com, berser...@gmail.com

In summary though, my main point is purely in the fact that this would be immensely convenient,
nothing else. I think the fact that people are already using "go run *.go" in systems where it's
possible to do so plainly shows how convenient this is.

I've used to
    go build && ./myprog
and not
    go run *.go


distributed

unread,
May 16, 2014, 8:00:48 AM5/16/14
to golan...@googlegroups.com, berser...@gmail.com
I'm also using "go build && ./myprog" on Windows.

Mateusz Czapliński

unread,
May 16, 2014, 8:07:46 AM5/16/14
to golan...@googlegroups.com, berser...@gmail.com
On Friday, May 16, 2014 9:45:44 AM UTC+2, berser...@gmail.com wrote:
I've confirmed that go build ./ indeed works on the entire directory, 
but it's nonetheless cumbersome to have to build through the command line 
and then click on the application .exe to get the program started. 

Run is great in these aspects because it both compiles and runs the program
removing the need for two actions.

The suggestion from Tamás Gulácsi should be taken more explicitly; assuming you are in directory "C:\foo>", you should type into your cmd.exe console the following one-line command (composed of two commands):

  go build . && foo.exe

The cmd.exe prompt is quite more capable now than the command.com of olden days; sometimes one can nearly feel like coding in an acceptable programming language when using it (but then immediately one falls through the rickety floor into a basement full of looping thorns and pain, and with no easy escape).

Konstantin Khomoutov

unread,
May 16, 2014, 8:31:27 AM5/16/14
to Mateusz Czapliński, golan...@googlegroups.com, berser...@gmail.com
On Fri, 16 May 2014 05:07:46 -0700 (PDT)
Mateusz Czapliński <czap...@gmail.com> wrote:

[...]
> go build . && foo.exe

"." is not needed;

go build && foo.exe

would suffice.

berser...@gmail.com

unread,
May 16, 2014, 10:26:01 AM5/16/14
to golan...@googlegroups.com, berser...@gmail.com
Thanks for all the replies,

go build && foo.exe 

will be the road I'll be taking for the time being. 
I can confirm it works and it's a whole lot simpler than typing each individual file.

I would like to add though, that I feel personally that if a command line command is named "Run",
I expect my program to actually [Run]. If adding an option is felt as out of bounds of being minimalistic,
it might be worthwhile to change the Run command to default to compile and run the
current package. 

Ex. go run => compiles and runs entire package
go run [file names] => compiles files listed and attempts to run package 

Reply all
Reply to author
Forward
0 new messages