Making your vi for default settings

If you want your vi editor to load with default settings (i.e) the line number to be displayed and also tabspace to set for 4 characters.

Here the way to do...

create a file ~/.exrc with settings

set nu
set tabstop=3

Then opening the vi will have these settings common for all.

More about MySQL

MySQL has two types of engine
1) InnoDB
2) MyISAM.

The difference b/w the above two is, former supports the subquery, constraints etc... but the later won't support those. This causes the MyISAM tables relatively faster during retrieval when compared to InnoDB. But the problem is the constraint check and subquery are not applicable in it.

Related to performance engineering.

How to find the total rows processed when executing an query and other infrmation.

use, explain query
(i.e) explain select * from table.

Related to mysql dump

How to see the create table script of an existing table ?

use, show create table &lt table_name &gt
(i.e) show create table &lt table_name &gt

Related to process

How to find the process id executing in mysql when you run a query? (i.e) Executing an query from the java client will create a process in background.

use, show processlist

SSH key generation

We will be ended up by re entering the password when ever we connect to a remote machine using ssh.

Here is the way to avoid re entering the password each and every time by generating a key pair Id and moving to remote machine only once.

ssh-keygen -t dsa

Generating public/private dsa key pair.

Enter file in which to save the key (/home/localuser/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/localuser/.ssh/id_dsa.
Your public key has been saved in /home/localuser/.ssh/id_dsa.pub.
The key fingerprint is:
93:58:20:56:72:d7:bd:14:86:9f:42:aa:82:3d:f8:e5 localuser@mybox.home.com

scp ~/.ssh/id_dsa.pub username@remotemachine:.ssh/authorized_keys


login to remote machine

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Power of Shell Script

Scripts makes the job more easy !

Below is the sample script which I wrote to retrieve the count of files modified for all the modified dates in home directory. This script also gives the sum of bytes for files modified on the corresponding dates.

prakash@prakash-laptop:~$ for filedate in `ls -l | awk '{print $6}' | sort | uniq -c | awk '{print $2}'`;do ls -l | grep $filedate | awk 'BEGIN{print "----------------------------"} {count+=1;sum+=$5} END{print $6" | " count " | " sum }' ; done


Sample Output
----------------------------
Date | Count | Sum of bytes
----------------------------
2007-10-30 | 1 | 26
----------------------------
2007-11-21 | 1 | 4096
----------------------------
2008-02-06 | 1 | 332341
----------------------------
2008-02-25 | 2 | 8192
----------------------------
2008-03-03 | 1 | 999
----------------------------
2008-03-04 | 1 | 219
----------------------------
2008-03-05 | 1 | 3402
----------------------------
2008-03-06 | 2 | 739209
----------------------------
2008-03-11 | 4 | 6648
----------------------------
2008-03-14 | 10 | 50918
----------------------------
2008-03-15 | 4 | 106573
----------------------------
2008-03-16 | 1 | 10635


Really the scripting makes your job more easy.

Ignoring Unix signals

Here is the interesting small C program I came across to ignore the unix signals!. Basically I'm a Java programmer, so this small C impressed me a lot :)

Below program ignores the CTRL + C signal,

test.c

#include < stdio.h >
#include < signal.h >


main()
{
signal(SIGINT,SIG_IGN);
while(1)
printf("You can't kill me with SIGINT anymore, dude\n");
return 0;
}


gcc test.c -o testout
./testout

Running the above program completely ignores the CRTL + C command and keep on running with out aborting. CRTL + C sends the SIGINT signal and we ignore that in program.

UNIX SIGNALS

THE UNIX SIGNALS are used for communicating the process when ever the event has occurred.

When ever you give CRTL + C on the running process or kill on the running process id, the signals are sent to process to notify the event.

There are about 64 signals and can be viewed using kill -l.

When you press CRTL + C , by default SIGINT is sent to the running process,
When you press CRTL + Z , by default SINTSTP is sent to the running process,
When you press CRTL + / , by default SIGABRT is sent to the running process.

Think when some one press CTRL + C when your program is half the way, you are going to end up with non cleaned up resource, this is because you do'nt have handler over the SIGINT in our program.

You can write the handler for CRTL + C using trap as follows to get the control. You cannot get the handler for SIGKILL and SIGSTOP. These two signals cannot be caught while other can be.

test.sh

!/bin/bash

trap "echo 'This is trap executing for 0!'; exit 0" 0
trap "echo 'This is trap executing for SIGINT!'; exit 1" SIGINT
trap "echo 'This is trap executing for SIGKILL!'; exit 1" SIGKILL
trap "echo 'This is trap executing for SIGTERM!'; exit 1" SIGTERM
trap "echo 'This is trap executing for SIGABRT!'; exit 1" SIGABRT

echo "We are running the script. Press Ctrl-C to cause trap to execute!"

read

We can also send the signals during kill using pid.

For EX:
kill -15 pid,

The above command will send the SIGTERM signal to the pid before terminating. So you can do your clean up logic by handling the signal in your program.

Using kill -9 pid,

the above command will send the SIGKILL signal but it cannot be caught by the program, this is also similar to SIGSTOP that cannot be caught too.

So it's advisable to use the SIGTERM to kill the process and then the SIGKILL as we can caught the SIGTERM signal for our operations and the SIGKILL cannot be.

The Recommended order of killing the process id is

kill_pid () {
PID=$1
RETVAL=0

for signal in "TERM" "INT" "HUP" "KILL"; do
kill -$signal $PID
RETVAL=$?
[ $RETVAL -eq 0 ] && break
echo "warning: kill failed: pid=$PID, signal=$signal" >&2
sleep 1
done

return $RETVAL
}

kill_pid 1234

How to find processor 32 bit or 64 bit

Some time you may need to know what bit your processor uses, for installing the packages.

Here is the way you can use to find the information.

getconf LONG_BIT

uname -m

(x86_64 GNU/Linux indicates you have 64bit CPU. If you use see i386/i486/i586/i686 then it is a 32 bit CPU.)