Good tutorials on Emacs Lisp

There are two pages that I would highly recommend to get started with Emacs Lisp.

• Xah Lee's tutorial on Emacs Lisp.
• Steve Yegge's Emergency Elisp.

Of course you should always have the Emacs Lisp reference manual handy.

Customizing colors in comint package in Emacs

The default foreground of prompt (gdb, shell, etc.) in the comint package in Emacs is blue. If you are working in PuTTY, the default background is black. Imagine blue on black background. Looks nasty!

You can customize the color of the prompt by using the comint-highlight-prompt variable. For e.g. I am using yellow foreground in my system. Here is how I have customized it by adding these lines in my ~/.emacs:

(copy-face 'default 'comint-highlight-prompt)
(set-face-foreground 'comint-highlight-prompt "yellow")

In short, the first lines creates a font-face variable by copying the default face and the second line changes the foreground value of that font-face variable to "yellow".

Scott A. Kuhl's .emacs file helped me a lot in understanding how to customize this. Thanks to him.

Time saving tip to connect PuTTY in one click

You can create a short cut in your Quick Launch folder that looks like:

\path\to\putty.exe -load "session name"

Session name could be obtained from your PuTTY dialog box when you launch it normally. This saves me a lot of time, since most of the time I connect to the same host.

There are other interesting questions available under PuTTY FAQ.

Customizing the colors in ls output

This posting is specific to customizing the dircolors in bash shell in Linux. It may or may not be applicable to other shells and other platforms.

When the bash shell is started, it executes all the shell scripts under the directory /etc/profile.d/*.sh. You might find other shell scripts under this directory (for e.g. colorls.csh), but those scripts are not to be executed by the bash shell. These files are executed within the current shell's environment, not in a separate execed shell (like a dotshell).

One of these files is colorsls.sh. A set of rules in colorls.sh search for the user specific dircolors file. This file could be any one of the ~/.dircolors, ~/.dircolors.$TERM, ~/.dir_colors or ~/.dir_colors.$TERM. In case the user has more then one of these files, whichever comes last will be taken.

Let us stick to the convention of using ~/.dircolors file for our customization. It is very easy to create this file by giving the following command:

dircolors --sh > ~/.dircolors

Then you can edit ~/.dircolors using your favorite editor. This file has only one environment variable called LS_COLORS. LS_COLORS variable is ":" separated. Each entry is a name value pair. Name could be the type of the file (for e.g. di is directory, fi is regular file, ln is link, etc.) or a regular expression for file's name (for e.g. *.sh, *.csh, *.gif, etc.). Value is a ";" separated three integers that tell about the attribute, foreground and background respectively. Here is an example (the color rule for a directory):

di=00;34:

This says the directory should be displayed with no special attributes and blue foreground. You can easily check the color codes using the following command:

dircolors --print-database

For handy reference, this is what I see in my machine:

# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white

So let us say I want to make my directories to be yellow and blinking, this is how I would have that entry:

di=05;33:

You must remember that not all attributes are supported by all the terminals. Some terminals have limited capabilities.

A tip: In case you are totally fed up with colors (just the way I am), a sane alternative is to use the following alias (like they might not be able to show blinking text).

alias ls='ls --color=none -F'

This will add a "/" after directory, "*" after executable and "@" after a link, etc.

If you have time to waste: C++ or Java which one is faster

Okay. This one is just as useless argument as anyone could imagine: C++ or Java - which one is faster? The long discussion could be read from here. The original poster of the thread (Razii) came up with this idea of reading the whole bible verse by verse and sort it and write it back to disk using programs written in both Java & C++. In doing so he will compare the time taken by both Java & C++ programs. The (seemingly wrong) conclusion he came upto was that Java is faster than C++.

Let me give you my gist of it. I copied and pasted the same piece of code (and fixed the issue of including the iterator header file and dividing by 1000 to get the milliseconds) , and ran the same test in my Linux box. Well, almost always the C++ program was considerably faster than the Java program. Many a times my C++ program took only 50% of the time taken by the Java program. My Java version is "Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)" and my g++ version is "g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)". I am running my experiments on Linux 2.6.9-42.13.ELsmp OS.

Again, this is only if you have some time to waste ... just the way I do ;-)

Have a happy weekend.

FTP connections over NATed VMWare virtual machine

I was trying to install the FreeBSD 7.0 in my VMWare virtual machine (VM). After I downloaded the installer disk's ISO image, I connected that ISO file as my CDROM drive in my VM and booted my VM. I should mention that my VM is in NAT mode, as I had decided to install the FreeBSD over the network.

When the installation tries to download the distro files from the FTP servers, it just kept saying it could not connect to the FTP server. I wasted around an hour or so without thinking about the basics (Damn!) that I am behind a NAT and I am trying to download files using active FTP mode. Then I tried to connect in passive mode and everything worked fine.

I don't want to repeat what many people have already clearly explained about passive mode of FTP. Here is an excellent tutorial that talks about active and passive modes of FTP.

Moral of the story is, don't forget that active FTP doesn't work (generally :-) if you are behind a NAT.

I would like to add only one thing: I think it would be a nice idea to have the FreeBSD installer indicate that passive ftp mode could work, in case it fails to open the data connection in active mode.

Event Completion Framework in Solaris 10

Simiar to kqueue framework in FreeBSD, Solaris 10 introduced a framework called Event Completion Framework (ECF). ECF is a very powerful concept that can be used when an application wants to wait for asynchronous events - like read/write events on sockets. Traditionally one would use poll()/select() for these events. There is enough discussion already on how primitive these mechanisms are and how they don't scale well on large number of file descriptors. Another advantage with kqueue and ECF is that you can wait on different kind of activities, not just activities on file descriptors. For e.g. when a process calls fork, or when a process calls exit, etc.

There are a few resources that would be very useful in understanding these frameworks:

• Robert Benson's article on ECF
• Sample program given in Bart Smaalder's blog
  
• Jonathan Lemon's paper on kqueue

Oh btw, I think Linux is yet to have a mechanism as powerful as these.