For someone not as steeped in shell programming as I am, it might have easier to accomplish in Perl, Python, or even C or Java. However, when evaluating what is the right tool for the job, we have to assume some high level of knowledge of the available tools. I happen to know all of the above tools and I’m pretty certain that shell was the right way to go here. (I’d love to see a different approach that proved me wrong, however!)

Interestingly, your argument for using shell instead of C is basically the same one for using Python or Ruby instead of Java, C#, etc.

I prototyped the above command, literally, in ten minutes start-to-finish and then emailed out the results to my team. Rather than having to fire up an editor and deal with a compile/run/edit loop I was editing and running a command line: hit up arrow, edit line, hit enter. Lather, rinse, repeat until you see what you want.

And there’s another point to remember: I don’t even know (offhand) how do to do this in a compiled language. Writing that utility would require me to understand the API that’s available for each of those tools. Subversion has a public API, and there are countless regex libraries for every language, but I’m not sure how one would do the diff using library code (a cursory Google search didn’t show anything too promising). All of which is not to say that I have a fear of learning a new API, but I already know how to use these tools as using them is core part of what I do. Learning the Subversion API and reimplementing diff is not.

And finally: writing a compiled solution would require a lot more code (even assuming that you wouldn’t have to re-implement diff). Note that the pipeline is only 42 words and 269 characters long. Even if you were to implement the pipeline as nothing more than system() calls so you could leverage the power of grep and diff, you’d still end up with a program at least three times the size.

So it ends up being a net win in efficiency; the iteration speed and compactness are pretty key. The time for it to run is about 3 seconds. The time to develop a minimal compiled solution is about 30 minutes. 20 * 60 / 3 = 400. So I get to run it about 400 times before this solution costs me anything over a compiled solution. And I get to keep the flexibility editing the command line to tweak what I want to see in the report. (Exercise for the reader: add timestamps to the report lines that indicate the last modified time).

So while I agree that the shell is slow at times, it’s often the fastest route to getting the information you seek.