Change the Gnome Commander default editor
The default editor for Gnome Commander is geit. Of cause gedit is good enough, but I prefer to VIM.
The changing of preferred programs in Gnome Commander seems broken somehow. It simply does not work.
Since Gnome is following the standard of handling mime types, we can still update the mime settings to choose the preferred editor.
The preferred applicaiton configuration file is located in ~/.local/share/applications, the file name is defaults.list.
Here is the content of my default.list
[Default Applications] text/html=gvim.desktop application/xml=gvim.desktop text/plain=gvim.desktop text/x-java=gvim.desktop text/x-python=gvim.desktop
As you may guess, I open all the html, xml, text, java and python file with GVIM.
The gvim.desktop is the configuration for gvim for what mime types it can handle and its launching command.
Bubble sort algorithm dance
Hey, I really love this show. Great Job. Just Enjoy. 
Fix unknown virtual device error for launching android emulator
The problem is after the avd be created successfully, the emulator.exe launching ends up by error 'unknown virtual device name: your-avd-name'.
I think this error is caused by I moved my Documents folder to "D:\paul\My Docuements". The android.bat tool created the avd files under "D:\paul\.android". But, by default, the emulator tries to load the avd files from "%USERPROFILE%\.android". In my system, it is "C:\Documents and Settings\paul".
The emulator.exe and android.bat have different logic to caculate the avd files path. One explanation is the emulator is a C app and the android.bat tool is actually a Java based app.
To solve this problem, the best solution is to define the global environment variable "ANDROID_SDK_HOME".
The value of the "ANDROID_SDK_HOME" is the parent directory path where you want the .android to be created.
e.g. set ANDROID_SDK_HOME="d:\"
Then the path to .android is d:\.android.
The emulator now can load the virtual device setting properly from d:\.android
Detect CRLF (^M) line terminators in shell script
Shell will complain 'bad interpreter' error for script which contains CRLF (^M) line terminators.
The error message likes 'bash: ./test.sh: /bin/bash^M: bad interpreter: No such file or directory'.
This generally caused by the script file was edited by a windows ( dos ) editor and saved with dos format.
How to check whether a shell script file contains CRLF? Either the below tricks can help you out.
1) Grep the hex code of CR.
The new line terminator for a text on Unix system is only LF. So, the once the file contains CR, it's not a compatible unix shell script.
The hex code of CR is 0x0D. The grep command is :
grep -c $'\x0D' test.sh
-c means print the total number of match character.
To be honestly, I do not understand the $ in this command either. :P I just found this black magic somewhere by Google.
--- update---
Quote from bash manual page:
|
Words of the form $'string' are treated specially. The word expands to string, with backslash-escaped characters replaced as specified by the ANSI C standard. |
2) Find the hex code of CR by Perl Regular Expression.
The theory is the same to the above one. Just replace with Regular Expression. To be more precisely, Regular Expression match the whole CRLF in the end of each line.
perl -n -e 'print if /\x0d\x0a$/;' test.sh | wc -l
The hex code of LF is 0x0A. wc is to count all the matched lines.
3) Determin file's line teminator by file. This is my favorite one. :D
Command line tool file is used to check the file type of files. It also report the character set and line terminates of regular text file.
file -m /dev/null test.sh
-m /dev/null is a trick to force the file to treat shell script as a regular text file.
Good Linux Tool, find out the biggest file / directory in the system
No matter how big your hard disk is, it can still run out of space someday. So, do some regular cleaning up work is necessary. Free some space by deleting the files which are out of date or not needed anymore.
To get the space consumed by each directory with du and find out the biggest one with sort.
$du --max-depth=1 -h | sort -h -r
Meaning of du options:
--max-depth : print the total size of direcotries on the firest level.
-h : print the size in human readable format (e.g. 1K, 2M, 3G, etc. ).
Meaning of sort options:
-h : sort human readable format numbers.
-r : reverse the result, the biggest number is on the top.
What I need to do is use this command recursively from the root directory ( / ) . It will finally lead me to the file or directory which consumes most of my storage.