Update

olekukonko

Any updates on the `todo` ? Its over 2 months now :)

laher

Hi there Oleku, I've just been busy with other stuff this Summer. Hoping to start adding to it again soon. Late last year I got about halfway through making `tar`, and I was also doing some work on the 'scp' command.. I should finish these soon and then look at some more stuff. Is there anything in particular which you're interested in? If you're interesting in collaborating at any level then please go ahead & send a pull request (hopefully the coding guidelines are self-explanatory). If your'e not, no worries, feature requests are still good to hear. Cheers

olekukonko

> Late last year I got about halfway through making tar, and I was also doing some work on the 'scp' command.. I should finish these soon and then look at some more stuff Well done .. hope to see what you would come up with > Is there anything in particular which you're interested in? Nothing in particular at the moment ... > If you're interesting in collaborating at any level then please go ahead & send a pull request (hopefully the coding guidelines are self-explanatory) Sure .... Am reviewing some at the moment would let you know when am ready **Observation Must it by only linux tools, some interesting tools such as `fnotify` , `png compression` , `image format conversion`, `password generators`, `etc` can also be considered

laher

Yeah sure, it can include stuff which doesn't normally exist in Linux, but I'd like it to stick to mimicking existing packages for the moment, be they from Linux, Mac, Windows or whichever. Also, bear in mind that I don't want any cgo (C or C++) dependencies, and preferably minimise use of syscall, because I want it to remain cross-platform and to cross-compile easily. For example, for fnotify you could potentially use the syscall package to call inotify under Linux, and then just keep Stat-ting on other platforms (this would be inefficient for monitoring entire filesystems but fine for single files I guess). Password generators or image converters could be an excellent use case. I'd be inclined to try to mimic things like gif2png, apg, or similar. Cheers

olekukonko

I also prefer strictly `go code` because of the limitations on windows platform. There are plans to add `os/fsnotify` as part of the standard see - [Todo List ](https://docs.google.com/document/d/1s6MxBsLyBG45SRS60a-aM01DmZ4hD1nMzGAKdTopKGY/edit#) - [Go 1.3 os/fsnotify API](https://docs.google.com/document/d/1-GQrFdDVrA57-ce0kbzSth4lQqfOMMRKpih3hPJmvoU/edit#heading=h.7ush6jpv61gf) The implementation would be based on [fsnotify](https://github.com/howeyc/fsnotify) which already has [windows support](https://github.com/howeyc/fsnotify/blob/master/fsnotify_windows.go) See [Watch](https://github.com/eaburns/Watch) for a simple use case where a command is lunched if a file is modified On other comments - [imaging](https://github.com/disintegration/imaging) process images in parallel and very fast. Its all we need for images - `apg` has to many options but am sure we can implement a simplified version - [lossypng](https://github.com/foobaz/lossypng/) Is a good image compression reference - [csv2table](https://github.com/olekukonko/tablewriter/tree/master/csv2table) trivial but i found it to be very useful - Am sore there are so many other useful tools

laher

Hmm, I've been planning on a second repo along the same lines, which might be a better place to put this stuff. Something like 'moreutils' or 'otherutils'. I'm going for [otherutils](https://github.com/laher/otherutils), just because the 'other' command isn't a common linux command. The distinction being that otherutils is more varied in scope (imports various non-core libraries such as these), making it potentially less 'stable' in that it relies on libraries which I have no control over. So, basically 2 distinctions: - otherutils don't necessarily resemble existing executables. They could be anything really. - otherutils can import non-core, 3rd-party, Go libraries - but, otherutils are still 'pure go' commandline executables with a similar convention for commandline options (--help, --version, etc) _The only libraries imported by someutils should be either specifically targetted towards someutils (e.g. wget-go, scp-go, uggo), or under the Google umbrella (e.g. go.net). That way I can keep some control over backward & forward compatibility. (The Go toolchain doesn't allow for version pinning, which makes me nervous)_ So, otherutils could make the most of the 'imaging' library, without wasting time trying to mimic apg or similar Does that sound good to you? If so I'll add you to that repo and you're welcome to start work with that (or just go your own way if you prefer). I'm planning to add a couple of my other projects into 'otherutils' which don't really feel right inside 'someutils', because they're not recognisable as common shell commands.

olekukonko

Sounds very interesting but rather than make it a different `repo` implement it it like the `go tool` where you can have `other name -args` as as the other utils mature then can gradually stand alone or better still all utils are available via `utils name -arg` but on linux command also has a stand alone version but can also be accessed via `utils` just like `gofmt` and `go fmt` What do you think ?

laher

Hi, are you aware that someutils already has a command called 'some' whereby you can call `some ls` etc? So, it's already just like you described. 'other' is theoretically along the same lines, the distinction being about project scope - someutils being limited to _familiar_ CLI utilities along the lines of 'coreutils'. i.e. it must resemble a command commonly found on one of the target platforms. Idea: instead of 'otherutils', you could make a repo yourself (e.g. 'olekutils'/manyutils/alltheutilsarebelongtous) which `import`s all of someutils, plus whatever other utilities you want to add in, setting your own scope as you please. Your users would not need to explicitly install someutils itself, just olekutils. The code for wrapping someutils would be very straightforward. Just `import` and call the relevant util function as I have done. Hope that works for you. Cheers, On Thu, Feb 20, 2014 at 5:50 AM, Oleku Konko [email protected]: > Sounds very interesting but rather than make it a different repoimplement it it like the go > tool where you can have > > other name -args > > as as the other utils mature then can gradually stand alone or better > still all utils are available via > > utils name -arg > > but on linux command also has a stand alone version but can also be > accessed via utils just like gofmt and go fmt > > What do you think ? > > ## > > Reply to this email directly or view it on GitHubhttps://github.com/laher/someutils/issues/1#issuecomment-35520047 > .

olekukonko

> Hi, are you aware that someutils already has a command called 'some' > whereby you can call `some ls` etc I was not aware ... that is cool > Instead of 'otherutils', you could make a repo yourself Yours is more comprehensive , they are too small to make a set of tools Lastly you might want to consider [go-diff](https://github.com/sergi/go-diff) based on Myer's diff algorithm for `diff`