Sleep command is not useless: good usages of sleep command

All developers thougt at least once -and many of them still thinking it from time to time- that something that has been built by somebody else is completely useless. Make a small review of your three or four days and think if you did not say to yourself “what is this useful for?” while looking to a function or a class. It did happen, right? Well, many of us did that with some really useful pieces of code. If you say that you’ve never though that the sleep command is useless you did not spend enough time in front of a command line. I though that some times, “why would somebody want to make a computer to do nothingfor a period of time?” So here I am to explain a list of useful uses of the sleep command, in Linux. This can be done in many other operative systems of course, but not with the same syntax. You’ll need to think on your own how to apply this kind of things on Windows, for example. So here we go with the most recent example I have to give. I was downloading a bunch of torrents when I decided to go to my girlfriend’s place. I did not want to leave Transmission running the whole weekend, and I did not want to tell my girlfriend “Sorry, need to go home to close the torrent client to avoid having an enormous internet bill”. So I simply executed this in the command line:

sleep 7200; killall transmission-gtk

The SEO words for this would be “how to close an application with delay”, “how to delay closing an application”, or “schedule application to be closed”. Another good use, as explained in the “drop table” post, is to make intense-looped operations a bit ligther. For example this could be a good approach to execute a big list of SQL files:

for FILE in `ls *.sql`; do
mysql -uuser -ppassword database < $FILE;
sleep 5;

The script will wait five seconds between the execution. However the sleep command can be even more useful. Let’s say, what if the “5 seconds” is actually changed by another process? So we’ll have two scripts running simultaneously. The first one will be

while true; do echo 5 > sleep.txt; sleep 30; echo 1 > sleep.txt; sleep 10; done

And the second one will be:

for FILE in `ls *.sql`; do
mysql -uuser -ppassword database < $FILE;
sleep `cat sleep.txt`;

With this approach you have the control on how to wait within the loop, and you can change the setting without killing and re executing the script. Nice, uh?

Local Storage

In the good old days we used to do many things to persist form information between pages. All of us have filled at least once one form to search a job, and we all needed to fill that enormous list of fields by entering education info, previous experience, etc. Imagine what could happen if for some reason (Windows?) the browser crashes, and all the form information is lost. That could be a good reason to simply not look for a job, isn’t it? So as I was saying, in the good old days pages with many fields were splitted in two or more pages, so you fill first your email, username, password, first and last name; submit that form; and in the second page you enter your age, your gender, your birthdate, etc. How were the values persisted in the second page? There were a set of options:

* Cookies, which is storage in the client side. Every request to a domain includes these cookies. This means that your browser request will contain much more info than needed.
* Sessions; which is information stored in the server-side and retrieved by a SessionId, which is a cookie in the client side. So on each request, your browser sends the session ID and the rest of the info is obtained from the server.
* Hidden fields. The first page contains a form with, as previously said, email, username, password, first and last name. The second page will contain a form with the input boxes to fill age, your gender, your birthdate, etc; but will also contain a set of hidden fields to keep the values for email, username, etc. as specified before. When the second page is submitted, all fields will be sent to the server.

All these options are valid, are still working and can be used; each one has advantages and disadvantages. But what I want to introduce now is the LocalStorage feature provided by HTML5. LocalStorage is not cookie based, is not session based and is not part of the form. LocalStorage is just, as the name says, local storage of information, on the client side, and that is not sent to the webserver on the requests. So for example I start writing an email, and the browser chrashes. When I open back the same page, I still have the form exactly as it was before the crash.

LocalStorage works as a JS array and can store only strings on each key. This means that you can not store an array in a key, except if you serialize it. Numbers will be stored as strings as well, so you must parseInt() them, or paseFloat() them. You can also iterate over the elements in the localStorage element with the help of the classic .length array property. Also content in LocalStorage will never expire, it will remain in the browser until you clear the private data.

You can see an example in; but basically you can operate on it in any of these ways:

Set a value
localStorage[‘country1’] = ‘Canada’;
localStorage.setItem(‘country2’, ‘Canada’);
localStorage[‘cities’] = JSON.stringify([‘Montreal’,’Toronto’,’Vancouver’]); // We can not store an array, but we can store a string

Get a value
country1 = localStorage[‘country1’];
country2 = localStorage.getItem(‘country2’);
cities = JSON.parse(localStorage[‘cities’]); // We can not store an array, but we can store a string

Just remember that before using localStorage you should check it’s availability, I suggest to use Modernizr to do so.

Detailed and friendly description: