Calculate CRC Checksum in Linux using Cksum Command

CRC stands for cyclic redundancy check.

Checksum can be calculated by applying cyclic redundancy check (CRC) mechanism over the data that is being communicated.  Each block of data that is traveling the communication channel is attached with a CRC code or checksum and when the data block reaches the destination, this check is applied again to generate a checksum value. If the checksum generated at the destination and the checksum value in the data block are same then data is believed to be non-corrupted and can be used further but if the two checksum values are not same  then in that case data is said to be corrupted or infected.

cksum command

The cksum command is used for computing the cyclic redundancy check (CRC) for each file provided to it as argument. CRC becomes important in situations where data integrity needs to be verified. Using the cksum command, one can compare the checksum of destination file with that of the source file to conclude that whether the data transfer was successful or not.

Besides providing the CRC value, this command also produces the file size and file name in the output. The command exits with status zero in case of success and any other status value indicates failure.

cksum command examples

1. A basic example

On a very basic level, the cksum command can be used to display the checksum for a file.

$ cksum xwds.pdf
3000792507 123 xwds.pdf
The first value (big number) in the output above is the checksum for the file, then we have the size of the file and finally the name of the file.

2. Checksum changes with change in content

The test file ‘xwds.pdf’ has following contents:

$ cat xwds.pdf
To calculate the checksum of the test file, pass it as argument to the cksum command :

$ cksum xwds.pdf
3000792507 3 xwds.pdf
Now, Modify the contents of file :

$ cat xwds.pdf
Hi everybody.
Again pass the test file as argument to cksum command :

$ cksum xwds.pdf
2559130041 14 xwds.pdf
So we see that with change in contents, the checksum changes.

3. Change in content does not always mean increase or decrease in size

Well the above is true fundamentally also and even for chksum too. Lets see what it means :

Check the contents of the test file ‘xwds.pdf’ :

$ cat xwds.pdf
Hi everybody
Note the checksum :

$ cksum xwds.pdf
2559130041 14 xwds.pdf
Now, change the content by not actually adding or deleting something but by replacing one character with other so that size of the file remains same.

$ cat xwds.pdf
Hi everybudy.
So as you can see, I replaced ‘o’ with ‘u’.

Compare the checksum now:

$ cksum xwds.pdf
3252191934 14 xwds.pdf
So we see that the checksum changed even if the change was of one character replaced by other.

4. An interrupted copy

Suppose you are copying a zipped folder containing various sub-folders and files from one location to another and due to any reason whatsoever the copy process got interrupted, so how would you check whether everything was copied successfully or not? Well, cksum makes it possible as now we know that in case of the partial copy, the overall checksum of the destination would differ from that of the source folder.

You can simulate this scenario in the following way:

I created Xwds.tar.gz and Xwds_1.tar.gz from the same ‘Linux’ folder. The difference being that Xwds_1.tar.gz was made when ‘Linux’ folder contained an extra text file.

So the above scenario simulates when Xwds_1.tar.gz was being copied but got interrupted when just one text file was left to be copied in the target Xwds.tar.gz

Now when I compare the checksum of both these files, I see

$ cksum Xwds.tar.gz
756656601 1037079 Xwds.tar.gz

$ cksum Xwds_1.tar.gz
2598429125 1037184 Xwds_1.tar.gz
So the above output shows different checksum values suggesting incorrect copy of file.

Things to Consider When Making iOS and Android Apps with Cordova or PhoneGap

The promise of PhoneGap/Cordova development is quite fascinating. Use your existing HTML/JS/CSS skills (and team) to build cross-platform mobile applications for iOS/Android/Windows, and other mobile platforms. As a bonus, you can then update your existing codebase once for all platforms instead of maintaining separate repositories. In this post we are trying to explain some of the decisions you we consider before beginning your next cross-platform Cordova project.

About PhoneGap and Cordova 

This first choice might be a confusing one but it’s really very simple. Phonegap is a product owned by Adobe which currently includes additional build services, and it may or may not eventually offer additional services and/or charge payments for use in the future. Cordova is owned and maintained by Apache, and will always be maintained as an open source project. Currently they both have a very similar API. I would recommend going with Cordova, unless you require the additional Phonegap Build Services.

Which Plugin we should use

Plugins are a big part of the magic of Cordova development. Cordova comes with a minimal set of APIs, and projects add what extra APIs they require through plugins. You can search through all existing plugins using the Cordova Plugin Registry. The core set of Cordova plugins provide access to Battery, Camera, Dialogs, Geolocation, and more, which are generally available across all supported platforms.

There are also many other third party plugins that allow extra functionality including native sharing, analytics, and many other platform and device-specific capabilities, however cross-platform support is typically more limited with third-party plugins. Make sure that you are aware of which plugins you will need and make sure that they are available on the platforms and versions you will be supporting.

Supported Platforms and Versions

Generally Cordova supports most of the platforms with the help of some plugins and settings. The first generation iPad is locked at version 5.1.1, so those iPad users (and users who have not updated beyond iOS5) will not be able to download your app from the App Store unless you customize the application in XCode. Additionally, if you are going to support 64-bit iOS devices such as the iPhone 5S, you will either need to use a recent version of Cordova (3.5 or greater), or you will also need to do some further customization within XCode.

Support for legacy Android versions is a bit more complicated, depending on what your specific needs are. You will want to be familiar with the Android Developer dashboard for weekly updated stats about Android platform versions. Android versions 2.2 (Froyo, version 8) and earlier do not have Play Market, so those users won’t download your app. Android version 2.3 (Gingerbread, version 10) is officially warned against using in the Cordova Security Guide, and many third-party Cordova plugins do not support Gingerbread, so its use is discouraged. Android 3.x (Honeycomb, version 11-14) appears to have been completely phased out with zero percent of users in the weekly dashboard (so testing this version might be both complicated and completely worthless).

As far as worthwhile Android versions go, version 4.4 (KitKat, version 19) has excellent CSS3 & HTML support. You can most likely just build your working iOS Cordova app for android and view it in a 4.4.x version Android device and not have any issues at all. Versions 4.0 – 4.3 (Ice Cream Sandwich and Jelly Bean, versions 14-18) will likely require at least a little more effort, especially if you are using hardware-accelerated CSS 3D transforms or scrollable divs. You will probably spend the majority of your UI bug-fixing time working on these versions alone, however at the time of this writing, these versions (not including KitKat) enjoy a combined 63% global distribution, so this is time well spent in most cases.

Regarding CSS and platform support and version fragmentation, one approach that I recommend is similar to that used by Modernizr. You can use the Cordova device plugin to detect the OS and version (and other device-specific properties), and append specialized classes to the html or body elements, such as ‘ios’, ‘android’, and ‘jelly-bean’. This way you can target specific versions with CSS more easily. Another variation on this approach is to add a class such as ‘legacy’ for certain platform versions, to simplify the CSS selectors while still allowing for similar platform/version differentiation.

Factors to be considered 

Will you support only mobile phone or tablet form-factors, or provide a responsive, universal experience? This question can dramatically change your designer, developer, and tester resource requirements for a given project. Just as each platform and platform version will introduce an extra level of effort, each form-factor/breakpoint setting will introduce a new level of effort for designers and developers.

Additionally, each level of effort for designers/developers will create a new level of effort for testing requirements for each platform version. That is to say that for a project with three supported versions with two identical form-factors, there are two levels of designer/developer effort and six levels of testing effort involved.

Offline Plugins

What is your app going to do when there is no internet connection? While some apps don’t require any internet access for normal behavior (e.g. a calculator), some do. Take a moment to consider the user-experience for your app when no internet connection is present. Things that might not work while offline include sharing, linking (includes opening links in an in-app browser), analytics, and file access/transfer (ajax or otherwise). You can use the Cordova Network/Connection plugin to detect the connection type and to handle online and offline detection and event handling.

Development Tool Selection

There will probably be some things that you will not like about the out-of-the-box Cordova XCode implementation. For example, do you want the status bar to be hidden when you launch the app (and/or after the start screen)? Do you want to disable Universal application status? You might even want to customize some Cordova application settings or plugins (which are written in Objective-C). If you want to release your application to the App Store (or do some of the things just mentioned), then at some point you are going to have to learn some basics of XCode development. Most of the Android settings can be changed directly in the AndroidManifest.xml file so knowledge of the Eclipse IDE isn’t as essential, however you should be aware of how to sign and publish a Cordova app for Android.


It is a good idea to have one or two physical devices for each platform/version combo you are supporting. There are emulators and simulators that can help you to identify some major issues, but nothing beats having a real device for testing. With emulators sometimes you will get false positives or negatives for bugs (and sometimes the emulators have bugs of their own which don’t affect your application). It is also helpful to be aware of the any specific bugs and/or issues with the platforms/versions/devices you are testing.

Debugging Cordova applications can sometimes be a challenge, but if you are familiar with Chrome and Safari Dev Tools it is much easier. For Android devices, you should be able to choose Tools > Inspect Devices and have full access to your application’s HTML, CSS and JS. Similarly in iOS once debugging is enabled in iOS Safari and Mac Safari, you will have access to the Developer Panel with similar access (although with a very XCode-style debugging UI which might take some getting used to). You will need to reopen the Safari Developer panel whenever you restart your app, which can be a pain, but you can also simply reload the app with Command+R instead. Another approach I’ve used is to use setTimeout or an alert to delay the app for debugging so that I have time to open the console before the application starts up.

Hopefully this post will help you to think about the considerations for in-house cross-platform packaged application development with Cordova/PhoneGap. Mobile application development typically involves a lot of testing and iteration, so be sure to plan accordingly.

Getting started with PHP and MySQL on Amazon EC2

Do you know nothing about Amazon Web Services (AWS) or Linux server administration, but want to get a PHP/MySQL server set up on AWS? I will show you how to set up PHP and MySQL on one of Amazon’s free servers

Amazon Web Services has a ton of different products, but the one you want is Amazon Elastic Compute Cloud (EC2). Go there, and click “Sign Up for Amazon EC2”.

Once you’ve gotten that set up, go to the AWS Management Console, and click on “Instances” in the Navigation panel. AnInstance is just a virtual server – so let’s create one! Click “Launch Instance” under “My Instances”, and select “Basic 64-bit Amazon Linux AMI”. On the Instance Details phase, select “Micro” (which is Free tier eligible). Continue until you need to enter the “Name” – if you don’t know what else to call it, just use “Web/DB server”.

Next you create a Key Pair – this will be the credentials you’ll use to SSH into the box. The instructions here should be fairly straightforward. Next is the Security Group, which will be used to specify the firewall used for your instance. Feel free to use the default Group for now. Continue to the Review phase and launch it!

You should now be able to SSH into your instance using your .pem file with ssh -i [FILE NAME].pem ec2-user@ec2-[IP ADDRESS] Alright, we’ve got a server up and running! However, no software are installed to it till now. Let’s install some software.

Configuring the Linux Server

Below I’ll show you how to set up PHP and MySQL on the server. I’ve separated PHP and MySQL so that it’s easier to adapt this to having two instances.


Install PHP using following line

sudo yum install php-mysql php php-xml php-mcrypt php-mbstring php-cli mysql httpd

Press ‘y’ for each of the prompts that shows up. Note that you’re logged in as ec2-user, so you need to sudo all of these commands.

You should now be able to create and run a PHP test file. Next, let’s get MySQL up and running.

MySQL server

First, install and begin running the server:

sudo yum install mysql-server

sudo /etc/init.d/mysqld start

Next, set the root password. I’ve found this password generatorto be just dandy.

mysqladmin -u root password ‘[PASSWORD]’

Now we set up two users for MySQL: the administrator, which you’ll use to create and modify tables; and the app user, which the app will use to query the DB (with more limited privileges). Log into MySQL as root (mysql -u root -p) and enter each of the following lines:






You may want to fine-tune your database settings further than this, but this is a good start.

Make it web-accessible

We now have PHP and MySQL running on the box, but cannot access it through a browser. We need to configure the web server and set up an Elastic IP.

Web Server

First, let’s create a test PHP file that will be accessed by the browser. Create directories so that you can put your file in/opt/app/current1. Make an index.php file that contains whatever you want.

If you want to FTP transfer files to your server, you’ll want to give the ec2-user permissions to modify files in your web directory:

sudo chown ec2-user /opt/app/current

To set up the web server, httpd, we need to first modify its configuration file, located at /etc/httpd/conf/httpd.conf. Open it up with vimemacs, or your favorite text editor, and go to the bottom of the file. Here you’ll see a small section on theVirtualHost (between <VirtualHost *:80> and</VirtualHost>). Uncomment it out and set DocumentRoot to/opt/app/current. Restart (or start) httpd:

sudo /etc/init.d/httpd restart

Elastic IP and Security Groups

In the AWS Management Console, click on “Elastic IPs”, then “Allocate New Address” under “Addresses”. Once the address is created, click on it, then “Associate Address”. Select the instance and associate it.

Now click on “Security Groups” in the Navigation panel. Select theSecurity Group that you used for the instance (probably the default one). Under the “Inbound” tab, add an HTTP rule (port 80). Click “Apply Rule Changes”, and you should now be able to access your website! In your browser, go to http://ec2-[IP ADDRESS], where the IP address is the Elastic IP you made with periods replaced with hyphens.

Hello World! or Putting it all together

We now have all the pieces we need to access MySQL from PHP and serve that to the browser-accessible website. So let’s log intomysql and create a sample table:

mysql -u [DB NAME]_admin -p

[type password]

mysql> use [DB NAME];

mysql> CREATE TABLE test (message VARCHAR(255));

mysql> INSERT INTO test (message) VALUES (‘Hello world!’);

Now modify your index.php file (/opt/app/current/index.php) to be the following:


$conn =  new mysqli(‘localhost’, ‘[DB NAME]_user’, ‘[USER PASSWORD]’, ‘[DB NAME]’);

$result = $conn->query(“SELECT message FROM test;”);

$row = $result->fetch_assoc();

echo $row[‘message’];


We now have a fully functioning PHP and MySQL server!

Taking it further

That’s it for the basics, but there’s so much more that you can do now.


sudo pear upgrade

sudo yum install php-pear

sudo pear channel-discover

sudo pear channel-discover

sudo pear channel-discover

sudo pear install phpunit/PHPUnit


I’ve found it handy to set up an administration area for my sites using a different port on the same URL. Note that port 80 is the default for web traffic, but 8080 is also commonly used.

Create /opt/app/admin. Then, in httpd.conf, add the lineListen 8080 after Listen 80 and add another VirtualHostentry, using <VirtualHost *:8080> and pointing to the/opt/app/admin directory. Update your Security Group to allow traffic over port 8080. Make sure to restart Apache and you should now be able to access your admin folder through your browser at

You can then download phpMyAdmin into/opt/app/admin/pma and unzip it. Using the [DB NAME]_admin user, you can now manage your databases there through your browser.