KSpace

If you are working on unix based system (for any reason), you know that you will need “ls” command more than often. Not anyone would disagree that “ls” is one of the most widely used command in any unix based system.

However one of the thing which got me surprised is the lack of option with “ls” which would list *only* hidden file (or directory). Obviously I am not interested in getting the result which includes the famous “.” and “..” (current and parent directory respectively).

When trying with the option “a”

<kunalkumar@kspace>ls -a
./      ../     .data   .dump/  src     test

As expected, the list included all the files present in the directory (including hidden files as well). However as I was interested only in getting the name of hidden files, I executed

<kunalkumar@kspace>ls -a .*
.data
 
.:
./      ../     .data   .dump/  src     test
 
..:
./                                ../                               test/
 
.dump:
./       ../      dump.1   dump.2

Oouch! Because of the “.*” for file name, it traversed the directories present and hence the above result. So let’s ask “ls” not to traverse directories present and just list the name

<kunalkumar@kspace>ls -ad .*
./      ../     .data   .dump/

Ok. Still the result includes “.” and “..” which I did not want. My attempt also included

<kunalkumar@kspace>ls -ad .*
./      ../     .data   .dump/
 
 
<kunalkumar@kspace>ls -a | grep "^\."
./
../
.data
.dump/

At the end, I realized there is an option with “ls” which directs it to ignore “.” and “..” while listing and finally,

<kunalkumar@kspace>ls -A |  grep "^\."
.data
.dump/

However, I still wonder why there is not direct option with “ls” which only list the name of hidden files (excluding “.” and “..” .) Probably because “.” and “..” are also considered as hidden and hence the output.

It is not very uncommon to use third party library/framework while developing any application. There are definite advantages of using third party library/framework and certain disadvantage as well. Keep aside the advantages. Disadvantages makes us put more effort.

Consider this, you had started developing your application with some third party library which was at version 1.2. Over the period of time, library developer(s) fixed several bugs, included new feature and released version 1.3, 1.4 and 1.5. However your application is still with version 1.2. Worse, you might have referred some resources of version 1.2 in your source code by hard coding the location.

Now if you need to migrate to version 1.5, you can’t simply go in and change the library itself. You need to digg in code, find all the references of version 1.2 and change it according to the new location for 1.5

(Well all the above are true, if you are maintaining library file in folder named according to the version.)

Also there will be a possibility where you would like to maintain different version to deal with different environment. You might need to revert to the old version if something went wrong with the new version.

Now imagine this, you need to revert to the old version immediately. Probability of doing that is absolutely zero if you have version referred in your source code. How would you deal with that?

The basic problem here is not having multiple version of any library. Infact what the code references is wrong! Period.

In any case, source code must not refer any version directly.

To deal with such problem I was facing, I removed all the version reference from the code. For example if the code was looking for a gif file at

/Web/apps/libs/framework/1.2/resources/images/default/loading.gif

It was modified to

/Web/apps/libs/framework/current/resources/images/default/loading.gif

and the new directory structure looked something like as

I chose “current” since it reflected the current version being used with application. Depending on condition/environment, I can always link “current” to appropriate version (say “1.5”). Now with such a directory structure, if we need to change the library with a new version, we will not have to touch the source code (unless there are API changes which breaks the existing code). We just need to modify the link for “current” so that it points to new version of the library. Guess it was worth the effort!