Adding/Removing stuff from start-up

Its a wonder how frequently we need to add stuff to the start-up and yet we prefer the hard-ass manual way. You can lose hours if you forget to do one small thing (eg. one of my builds, which takes 2 hours on an average, failed merely because I forgot to start httpd.) Thats when I considered this start-up thing seriously.

1) Adding/Removing services:
In very (very) loose terms, services comprise of everything under /etc/init.d directory. (Files under this directory are scripts that manage starting, stopping, restarting and status reporting of the services). The 'chkconfig' command is used to Add/remove these services from the start-up. These can be done per-runlevel too. (Just pass a suitable '--level' option)
eg. To start httpd on startup. Just type
>> chkconfig httpd on
(To remove httpd from startup, replace 'on' with 'off')
(Syntax ==>> chkconfig {service-name} on/off)


(To add a script to be managed by chkconfig, just copy the script to /etc/init.d directory and run
>> chkconfig --add {name}
This creates links in /etc/rc[0-6].d directories. Scripts in these directories are run each time the run-level is switched (provided that the service isn't already running))

Type in 'chkconfig --list' to get a nice summary of the status of services at each runlevel.


2) Initializing environment variables at start-up:
Just add an "export name=value" command to ~/bash_profile file. (Create the file if it isn't already there). Note that this would be a per-user initialization.
To initialize an environment variable globally, add an entry to the /etc/profile file.


3) Initializing aliases:
Add a "alias name=value" to ~/bashrc file. Create the file if it isn't already present.
/etc/bashrc file if you need global changes.


4) Random stuff in start-up:
What if you want to run a random command at start-up? (eg. Flushing ip-tables). In fedora you can add the commands to /etc/rc.d/rc.local file. But, the file is distro dependant. Most probably, you'll find the appropriate file in /etc/rc.d directory.

Hope it helps!

Patching....

Before we delve into applying patches, let us have a look at a sample patch file.


--- old_test 2008-12-07 15:43:27.000000000 +0530
+++ new_test 2008-12-07 15:43:39.000000000 +0530
@@ -1,5 +1,6 @@
This
is
+also
a
test
file


The first line gives details about the original file and the second line about the modified file.
Then "@@ -1,5 +1,6 @@" marks the beginning of the hunk. This line tells the patch command where, in the file-to-be-patched should it find the specified change.

The line prefixed by "+" is the line that was added in the modified version. Other lines constitute the context.

Now why is context important?
Here's why. Consider this scenario. You work on this amazing new idea on a file called blah.c. At the same time, another of your friend modifies the same file to implement his crazy new idea. So, would your patch not apply to your friend's version of blah.c?
Chances are, it will!.. because patch tries to find the same "context" in the neighbourhood of the original line numbers. If it does, patch applies successfully!... Now this is what makes patches a good idea!.. DISTRIBUTED DEVELOPMENT!

So, coming back to the patch command,
>> patch -pNUM < patch-file

Note that patch reads the patch file from the standard input. So, you have to redirect the standard input to the patch file.

the -p option is used to specify number of components to strip.
Here's a line from a patch file. Lets take it up as an example to understand the -p option
diff --git a/wlan/driver/linux/some-name.c b/wlan/driver/linux/some-name.c

the -p option works on the path "a/wlan/driver/linux/some-name.c".
with -p1 : it strips one element from the LHS of the path. Thus, it will try to find "wlan" directory in the current directory.

with, -p2 : patch will strip the first 2 components. i.e. "a" and "wlan" and it will try to find "driver" directory in the current directory.

and so on.
If you don't give a -p option, -p1 is used by default.


Unapplying patches:
It is possible that you applied a wrong patch to your code. Or you find out after applying the patch that the damn thing is not going to work. Or there is a regression. Whatever. The point is, you want to revert the patch.

Just pass a "-R" option to patch and it will try to unapply the patch. Although, do read the man page carefully before using this option.


Random notes on the patch command:
1) Use the strip-level option (-p) properly. If patch command doesn't find the file to be patched, chances are that you have specified an improper strip level option. (In that case, patch becomes interactive and asks you the path of the file to be patched. Most of the times, it means that you need to correct the strip-level option. so, exit with ctrl+c and give the correct strip level)

2) In case, one of the hunk fails (Which is the case when, the original file is modified by someone else prior to applying the patch and there is a conflict), the hunk that failed is saved in the "filename.rej" file. You need to apply that change manually. Just open the .rej file, see which hunk failed and make the changes manually. Also, the original version of the file is saved in filename.orig, just in-case you changed your mind or you are just too lazy to do the hard-work.

3) A patch is a defacto standard to give out changes like bug-fixes, minor feature additions, security patches etc. Patches are extensively used when a team is working on the same workspace (which is almost always the case). Revision control softwares like git, SVN, CVS, perforce, etc all support patches extensively in all their operations.
Patches are something you really want to know!

Hope it helped!

Diff and Patch

Patches show the difference between two versions of the same file.
A patch shows which lines were newly added and which lines were removed. What makes a patch very useful is that a patch can be applied to the old version of the file to obtain a new version.
i.e. (old version) X (Patch) = (new version)

This fact makes it easy to manage a community software where a software is open-source and anyone can submit changes. Trust me on this, without patches we would be nowhere.
For eg, Andrew Morton (Linux kernel maintainer) gets hundreds of patches everyday. In the absence of patches, he would have to integrate each and every change manually which would be a VERY time consuming and an inaccurate process. Patches automise this job.

"Diff" is used to create patches and "patch" is used to apply it.


Diff:
syntax
>> diff [options] [original version] [modified version]
Generally, I used the diff command with "-du" options.
eg. diff -du old_test.c new_test.c > test.patch

Note that diff produces output on the stdout and you'll have to redirect it to a file.
Options:
-d : Use an algorithm which will produce smaller set of differences
-u : Use unified output format
(-u causes newly added lines to be prefixed by "+" and removed lines prefixed by "-". Otherwise, other prefixes are used which people generally dislike :)

-r : recursive.
Now this is a beauty. You can find differences between all files under a directory. So, if you have changed multiple files, use this option to generate only ONE patch and _not_ a patch for each file separately.

-N : Include new files
With -r, it is possible that you might have added a new file in the newer version of the software which wasn't there in the old version. Diff by default ignores such files. Use this option to change this default behaviour.

Random notes on patches:
1) In patch files, you will find something called hunks. Hunks are a set of changes alongwith some context. By default, 5 lines above the change and 5 lines below the change constitute the context. View a patch file in emacs/vim and you'll know what I am talking about. Context is a very important part of the patch file. I'll come back to it when I talk about applying patches.

2) The beauty of patch files is that you can actually MODIFY them. Well, it won't seem to be a big deal if you havn't used patch much. But, it is a quite handy trick. You can remove entire hunks and the patch is still valid!
So, play around with it a bit.

3) Many people and inherently afraid of patches. Trust me they'll have a very hard time when they work in a group on a single project. Patches are a great way to review changes that have been made or pass them on to others. Without patches, I cannot concieve a way I'll pass on my changes to others!
Patches are very easy to use. Just try and get comfortable with them. Ask around if you think you are stuck.

Now that we know how to generate patches, it is time to move ahead and learn how to apply these patches.
But, I think this post is long enough. So, I'll write about it in the next post.

(Do leave a comment and let me know if I need to add/remove/modify anything to make the post lucid and easily understandable yet comprehensive)