grep-ing your way to glory!

Grep is oxygen. Also, Grep is a very very powerful content search tool found on Unix-based systems.

Basic Syntax:
>> grep [options] [pattern] [files to be searched]
eg. >> grep -r Hello .
(Grep the current directory for the string "Hello". Make the search recursive i.e. search within sub-directories too)

grep searches in all files. Even binary files. This can sometimes be irritating, since results from binary files are seldom useful. Pass a "-I" ignore binary files. (grep examines the first few of the file to determine whether the file is binary or ASCII. extensions are NOT used)

Also, you may want to ignore case. Use "-i"

By default, the format of printing the output is
"[path-to-file]: [line containing the matching pattern]"
Sometimes it might be useful to alter this pattern.
Use
1) "-n" to display the line number in the file where a match was found
2) "-o" to show only the matching text and NOT the entire line.
3) "-C [num of lines]" to show the context (before and after)
4) "--color" to show the matching pattern in color.


Also, sometimes you might be interested in only the number of matching lines. use "-c".

Another VERY useful option is "invert-match" (i.e. select non-matching lines)
use "-v".
eg. >> grep -v -e "^#" my.c
(i.e. select all lines that do NOT start with a #)

grep can take only basic regular expressions. Use "-e" to pass an expression which uses the extended regex format.

These are pretty much the frequently used options. man grep for more options.

Some Grep usage scenarios:
grep alongwith piping makes a great combo!
you can say something like
>> find . -name "*.c" | xargs grep -in Hello
to search only C files within a directory.
Or you can say
>> find . -name "*.c" | grep hello | grep -v not_welcome
to find a filename containing the string "hello" in it but NOT "not_welcome" !!

NOTES:
1) I purposely havn't talked about regular expressions. They are worthwhile to learn since they are required everywhere, not only for grep. With a good knowledge of regular expressions, grep is awesomely powerful!
2) grep is slow. Understandable. since it is content search!
3) Are more examples required? Let me know!

PS:
So, grep is used for search. But, what about search and replace?
Well, use "sed" for that. sed is good! (sed has saved me loads and loads of time. It is good to know atleast basic sed)
A nice tutorial can be found here.

EOF

So what is so great about find?

Why do people not like find? It is a nice command to have. I gather that there is no "find" in BSD and that find is "impure" (I am not sure about both) Well, frankly, it makes no difference to me, as a user, whether a command is pure or impure. Find is a simple slick and helpful command and that is what I care about. As for BSD, get the sources and compile!

LOCATE:
Anyway, there is an alternative to find (albeit lame). It is "locate".
Basic syntax :

>> locate [pattern]

(Don't mind the square brackets. '<' brackets makes google think that I am writing some xml doc. So, a quick fix) Locate merely searches the database of names that was created by "updatedb" command. updatedb is periodically scheduled by crond. So, your database is automatically updated. You don't need to worry about that. One advantage of this approach is that the search is lightning fast. If you compare the performance of locate and find, locate would win by light years! Also, the syntax of locate is deceptively simple. Merely, "locate {pattern}"
But, as every girl you like is always taken, locate has its own drawbacks.

1) locate command doesn't check whether the file actually exists on your machine. It simply consults the database and gives back the results. (Thus, after an updatedb, you delete a file, you still get it in the locate results until crond schedules another updatedb). You can pass "-e" to locate to avoid this condition. -e checks whether the file actually exists.

2) If you create a new file, it won't appear in the locate results for a while. (Until crond schedules an updatedb)

3) There is no way you can ask locate to search only within a particular directory. You have to search the entire directory tree, always. This, in my opinion, is the worst drawback of locate.

Some other options that could be passed to locate:
-i : ignore case
-b : match basename only. (i.e. the final component of the whole name)
-e : check if file exists
-E : print only files that do not exist, but were there when database was made.


FIND:
Find is good.
With find you can search a part of the direcotry tree. The basic syntax is

>> find [directory to search in] [options]

eg. >> find . -name "Linux"
the beauty of the command is that, you can have many many search parameters. Like:
1) -name [pattern]
Search name of the file
2) -user [username]
Search for files owned by this particular user
3) -perm -{octal permission bits}
Search for files with this permissions.
4) -type [c]
Search for files only of type . (eg. b for block. p for pipe etc etc)
and many more. Check out the man page. You can combine the above options.
eg. >> find . -name "Linux" -user httpd

Also, with find the expression part can be "expression" "!expr" "expr or expr" "expr and expr" etc etc. Quite handy!

What more? You can format your output as per you wish. check the -print option in the find man page. Havn't found the need to use this one, but such options are good for writing scripts.

When you search in "/", find unecessarily searches the mounted windows paritions too? No prob, pass "-mount" and it won't !! It'll skip all mounts.

With find, you can have more control over the search. But the downside is that find is terribly and horribly slow.


As a third lame option. You can define an alias. Something like

>> alias myfind='updatedb; locate'

So, "myfind" becomes a new command which expands to 'updatedb; locate'. Neat, eh?
although, the overhead of updatedb might not always be acceptable. In those cases, you can simply use locate. updatedb, btw, is NOT very slow. So, it is a better option than find, if you don't want too tight a control on your search.

Enjoy searching!!

(PS: Lookout for the next post on grep)

Emacs v/s vi !

While looking for a comparison among the editors I stumbled across these. Great!!
(Both emacs and vi are great and masochistic. Both of them have a steep learning curve but equally great are their uses. You can find a good comparison here.)

Emacs and vi have been involved in a never-ending holy war since ages. All of the verbal battles involve critisizing the people using the editor. I love such wars! :D. Yes. What with all the insulting and swearing :D. Here is a sample....

LOL ----->>

How to ask questions?

n00bs often get frustrated when they start using Linux. Partly because it is very different than Windows and partly because they lack patience. Patience to figure out what is not working and why it is not working. Patience to learn. They want quick answers and so they turn to forums and mailing lists. We have seen hundreds of stupid posts/mails which go something like this - "I can't get xyz working. Help me. NOW!".

One thing we all should understand is the people who made the software are not your servants. You should be thankful they opted to share their effort for free. Isn't it your responsibility to atleast try somethings out before wasting their precious time?? You get to learn a lot in the process too. Its a win-win situation!!

So, before posting any question to a mailing list/forum please make sure thatyou have done your best but couldn't find the solution. (Google. Ask around. Have a look at the debugging output) Let others know what you have tried. Write it in your mail/post. Be respectful and humble.

There is a nice document which documents this particular aspect. You can find it here.

Happy getting-things-to-work!!! :D

Nothing technical about it !!

So, we are supposed to mail our status reports each week to our manager. One of the guys (some people have a good good idea who he is !!) wrote this in his status report:

Tasks this week:
* Worked on "one build to rule them all" infrastructure


And bang came the reply from the manager:

Three Builds for the Linux-kings in the MSI,
Seven for the SQA-lords in their shield-halls of stone,
Nine for MIPL Mortal Men doomed to code,
One for the Dark Lord Kedar on his Bamboo throne

In the Land of Linux where the RPMs lie.
One Build to rule them all, One Build to find them,
One Build to bring them all and in the flash-ness bind them
In the Land of Linux where the RPMs lie.


Need I say more?

Coding Style...

No technical blog can start without commenting on the coding style. 90% of the times the code written by you would have to be understood by a third person who will enhance or maintain it. (The other 10% being college assignments.. even there the code has to be understood by MANY third people :P). So, wouldn't it be nice if your code was easily understandable and readable?

You will understand the importance of coding style once you start studying code written by others. Some get so frustrated that they re-indent the entire code base (:P) which leads to worse problems!! :P. So, better write understandable code. Coding is an art and an art is nothing without presentation!

A very good guide to coding style can be found in the linux kernel documentation.
Just check out Documentation/CodingStyle in the Linux kernel sources. Remember that this coding style is recommended by people who have written/maintained millions of LOC. It has to be the best. And it is!

The file also provides a configuration to be integrated with emacs so that emacs does some of the things automatically for you. Emacs is great!

Welcome to the world where we like to speak quality C !! :)

The traditional post....

As is the tradition, the first post of any blog always explains what the blog is going to be about. And as is the tradition, the blog is never about it !!

We'll stick to the tradition.
So here goes.
The blog will contain posts that I don't think are fit for my other blogs. My experiences and Humour. Basically everything that people don't think is fun. I won't say that I agree with them, but I can understand. Some things are better left to geniuses :P:D.
Anyway, expect technical or atleast no non-technical posts from this blog!

And have fun!
Amen!