Btw, I totally want that machine! All I have here to test my multi threaded apps is an ancient Sun-Fire-880 with four 750MHz CPU’s and just a bit over 8GB of RAM .

But you’re right - with a fast CPU it doesn’t really matter if you grep the cat or not. Still even with unlimited resources greping the file directly instead of greping the cat is less typing.

As far as “grepping the cat”, when you are running a Sun V1280 with twelve 1.2 GHz SPARC III cu processors and 80 GB of RAM, those two microseconds you save are not really going to be of value later . . .

If resources are the scarce, you really need to go back to C and drop Java . . .

for(int i=0; i<a.lenght; i++)
{
sum += i;
}

On the other hand someone using the K&R style would write the same snippet of code like this:

for(int i=0; i<a.lenght; i++) {
sum += i;
}

This means that I gain 1 line of code per each block of code that requires a brace. Every loop, every if statement, every try statement, every method and class declaration will be always 1 line longer for me. The bigger the project, the more this adds up to my line count.

Our code can be semantically equivalent, and it can compile to the same exact set of assembler instructions. But my line count will be higher simply because of a visual formating choice that I made.

This makes for a very poor metric. Of course so is counting methods, classes, variables and etc. There is just no very good ways to measure progress and performance other than accomplishing set goals at the desired deadlines.

That’s why at the beginning of this post I said that I never really cared how many lines my code had - because it didn’t really mean anything. But when I tell people about the project they keep asking me about the line count.

Some unix commands will only work with stdin, but many are able to access files on their own. Grep is probably most notorious for this:

1. grep foo bar.txt # fast
2. grep foo | cat bar.txt # slow

Many people will use #2 by habit, when #1 is much faster and actually easier to type. I remember this because we would always use to joke about this:

“Stop greping the cat you pervert!”
“Leave the poor cat alone dude!”
“Did you just pipe the cat? I’m gonna call animal services!”

So yeah - every time I see cat in a script I start looking for alternate solution to rescue the poor kitty form the pipe abuse.

Btw, I always forget the syntax of the bash loops and have to look it up. It also doesn’t help that I spent a lot of time in tcsh on one of the unix stations at school - and tcsh loops are widely different from bash loops.

*reads man page for wc*

Doy! I keep thinking that only the shell can resolve multiple via wildcards versus the output of the command in the back ticks.

Maybe I just like showing off running for loops in a command line . . .

Yours will also work, but I think the cat step will make it a tad slower.

Oh, and by recursive I kinda meant “recurse into subdirectories”.

Try this one for size . . .

for file in `find . -name \*.java -type f`; do \
cat $file; done | wc -l


This will count the total number of lines in all the *.java files, not just how many *.java files there are.