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.