maybe you did not spot that this was an “in repository” cleanup. Inside CVS?

So in processing “,v” i.e. RCS files, tabs found can be unrelated to the actual source code (there is the initial node / tree structure before the section with the source)!

I was also reluctant to assume that a file extension guaranteed matching content, and so I checked for binary tags and such.

Significantly, in modifying the RCS files directly, one avoided setting off a chain of events that a checkout / checkin of many thousands of source files would cause.

Oh, it was a one off I wrote for a software house client (with complicated CVS triggers, tagging and release mechanisms)!

And so the “in situ” fix.

The code is a one off and a little messy (just a stream of code until it worked, with on-going client input / changes), plus my brain is rewired by Groovy and Python ;-)

Actually I agree with your find comments (my code started out doing something different) and suggestion about indent, and maybe they will read this discussion!

I still used the same routine (minus RCS handling) on what the developers had in their sandboxes (work areas with source checked out) because it guaranteed that the changes outside of the repository would still match exactly what was now inside that CVS repository (hopefully all was correct, but if an error crept in, at least it would match!).

Does that make the exercise a little more clear? I thought that others just might get such a request and there was no point in my not sharing :-)

# find <code dirs> <find opts> -exec indent <indent opts> \;

Basically, if your code is all written in C, GNU Indent should readily solve all your code-formatting problems.

Here’s its website: http://www.gnu.org/software/indent/

It is not that unusual for a company to force all files to be re-formatted using the indent program as a CVS/SVN pre-commit hook. In fact, I highly recommend that practice.

Next, get to know the ‘find’ command. I see you’re calling it from your perl code, but I can see from what you’re doing with the results that GNU find can do everything you need *without* the extra processing.

Your final program will be reduced to something like this:

# find -exec indent \;

This is a much faster, maintainable, and flexible solution than the program above! This does not in any way belittle your efforts, nor does it call your task trivial... part of becoming a master of these things is learning to do *much* more with less typing, but more thinking.

A little check using that pointer revealed this educational link

http://www.perlmonks.org/?node_id=203941