Linux LOC

[mai]

Hi, Does anybody know the approximate number of Lines of codes in Linux (the Linux, not the RedHat or any other distribution's) now? or does anybody know where I can find such information? Thank's.

Maida :)

[mdwatts]

I assume you mean the kernel. Best place to find out (if possible) would be www.kernel.org or you could contact one of the kernel developers by posting in the kernel mailing list or usergroup.

Check the kernel FAQ's at the above site.

[Ludootje]

download the kernel, than do 'wc -l'. 'wc' stands for word count, but with the '-l' (lines) option it counts the lines. Since files are in subdirs, I suppose you need something like this:
for codefile in $(ls -r); do wc -l $codefile; done
Then you'd still need to count all the lines for each and it would include the comments, so this is better:
for codefile in $(ls -r); do cat $codefile |grep -v "^//" | grep . | wc -l; done

All comments put between */ won't be grepped out however. You'd need some regular expression magic to do that (which I don't know good enough to do it).

You need to do this in the main dir of the kernel tree, of course. So you just unbzip2 it, cd to it and run that command.
BTW I'm not sure it'll work since I didn't test it.

[Ludootje]

just of this while formulating a grep in the programming forum :)
this is probably better:
for codefile in $(ls -r); do cat $codefile |grep -v "^// " | grep . | wc -l; done
what I did was add space after ^//. I don't know if when you start a line in C with //something, whether it'll be considered as a comment or if this can be actually be code. with this one you're sure. You'll still include some comments though. (with the /* stuff). Normally it should work, the only thing I don't know for sure is whether "grep ." is correct or not, can't remember that.

edit: just looked at http://www.rahul.net/cgi-bin/userbin/man?topic=grep&section=1, the "grep ." is correct.

[bwkaz]

Originally posted by Ludootje
for codefile in $(ls -r); do cat $codefile |grep -v "^// " | grep . | wc -l; done Better yet:

find . | while read codefile ; do grep -v '[[:space:]]*//' "$codefile" | grep . ; done | wc -l Differences:

(1) You don't need to waste another process catting $codefile when you can use $codefile as one of the arguments to grep.

(2) Quotes around files that may have spaces in their names. Also change the for loop, because the other way, if spaces exist in a file's path, it'll show up as two separate "words" to the for loop.

(3) The // doesn't have to be at the beginning of a line; it can have any amount of whitespace before it. I still haven't figured a way to exclude stuff between /* and */, though, because it might cross line boundaries... Unfortunately, the /* ... */ type are probably infinitely more common in the kernel...

(4) Pipe the whole for loop through wc -l rather than each file. This way, you don't have to manually add numbers together.

Run on a configured kernel 2.4.20 plus the Alsa tree, I get 4542576. But again, that's including a whole ton of /* ... */ comments, so it's probably closer to 4 million.

[Ludootje]

Originally posted by bwkaz
Better yet:

find . | while read codefile ; do grep -v '[[:space:]]*//' "$codefile" | grep . ; done | wc -l Differences:

(1) You don't need to waste another process catting $codefile when you can use $codefile as one of the arguments to grep.

(2) Quotes around files that may have spaces in their names. Also change the for loop, because the other way, if spaces exist in a file's path, it'll show up as two separate "words" to the for loop.

(3) The // doesn't have to be at the beginning of a line; it can have any amount of whitespace before it. I still haven't figured a way to exclude stuff between /* and */, though, because it might cross line boundaries... Unfortunately, the /* ... */ type are probably infinitely more common in the kernel...

(4) Pipe the whole for loop through wc -l rather than each file. This way, you don't have to manually add numbers together.

Run on a configured kernel 2.4.20 plus the Alsa tree, I get 4542576. But again, that's including a whole ton of /* ... */ comments, so it's probably closer to 4 million.
1. is a good point, didn't think about that :)
2. I don't think many (if any) files have spaces in the Linux kernel tree, but it's possible I guess
3. actually I read that // is for C++ and is a mistake in C (although gcc does accept it), so you're right about the */ /*. can't figure out a way myself for the */ /*
4. with the last script, I don't think you need to manually add them either.

One problem I thought of: we need a *.[h|c] as the name, otherwise the docs get counted too. So:
for codefile in $(ls -r | grep "[h|c]$"); do cat $codefile |grep -v "^// " | grep . | wc -l; done
or
find . -name *.[h|c] | while read codefile ; do grep -v '[[:space:]]*//' "$codefile" | grep . ; done | wc -l
don't know enough of find to know if -name *.[h|c] will work.

[Ludootje]

Here's a way for the /* and */.
for codefile in $(ls -r | grep "[h|c]$"); do cat $codefile | grep -v "^// " | grep -v "/\*.*\*/" | grep . | wc -l; done
With this one, it should work perfectly.
btw because of the 'cat' everything seems like one big file to 'wc', so you don't need to add the number afaik (didn't test it though)
Could someone who has an unpacked kernel (I don't have the space for it ATM) test it please?

edit: and here's an adapted version of the find:
find . -name *.[h|c] | while read codefile ; do grep -v '[[:space:]]*//' "$codefile" | grep . | grep -v "/\*.*\*/" ; done | wc -l

Could you please explain the :space: thing? I never saw that before

[bwkaz]

Originally posted by Ludootje
btw because of the 'cat' everything seems like one big file to 'wc', so you don't need to add the number afaik (didn't test it though) I haven't either, but seeing as 'wc' is inside your for loop, it will get run separately for each file that the loop iterates over...

Could you please explain the :space: thing? I never saw that before It's a regex thing meaning "any whitespace characters". The outside set of brackets are just to set it off, more or less (they're the same as you'd use if you were searching for, for example, [ch], which matches either c or h), and the inside set of brackets introduces a "character class". The :space: is to tell grep which character class this is, i.e. all space-type characters. You can also use, for example, [[:alnum:]], which is equivalent to [A-Za-z0-9] (any alphanumeric character), IIRC. There are others.

The star after it is just like a star in any regex.

BTW -- your [c|h] thing in find will work, sort of. It'll also match files that end in .| (that is, dot-pipe), though. You shouldn't have the | character there; glob expansion takes [ch] to mean the same as regex expansion would. find . -name '*.[ch]' will do what you intend (the single quotes are to prevent wildcard expansion before find starts looking).

What I don't know is whether your regex to exclude /* ... */ comments will work. It'll definitely work if the comment is only on one line, but if it's like this:

/* this is a multi-
line comment... */ then I'm not so sure it'll match. Because AFAIK, grep works per-line, and you can't match an embedded newline...

[Ludootje]

Originally posted by bwkaz
Because AFAIK, grep works per-line, and you can't match an embedded newline...
You're right, it doesn't work. Just tested it on a simple textfile, it doesn't work.
Thanks for explaining the :space: thing :)