build scripts

[ericlagergren]

Need some help creating generic build scripts.

Basic idea would be a Go file inside the main repo that allows you to build any of the go-coreutils commands you want.

E.g., the process would be a little like this:

go get github.com/ericlagerg/go-coreutils (creates a binary file in $GOBIN)

To install all: go-coreutils install --all To install specific: go-coreutils install --rm --wc --cat To install a bunch of specific tools go-coreutils install --from-file=list.csv

Thoughts?

[rdeusser]

I think it's a good idea. We'd need to figure out logistically how it would work. When you go-coreutils install --rm does that replace the GNU rm binary completely? What If I want to go back? What if I want a way to test both quickly while both being on the path? (ie: having go-coreutils call the binary for you go-coreutils rm /home/nope/blahfile). Also, should the build tool let the user specify whether they want dynamic or statically linked binaries? What kind of features do we want in the build tool? Should it stay as simple as possible? Or Go the GNU way and jam pack it with features? (Did ya see what I did there? :smile:). Hopefully we can get more input besides @EricLagerg and myself.

Now I can say what I think the build tool should do. Users should be able to go get github.com/ericlagerg/go-coreutils and in order to use one of the utilities (say testing it out) go-coreutils rm /home/nope/blah. That way the user can keep both GNU coreutils (for now muahahaha) and still be able to use/test go-coreutils. That being said, I do like the option of doing go-coreutils --install rm wc cat or go-coreutils --install --all. Exact syntax to be worked out later.

[ericlagergren]

I was thinking the go-coreutils binaries would be installed in $GOBIN and we could add a command, say, go-coreutils overwrite ... that copies the binaries from $GOBIN to the GNU coreutils location. On Tue, Jul 28, 2015 at 8:24 AM Robert Deusser notifications@github.com wrote:

I think it's a good idea. We'd need to figure out logistically how it would work. When you go-coreutils install --rm does that replace the GNU rm binary completely? What If I want to go back? What if I want a way to test both quickly while both being on the path? (ie: having go-coreutils call the binary for you go-coreutils rm /home/nope/blahfile).

— Reply to this email directly or view it on GitHub https://github.com/EricLagerg/go-coreutils/issues/103#issuecomment-125653198 .

[rdeusser]

The only issue I see with that is if the user has the $GOBIN path in their $PATH. The binaries are named the same so which one gets used? How do you specify?

[rdeusser]

I think it would be best if go-coreutils created a folder not on the $PATH. Perhaps $GOBIN/go-coreutils? That way go-coreutils can call it's own binaries without confusion. (ie: am I using GNU rm or go-coreutils rm?). This however, gets a little out of scope for a build tool and becomes more multipurpose.

[rdeusser]

I like the go-coreutils overwrite option. Definitely gonna want some "are you sure?"'s in there. :smiley:

[ericlagergren]

As far as I'm aware, paths on pretty much every OS are first-come, first-serve order and I'd assume most systems would have GNU's coreutils in ~/bin, /bin/ usr/sbin/, etc. -- all of which are typically before $GOBIN in the path.

I'm hesitant to have the utilities be called from a binary, (e.g. go-coreutils rm instead of rm) because that sort of defeats the purpose of the utilities in the first place. Not only would it make executing the commands slower and possible introduce bugs, but imagine something like this (yes, I know, UUOC and stuff but it's not an uncommon example):

cat file.txt | sed 'g;n;p' | sort | uniq

would be

go-coreutils cat file.txt | set 'g;n;p' | go-coreutils sort | go-coreutils uniq

which is twice as long and unwieldy.

Another option would be to have a flag that adds a prefix to the installed commands. E.g., --prefix=string could prefix each command with the given prefix, so --prefix=g would cause wc to be gwc...

Thing is, since this project aims to be drop-in compatible, anybody who installs the utilities would probably either a) know what they're doing, or b) have these in lieu of GNU's coreutils (because they're on Windows or want GNU/Linux functionality on BSD, etc.)

[rdeusser]

As far as I'm aware, paths on pretty much every OS are first-come, first-serve order and I'd assume most systems would have GNU's coreutils in ~/bin, /bin/ usr/sbin/, etc. -- all of which are typically before $GOBIN in the path.

This is true, but who knows what people do with their PATH.

I'm hesitant to have the utilities be called from a binary, (e.g. go-coreutils rm instead of rm) because that sort of defeats the purpose of the utilities in the first place. Not only would it make executing the commands slower and possible introduce bugs, but imagine something like this (yes, I know, UUOC and stuff but it's not an uncommon example):

cat file.txt | sed 'g;n;p' | sort | uniq

would be

go-coreutils cat file.txt | set 'g;n;p' | go-coreutils sort | go-coreutils uniq

which is twice as long and unwieldy.

I don't think I quite explained that correctly. Doing go-coreutils rm wouldn't be permanent behavior. Just meant for testing before you go-coreutils install --rm and replace the GNU version. I see your point about the performance impact. I didn't think of that.

Thing is, since this project aims to be drop-in compatible, anybody who installs the utilities would probably either a) know what they're doing, or b) have these in lieu of GNU's coreutils (because they're on Windows or want GNU/Linux functionality on BSD, etc.)

Agreed with most people knowing what they're doing if they come here and decide to replace GNU coreutils with go-coreutils. We should still be tactful on how the replacing part is done. It should be relatively easy to replace one with the other.

[ericlagergren]

This is true, but who knows what people do with their PATH.

I guess this means they should be careful when installing go-coreutils and we should be mindful when creating the installer :)

Maybe something like, "These are going to be installed in $GOBIN, etc."

It should be relatively easy to replace one with the other.

Yeah. I was thinking of having options to either delete, rename, or move (to a subfolder) the old GNU coreutils if they chose the overwrite (or whatever it's named) option.

You can only make it so user-friendly though :P

[rdeusser]

Yeah. I was thinking of having options to either delete, rename, or move (to a subfolder) the old GNU coreutils if they chose the overwrite (or whatever it's named) option.

In the spirit of Doctor Who, I vote for "Upgrade" with some output stating they will no longer feel pain, that go-coreutils takes the pain away.

[ericlagergren]

I've actually never watched an episode of Doctor Who in my life, but you're 100% free to add in any quirky lines you want, lol.