<p><pre><code> find ~/my/docs/ -type f -name '*.txt' -exec sed -i.bak 's/inheritance/composition/g' {} +
</code></pre>
This will search all files ending in `.txt` and will exec `sed 's/inheritance/composition/g'` on it. Sed modifies files in-place and saves a backup file with .bak extension (-i.bak) and is called the minimum necessary times (-exec +).<p>My best advice to someone using the command line is to learn `find` + `xargs` or, even better, `find` + `parallel`.
Okay, so what I learnt from this:<p>1. You've imported droundy/goopt, wsxiaoys/terminal really easily. The first provides option-parsing, and the second provides helpers for emitting ANSI escape codes.<p>2. Practically everything is overloaded. You can == to strcmp(), + to concatenate strings.<p>3. path/filepath gives you some nice goodies for path manipulation. But you have to deal with the fallouts of making naive assumptions like whether or not to recurse symlinks (why isn't this a flag in filepath.Walk?). This has resulted in ugliness in your walkFunc callback.<p>4. You have been able to abstract quite a bit without using Java-like factories, although your inconsistent error passing has me somewhat confused.<p>5. Since it's so strongly typed and there are no raw pointers, it's not going to be hard to debug at all.<p>Overall, I'd say Go is an effective language. But not beautiful, or novel in the slightest. It resembles Algol-68 (yes, a 1968 language) quite strongly, and I don't think it will drive compiler technology. Their syntax is specifically engineered to be parseable quickly (and hence super-fast AOT compilation): what the final program looks like is secondary concern. I'm not sure I see the appeal.<p>[edit: clarified that the note on compiler technology was an opinion]
Nice! svn support would be useful (ignore .svn directories) and the -r option is easy to remember, but perhaps not so much in line with the already messy standard Unix options (-r or -R for recursive operation).<p>Note that specifically for Go source code, there is "go fix -r" for syntax/context-aware code replacement (see "godoc fix").
For x86 binaries:<p>go get github.com/piranha/goreplace<p>go install github.com/piranha/goreplace<p>is another way to get it if you have GO and GOPATH set up.<p>I personally aliased it to 'gor' in my zshrc as the git plugin already occupied the 'gr' (short for git remote).
I really like Facebook's codemod.py for stuff like that: <a href="https://github.com/facebook/codemod" rel="nofollow">https://github.com/facebook/codemod</a><p>It has something like automatic and manual modes, so you can check (and fix) every diff during the replacement
This isn't working for me. I get:<p><pre><code> C:\Users\swah\docs>gr TEST
panic: Given path should be anchored at /
goroutine 1 [running]:
main.NewIgnorer(0xc08005bcf0, 0x29, 0x0, 0x0, 0x140110, ...)
/Users/piranha/dev/go/src/goreplace/ignore.go:32 +0xa4
main.main()
/Users/piranha/dev/go/src/goreplace/goreplace.go:62 +0x1b7
goroutine 2 [runnable]:
</code></pre>
[edit] New version is working!