Port Perl scripts from Solaris to Linux

The classes listed in Table 1 are not a definitive list of all portability issues but rather just the most common ones. For more detailed information about portability problems, take a look at Perl Programming Documentation.

Five steps to perfect Perl porting

Let's look at the roadmap to porting Perl scripts from Solaris to Linux. This roadmap builds on the classes of portability issues in Table 1. The roadmap includes five steps, each one focusing on one of the classes from Table 1; each step identifies problems with Perl syntax constructs or operators that may need some sort of code remediation.

Step 1. Inspect Solaris-specific module dependency

The first step is all about inspecting imported Perl modules. Some of them are specifically built for Solaris, and once you enable them, they will tie the script to the Solaris platform. We need to identify these modules by the script code, figure out their leveraged functions and variables, and make the proper changes so they don't tie you to a platform where your Perl script isn't running.

You can find a comprehensive list of Solaris-specific modules on the CPAN repository; they usually have names starting with either Solaris:: or Sun::Solaris::.

You can use the shell script in Listing 1 can be used to identify Perl script files with import statements that start with "Solaris" or "Sun."

You can modify the code in Listing 1 to make that script more accurate in finding Solaris-specific modules within Perl scripts. For example, you can convert the shell script in Listing 1 to Perl and thus leverage the PPI module for parsing. The use of that module is beyond the scope of this article, but we recommend it for greater precision when parsing Perl codes.

After identifying scripts with Solaris-specific code, you need to search for equivalent modules that work on Linux as well. It's not always easy to identify such modules in terms of functionality since the original modules might deal with technologies exclusive to the Solaris platform. When that occurs, you will have to perform a deeper analysis.

To use an equivalent Linux-based module, you need to replace all import statements as well as any called functions andvariables with the equivalents of the new module.

Step 2. Inspect calls to Solaris-specific system commands

Calling operating system commands from within the Perl script can present the most common problem when performing Solaris to Linux migrations for several reasons:

• Lack of commands on the target system

• Commands with different set of flags

• Commands that behave differently on both platforms

Therefore, you need to take special care when dealing with this issue, the class number 02 portability issue: System calls.

The goal here is to ensure that any system command evoked on the script syntactically and semantically works properly on Linux as well. In short, it's all about identifying Perl core functions and operators leveraged in the script that carries Solaris-specific system commands.

Let's start with an example. Listing 2 shows a simple Perl script used to display the memory size of a Solaris system.

Now let's suppose we want to run the same script on Linux. We figure out that it calls a piped system command (prtconf | grep Memory) through the backtick operator, and the prtconf command is specific to Solaris. The first step is to find a replacement for it.

You may use cat /proc/meminfo | grep MemTotal even though the output is formatted differently since the/proc/meminfo hold size information in KBs and prtconf is in MBs.

To remediate this script, you can replace ptrconf with cat /proc/meminfo, but to keep the output information in MBs (we don't know if the output of this script is used as input in other scripts, so it's critical to not change it), we can use a simple conversion. Listing 3 shows an example of how this script could be remediated.

Because Perl is flexible enough to accommodate different ways of executing operating system commands, there are many different core functions and operators used for that purpose. Table 2 lists Perl core functions and operators leveraged to call system commands from within a Perl script.

You can check Perl documents for further information about each of these functions and operators, as well as any others that are not part of Perl's core language. Consult the IBM Redbook "Solaris to Linux Migration: A guide for system administrators" to learn more about differences in system administration commands.

Step 3. Inspect use of OS pathnames

Now let's discuss migrating leveraged pathnames by the Perl script; this step is similar to Step 2. Here you need to pay attention to syntax elements and operators that are used to open or manipulate files. Although there are specific operators to do that, some problems with referenced pathnames may arise. (You can also see this when you invoke system command like those mentioned in Step 2.)

Listing 4 shows a small script that reads the NFS server config file of Solaris and prints it to standard output.

When migrating from Solaris to Linux, you need to pay attention to system paths, which often differ. In this example, the file/etc/default/nfs referenced on this Solaris script doesn't exist on the Linux/Red Hat distribution, but it is replaceable with/etc/sysconfig/nfs. Listing 5 shows the script after it's remediated.

You need to be aware of any Perl commands that manipulate files. Table 3 shows some common path-handling commands used in Perl; if any of those are being used in a script, you'll need to remediate pathnames when migrating.

Step 4. Inspect use of special variables that hold Solaris-specific information

Some special variables hold information on the environment that may be specific to Solaris; you need to identify these variables and make the proper translations. Table 4 lists a few core variables that may hold Solaris-specific information or references.