Paul - The Programmer

simple & stupid

Disable windows search

Windows search sucks and can not be uninstalled anyway.

Finally I find the way to disable it completely.

Step 1.  Open Start Menu >> Run, type service.msc

Disable service 'Indexing Service' and 'Windows Search'

Step 2. Unregister windows search dll, Open Start Menu >> Run, type cmd

Type regsvr32 /u "%programfiles%\Windows Desktop Search\wdsShell.dll" and process enter

Now, you have disabled the windows search and get the old xp search back when you type "Win + F". 

The biggest failure of windows search is not its huge resource consuming but it forces its end user to search around the google to find out how to make it not work.

Never fight with user.

Setup Android dev environment on Debian X86_64

The android kenerl compile script require the x86_64 system. So I install the Debian X86_64 port on my dev desktop.

Follow the below steps to setup environment for Android sdk.

1) Install Sun Java SDK 64bit and ia32 JRE.

The 64bit Java is requried by the eclipse and the ia32 JRE is needed for running android sdk tools like android, ddms.

Since the Sun Java SDK is not free software, the contrib, non-free Debian repository are needed in the /etc/apt/source.list

For instance, my source.list is

 

deb http://mirrors.163.com/debian/ squeeze main contrib non-free
deb-src http://mirrors.163.com/debian/ squeeze main contrib non-free

Install the Java SDK and ia32 JRE with command:

 

# apt-get update
# apt-get install sun-java6-jdk 
# apt-get install ia32-sun-java6-bin

2) For the convenience of running android sdk tools, the default jre should be ia32 JRE. Update the default JRE setting with Debian fashion:

 

# sudo update-alternatives --config java

Select the ia32 JRE for your default java.

3) Setup JAVA_HOME in .bashrc with the path to Java 64bit SDK for running ANT. 

 

export JAVA_HOME=/usr/lib/jvm/java-6-sun

4) Update eclipse.ini to run eclipse with Java 64bit JDK. And the below lines in eclipse.ini

 

-vm 
/usr/lib/jvm/java-6-sun-1.6.0.24/bin/java

 

 

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.

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.