How to debug unix (shell/perl) scripts

As a professional we also need to be the solution provider which essentially means you need to be ready to get your hands dirty with anything which comes your way in order to serve the business.

Many a times you will come across the situations where you need to fix critical problem or software bug in short span in order to keep your website or product up to date. So there comes the debugging in picture and you all will be adapt to debugging java applications using eclipse (local and remote) and so will not discuss that here but sometimes critical business aspects or functionalists are implemented in unix scripts like shell script or perl script which can be tedious task to deal with if you come across the bugs in these sections.

So today, we will see how to debug both of these scripts.

Debug Shell Scripts:

Suppose you have a critical function which is doing some X task but you are not seeing the step x or statement x within the same function being executed, as expected.

So how to deal with this situation. Sometimes you might work it around by putting lot of print statements to print some useful information. well, nothing wrong with it but what if those print statements are not getting triggered either or your favorite function is doing lot of things and have complex branching with if/else or switch statements.

So here what you want to do is to check how each statements are triggered inside the fuction and how if/else or other branching logics are evaluated. Consider below example:

function audit_upd
{
  stat=$1
  step=$2
  ins=${ins_rows:-0}
  upd=${upd_rows:-0}
  del=${del_rows:-0}

  TbNm=${TbNm:-MSTAR}
  print "\n\n  `$TIME`:  $Function step $step $stat start ... "

  print "  `$TIME`:  run $sql_dir/audit_upd.sql $DateFlag $AsofDate"

  run_sql $ORACLE_SID_A $DB_ID $sql_dir/audit_upd.sql \
  $DateFlag $AsofDate MSTAR $TbNm $stat

  print "  `$TIME`: $stat DONE"
}

All it does is, calls .sql file with required parameters.

Now, say you want to see the entire execution sequence while this function gets triggered. So you can put set -x as the first line in the function as above.

It will show you entire sequence as given below.

Output:

+ stat=START
+ step=20
+ ins=0
+ upd=0
+ del=0
+ TbNm=MSTAR
+ date +%H:%M
+ print '\n\n  13:39:  get_audit_info step 20 START start ... '

+ print '  13:39:  run /db/sql/audit_upd.sql M 20140630'
  13:39:  run /db/sql/audit_upd.sql M 20140630
+ run_sql TPAQ.WORLD APPUSR /db/sql/audit_upd.sql M 20140630 MSTAR MSTAR START
+ date +%H:%M
+ print '  13:39: START DONE'
  13:39: START DONE

So as you can see not only the execution sequence but it also shows you the assigned values of each variable inside the function.

Debug Perl Scripts:

Now, say similarly you want to debug the perl script then you can do so by using -d option.

It will execute the script but in debug mode and here you have advantage above shell script that -d provides you interactive mode similar to debugging java application in Eclipse.

so let's say you execute below script with -d,

perl -d $subscripts/xml_decode.pl

it will prompt you with  DB<1> on first executable line which is interactive mode and it will await the input from the user.

1) Step over:

 You can provide n or s after the prompt like below.
 DB<1>n (Enter)

n or s are both are similar commands for step by step execution of each executable statements like F6 & F5 in Eclipse.

n (same as F6) will execute the statement in single step which means any subroutine or function will be executed and response will be assigned back, same as F6 in Eclipse debug mode.

s, on the contrary, will step into the subroutine or function if called on this break point; similar to F5.

2) Break Point:

It also allows you to set the break point at particular statement. For ex, say you have a function at line #60 and you want to set the break point.

 DB<1>b 60 (Enter)

So any statement on line 60 will be triggered once the execution reaches there.

3) Inspect Variables:

p command allows you to inspect or print the value of any variable. For ex, say execution is at line #70 which is a variable called $count and you want to inspect the value at this particular point of time.


 DB<1> p $count (Enter)

Output: 20

4) Jump to break point:

Suppose you want to skip few lines and interested to see what happens at certain point, let's say at line #75. below command will exactly do that for you,

 DB<1> c 75 (Enter)

5) View the break points:

Now, say you want to see all the break points in the sequence from the current execution point. so l command allows you to see next window of lines.


 DB<1> l (Enterr)

Output:

DB<8> l
46
47        SWITCH: {
48          # evaluate the expression
49:         if (/([^<]*)<([^>]*)\/>$/) {
50:           print "Inside first if condition \n";
51:           last SWITCH;
52          };
53

6) Quit the interactive mode:

Finally if you want to quit the debug mode during the process then you can use q to quit the debug mode once you are done with it.

So these are some the useful tips to debug the scripts which can be tedious task sometime without adequate knowledge on particular scripting language.

Hope, this will help you to be more productive and efficient with the unix scripts......

Mule Part I: Introduction

Mule is widely used open source framework for Enterprise Integration. In this post, I will  try to cover basics of Mule and why you should be using Mule since there is very less documentation available for the mule.

What is Enterprise Integration?

In an organization, there will be multiple applications or products or processes to complete the end to end business flow or transaction. Needless to say that, these applications might be owned by different business groups or teams and so the underlying architecture or communication protocol will defer as well. 

So to serve the business, there is always the need to allow these applications or processes to communicate to each other regardless of the underlying architecture or protocol or communication style. For ex, to settle the trade, Frond office will receive the trade instruction, Middle office will process the trade and back office will settle the trade with market feed. Now let's assume, front office application which will receive the trade is designed using .Net framework and Middle office application which processes the trade is designed in Java. In order to communicate either of this application need to change (Java or .Net) which would be a disaster and there comes the power of Enterprise Integration Software or tools !! 

In our case, front office can send trade message or instruction to middle office process through web service and middle office can process the same through Mule or any other Integration tool like apache camel or spring integration etc without changing underlying architecture and same way send it to downstream system or back office. So two systems can work in isolation without interfering to what other system offers....

Now let's understand how we can achieve this through Mule ESB.

What Is Mule?

Mule is a transport-agnostic, Java-based messaging framework that allows disparate applications to connect without having to call each other directly. Mule supports multiple threading/messaging models, input and output to various transports (email, files, databases, etc.), and web services through protocols such as SOAP (see Figure 1).

With Mule, you can...

• integrate applications or systems on premise or in the cloud
• use out-of-the-box connectors to create SaaS integration applications
• build and expose APIs
• consume APIs
• create Web services which orchestrate calls to other services
• create interfaces to expose applications for mobile consumption
• integrate B2B with solutions that are secure, efficient, and quick to build and deploy
• shift applications onto the cloud
• connect B2B e-commerce activities

Leveraging the three layers of its architecture: application, integration, and transport, Mule implements an enterprise service bus (ESB) and provides a platform for a service oriented architecture (SOA). The layered approach promotes reusability (see Figure 2).

So stay tuned for more of Mule..............