Finding the path to a bash script
Often enough, you are writing a bash script and you want to find out where is your script. Here is a reliable and repeatable way to find the directory where your path resides.
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
However, if your script changes directories before calling this, it will get the wrong value. Now let me explain how the script works. BASH_SOURCE[0] will return the relative path of the script from the directory where the script was called. dirname will remove the script name from that. Which at the beginning of the script is the same as pwd. If we go to that directory then we are at the same dir as the script. Executing pwd there will give us the absolute path. And this is what we store in DIR
Visual Diff
Often enough you need a quick and efficient summary of the differences between two files. May be also the ability to chose to move a difference from that file to the other. Try Meld.
Easter egg: try pressing left-ctrl or left-shift while looking at a difference in Meld ;-)
Killing and assassination :D
"kill" is an extremely useful linux command. kill is used to send a signal to a running process. For kill, processes are identified using a process id (pid). It is often useful to combine it with "pidof" which find the pid of a program. For example, "kill `pidof helloworld`" should send a TERM signal to helloworld. Particularly interesting signals are STOP and CONT.
How many times have you run a program and realized it's taking too long, you don't want to kill it, but you want to use your processor for a while, may be to run another shorter program that is more urgently needed, but you don't want ot lose the 10 hours the first program has been running. Just issue, "kill -STOP `pidof program1`". This will cause program1 to go to sleep until you decide you want to wake it up again by "kill -CONT `pidof program1`"
Using asserts
The C language assert function is extremely useful. Using it often within your code to assert your assumptions will always make it easier to debug it later when you try using it in a weird way. The assert will immediately fail and pinpoint the location of where wrong behavior is observed instead of letting things propagate and cause strange failures later.
However, often asserts are annoying especially when they are failing without providing any error message why this assumption is made or why is this assert where it is in the first place. A nice way to circumvent that is to add a string to your assert like this:
assert ((a>=0) && "a negative number cannot be an index of an array");
The assert will work normally as if it didn't have any string, however, when it fails, the failure will include the complete line which shows both the failure condition and your message to the potential debugger of the problem.