You are on page 1of 9

Shell vs.

Java: Overcoming the Challenges of Shell Scripting for UNIX Installations


Shell vs. Java: Overcoming the Challenges of Shell Scripting for UNIX Installations
A shell is a command-line interpreter that takes and executes commands, and in doing so, implements a programming language commonly referred to as “shell scripting.” Shell scripting is traditionally used by UNIX system administrators to automate the execution of system tasks, but developers also use shell scripts to create enterprise-level software installations, and that is where problems occur. This white paper highlights the major difficulties with attempting to develop UNIX installations using shell scripts. It focuses on shell scripting as a language and how it is used in the context of UNIX installation development. It also discusses how Java is being used as a successful alternative to shell scripting for enterprise installations. Finally, this white paper details how the tools in InstallAnywhere®, the multi-platform installation tool from Flexera Software, can help developers overcome the inherent problems with shell scripting and create highquality multi-platform installations ideal for enterprise environments. Web servers, shell-based installations are rarely a viable delivery option. This delivery mechanism becomes more difficult when you reanalyze how the tar archive is built. The configuration management team has to produce a directory structure that will mimic the final destination. In addition, it is well known that tar-ball installations are not user-friendly to regular users. This is due to the absence of visually guided installations, as is the accepted standard for Windows applications. As a result, they often introduce barriers to user adoption of applications, and may even cause problems with the installation and maintenance of the applications.

UNIX Installations: The Way They Ought to Be

Installations, regardless of the targeted operating system, should be easier to implement. The “tar-ball” file archive structure should not be decided upon by the build system. This should be loosely packaged so that the installation can make the final decision on how the final file structure should look. The installation technology used should be based on a more robust language with built-in parsing capabilities for XML, Java properties files, and so on. Finally, the installation should give the user the option of running the installation in a graphical mode. Ultimately, customers and installation developers want the same thing, a robust installation system. However, their perspective is different. The customer cares about the final product, whereas the developer cares about the development environment needed to produce UNIX installations. The following lists are a subset of requirements as demanded by customers and installation developers. For customers: • Ease of use – Most customers want an easy way to interact with an installation, preferably one that is visually guided, such as those offered by Windows.
Flexera Software: InstallAnywhere White Paper Series

UNIX Installations: The Tar-Ball Archive

Most UNIX shell-based installations are constructed using a “tar-ball” (tar archive) paradigm. A tar file is delivered whose contents include a shell script and the files to be installed. For the most part the files are stored in a structure mimicking that of their final destination. This potentially means that a single copy (cp) command is invoked to copy the entire directory to the home directory. All necessary configurations are done with the help of commands such as “sed”, “awk”, and so on. The user interface provided is console only. By and large, the above scenario is acceptable for simple applications. However, it becomes very hard to follow when even the most straightforward enterprise installations are attempted. If the installation you are attempting to construct is required to configure application servers, databases, or

Shell vs. Java: Overcoming t he Challenges of Shell Script ing for UNIX Installat ions

• Single point of initiation – An end user attempting to invoke your installation should not be confronted by a plethora of installation options. A single native launcher should suffice. • Native look and feel – It is important that users receive an installation that looks and feels like any other application targeted for that particular operating system. • Get the product installed – The ultimate goal of the installation is to get the product installed and configured. For installation developers: • Single point of development – A true cross-platform development platform that would allow the developer to maintain a single code base for numerous platforms. • The development environment should use a familiar language, preferably object oriented – To allow extensibility, the installation development tool should enable the developer to extend it. • Operating system abstraction – When developing cross-platform installations, the developer should focus on product installation and configuration tasks and not how each operating system works.

installation and received the same error. Only this time the error occurs at line 4559. Debugging is not available unless you type: % sh -x The above does not yield results that someone with limited shell-scripting knowledge can understand. The problem is worsened when the script contains a statement similar to myvar=`cat $1`. If $1 is not initialized, the script will be stuck. Of course, a diligent programmer doesn’t allow this to happen, but if it does happen, debugging can be a nightmare. Other issues with the script come to light when you consider the problems associated with localization and permissions (“To install, you need admin rights\n”), and dealing with a nonstandard logging (to install.log) mechanism. The point of this exercise was to show how difficult it can be to develop elaborate enterprise installations using shell. Interoperability Even though shell was never intended for large development, shell scripting is sometimes used to create large installation projects, such as enterprise installations. These installations need to directly communicate configuration settings to the product being installed. For shell-based installations, this is done using input files or the command line. Error handling, for the most part, is done using return codes. Unfortunately, return codes are not always reliable. Sometimes a command may return 0 when in fact it should return anything but 0. Extra steps need to be taken to ensure reliability, which can turn into unnecessary complex ifstatements that make interoperability all the more difficult. Sharing Code When developing large-scale enterprise installations, you can expect more than one developer to work on the same code. Your plan, of course, is to develop reusable libraries that can be used across the installation system. However, shell was not designed with that in mind. Shell is for the most part used to automate administration tasks such as “empty the temp space” or “manage users.” It was designed to deal with low-level tasks, not code sharing. Portability Not all UNIX environments are created equal. Some commands work in every UNIX environment; some do not. Sometimes commands such as “pidof” do not exist in environments other than Linux. Furthermore, some utilities do not share the same command-line arguments across all UNIX implementations. Besides, would you like to learn all the command-line options offered by UNIX commands such as “ls”? To account for portability, a great deal of code must be written.

Analyzing the Shell Scripting Environment

The concept of shell scripting was introduced to help system administrators automate low-level shell commands. For a long time most companies have used shell scripts as delivery mechanisms (that is, installations), which, for the most part, worked well. Since shell scripts are delivered in clear, readable ASCII, they can potentially expose implementations that can pose as security holes. Unfortunately, that is not the only weakness shell scripting exposes. The following sections highlight why shell scripting does not scale when enterprises attempt to use it as an installation development platform. The Development Environment Shell is littered with hard-to-understand regular expressions and lacks a true integrated development environment (IDE). It often takes a truly senior UNIX developers to properly handle such complex scripting environments. Consider the following syntax: CURRENT_USER=`whoami | awk ‘{print $1}’` if [ “$CURRENTUSER” != “root” ] && [ “$CURRENT_USER” != “admin” ]; then printf “To install, you need admin rights\n” | tee -a install.log fi If you take a closer look, you will notice how awkward the if-statement really is. If you play with the white-spacing in the if-statement, you may receive an error similar to this one: ./ line 2: [CURRENT_USER: command not found] Although this may not seem like a big problem, imagine what would happen if someone in the field ran your
Flexera Software: InstallAnywhere White Paper Series


Shell vs. Java: Overcoming t he Challenges of Shell Script ing for UNIX Installat ions

Parsing Ability Shell was written long before SGML technologies such as XML were available. Therefore, its abilities for parsing such formats are based on regular expressions. For the most part, regular expressions are hard to write and even harder to debug. To consider writing regular expressions for parsing XML would put you in the business of building XML parsers from scratch. Modern languages such as Java and C++ have XML parsers built-in. Parsing becomes more of a problem when unknown formats are met. New regular expressions must be built, or you could write a native executable using C/C++ to do the job. Once again, interoperability becomes questionable. The Linux Factor With the introduction of Linux, a large number of nonUNIX users entered the UNIX arena. From a strategic point of view, it gives a large number of users the chance to diversify. On the other hand, most of these new users come from GUI-driven operating systems, and they want everything be done with graphical tools. But shell-based installations are made to be console-driven – no graphical interface. Mac OS X Mac OS X is further proof that UNIX is becoming more accepted as a graphical operating system. Besides making Mac OS X the most optimized UNIX environment to run Java, Apple has made Java an integral part of Mac OS X, which is good news if your strategy is to create Java-based installations. But shell-based installations must once again take a back seat.

public String getInstallStatusMessage( ) { return “Computing time stamp...”; } public void uninstall(UninstallerProxy up) { /* do nothing on uninstall */ } public String getUninstallStatusMessage( ) { return “...”; } } First and foremost, the above code is standard Java code. In addition to being able to use standard Java functionality, Java code can use JNI to call in to native code. The interesting thing about JNI is the fact that as far as the Java developer is concerned, the JNI call is just another Java call. Worth noticing is also the exception handling offered by Java. Logging is another powerful Java feature. To facilitate readability, logging information can be categorized by severity and the output can be formatted as XML, which in turn can be transformed into HTML so that customers can view install logs in a readable format. Java has emerged as a very popular technology, and for good reasons. Most educators have embraced Java as their teaching language of choice, creating a large pool of Java developers. The attractiveness of Java as a “write once, run everywhere” language has certainly been another contributing factor to its popularity. Another strong supporting argument for Java-based installations is that numerous companies deploy application servers such as IBM® WebSphere®, BEA® WebLogic®, Sun® Java Enterprise System, or JBoss. For scalability and reliability purposes, these are mostly deployed on the UNIX platform and are Java-based. Most application servers expose Java configuration APIs. This allows for a seamless integration strategy that can ultimately give users an out-of-the-box delivery solution. The interesting point here is that “write once, run everywhere” becomes an attainable reality. As an alternative to shell scripting, however, Java requires additional help before it can be considered as a logical successor. A reliable, user-friendly Windows-like setup experience would be a great thing to have for UNIX developers. The ability to target UNIX and Windows platforms with a Java-based application install would be even better, especially given how difficult it is to accomplish this with shell scripting. For the developer with lots of experience with tar-balls and cryptic script commands, any alternative needs to offer clear and compelling benefits. The balance of this paper will offer just such an argument, based on the capabilities of InstallAnywhere from Flexera Software.

Java-Based Installations

If not shell scripting, what then is a feasible alternative technology for developing cross-platform installations? What about Java? Its “write once, run everywhere” makes it an ideal technology for targeting platforms such as UNIX. Java transforms the installation development into a more robust environment. To appreciate the power of Java to extend an installation, consider an example. The following is a simple Java class that computes a time stamp and stores the result in a custom InstallAnywhere variable. import*; import java.util.*; public class GenerateTimeStamp extends CustomCodeAction { public void install(InstallerProxy ip) { // compute time stamp with Java... String now = new Date( ).toString( ); // ...and set a custom variable to the value ip.setVariable(“$NOW$”, now); }

Flexera Software: InstallAnywhere White Paper Series

Shell vs. Java: Overcoming t he Challenges of Shell Script ing for UNIX Installat ions

Building Multi-Platform Installations with InstallAnywhere

InstallAnywhere from Flexera Software provides an out-ofthe-box Java-based installation solution. Developing crossplatform installations with Java and InstallAnywhere’s multiplatform installation IDE provides many benefits, including making it easy to: • Tightly integrate installation development into the development department • Conceal code so that proprietary implementations are kept safe • Create installations that can be extended and developed using Java technologies

graphical interface, which allows developers to manage all aspects of their installer project. All the features of InstallAnywhere are available in this easy to use integrated development environment. Advanced Designer Tasks The Advanced Designer is divided into tasks that are represented by tabs found along the left-hand side of the window. Each of the following tabs represents tasks and settings specific to each installation project: • Project: Settings related to your specific project. These include general settings, file settings, and localization settings. • Installer UI: Set the look and feel for the installer by adding background images, billboards, and other graphical components. • Organization: Manages Install Sets, Features, Components, and Merge Modules. • Pre-Install: An ordered sequence of panels and actions that occur before file installation. • Install: Manage File installation tree and install time actions. • Post-Install: An ordered sequence of panels and actions that occur after file installation. • Pre-Uninstall: An ordered sequence of panels and actions that occur before file uninstallation. • Post-Uninstall: An ordered sequence of panels and actions that occur after file uninstallation. • Build: Manage build settings, including bundling of a Java Virtual Machine. Each Advanced Designer task contains sub-tabs that offer greater fine-tuning of InstallAnywhere’s features.

Learn More about InstallAnywhere If you wish to learn more about the capabilities of InstallAnywhere, please visit the Flexera Software Web site at
With InstallAnywhere, developers can build installers for all supported platforms from a single project. InstallAnywhere’s capabilities (highlighted below) make it the ideal tool for quickly developing industrial-strength installers. Rapid Prototyping with the Project Wizard Developers can build their first installer in less than five minutes with InstallAnywhere’s six-step Project Wizard. This intuitive design tool also sets the class path and finds the main class for a Java application automatically. When you complete the Project Wizard steps, the result is an installer project that targets a number of major operating systems. This working prototype is inline with management demands that prototypes be produced early in the development process. The development process demands that the installation be integrated early so that testing can be performed in a more realistic environment.

This, for the most part, means that the installation should have the capability to run in graphical mode and have a consistent look and feel regardless of the operating system. InstallAnywhere contains many tools that make rapid prototyping a reality. Customizing Projects in the Advanced Designer The InstallAnywhere Advanced Designer has an intuitive,
Flexera Software: InstallAnywhere White Paper Series

Action-Based Installers Actions, which represent the operations the installer performs, are the fundamental elements of InstallAnywhere installers. InstallAnywhere supports an extensible action architecture that provides the ability to perform additional operations during installation, such as installing files and folders, creating shortcuts, executing custom code, or extracting the contents of a compressed file. Some frequently used actions include Install File, Create Folder, Create Alias, Link, Shortcut, Execute Target File, Execute Command, and Expand Archive.


Shell vs. Java: Overcoming t he Challenges of Shell Script ing for UNIX Installat ions

Components, Features, and Install Sets Components, features, and install sets are organizational concepts in the InstallAnywhere IDE. They allow installer developers to add structure to the files and actions their installers employ and determine what feature choices end users have during the install. Components are an organization unit installer developers can use to group files and actions; however, components are internal organization units that are never shown to the end user. Conversely, features can group one or more components, files, and actions into combinations from which the installer end users can choose. And groups of features can be combined into install sets—a convention that allows end users to choose options like Minimal, Typical, or Full Install. While developers working with relatively simple installers can rely on InstallAnywhere to generate basic components, features, and install sets automatically, more advanced developers take control of components, features, and install sets to organize their installer resources in the Advanced Designer. Build and Try InstallAnywhere users can quickly examine the results of their project changes by building installers from the project and running the resulting installer with the click of a button. In addition, InstallAnywhere includes several built in features for previewing and debugging your installers and installer panels.

Get User Input Panels InstallAnywhere provides many panels for displaying information to the user and collecting user information. Moreover, InstallAnywhere includes the Get User Input Simple and Get User Input - Advanced panel actions. These actions enable you to build custom panels by inserting textdisplay and user-input controls into the Get User Input panel. InstallAnywhere provides the architecture to capture the user input from these panels to InstallAnywhere variables. For requirements that exceed the Get User Input panel’s features, you can code custom panels that share the dimensions, images, navigation buttons, and other elements used by built-in panels.

Rules and Variables InstallAnywhere keeps track of dynamic values using variables. Almost every dynamic value in InstallAnywhere is represented by an InstallAnywhere variable. Variables may be modified or accessed in order to affect the design or output of an installer; they can also be modified during the progress of the installer in order to change the installer’s behavior. InstallAnywhere uses variable-based Boolean rules to control most aspects of installer behavior. Rules can be applied to any action within the InstallAnywhere installer, as well as to organizational units such as Install Sets, Features, and Components. Rules commonly direct the execution of platform-specific actions on the target system, but they may check other conditions such as system architecture, file and folder attributes, and user-chosen language. Rules can also be used to compare the values of two InstallAnywhere variables, match a regular expression, or to execute a custom coded rule. (InstallAnywhere Enterprise edition also includes rules specific to System i (i5/OS).)

LaunchAnywhere Launchers Create launchers that look and behave like the operating system your installation is running on. Your end users are accustomed to a particular behavior. Windows users are quite familiar with the ubiquitous installer.exe concept. InstallAnywhere LaunchAnywhere launchers extend that philosophy to all of its supported platforms.

Flexera Software: InstallAnywhere White Paper Series

Shell vs. Java: Overcoming t he Challenges of Shell Script ing for UNIX Installat ions

A LaunchAnywhere launcher is a unique executable that launches a Java application on Windows, UNIX (including Solaris, Linux, HP-UX, AIX, BSD, and others), and Mac OS X platforms. On Windows, LaunchAnywhere technology creates double-clickable icons that invoke a Java application. For Mac OS X, it generates application bundles. On UNIX platforms, end users type a simple command to launch the application. LaunchAnywhere technology sets the classpath, redirects stdout and stderr, passes in system properties and commandline parameters, and performs other configuration functions. For graphical users a Web-based applet installation is also available. This further simplifies the distribution model of your product.

custom panels, custom consoles, and custom rules that interact with and extend InstallAnywhere functionality. Custom Dialog Boxes InstallAnywhere provides many built-in dialog boxes for displaying information to the user and collecting user information. Moreover, InstallAnywhere’s Get User Input panels enable you to build up custom dialog boxes by inserting text-display and user-input components into a standard dialog box frame. For more sophisticated userinterface requirements, you can create custom panels that share the dimensions, images, navigation buttons, and other elements used by built-in panels. Shell Revisited As mentioned earlier, shell scripting was intended for system administration. To that end, some scripts are worth keeping. InstallAnywhere facilitates launching existing shell scripts (even the ones that take command line arguments). Since most shell scripts are processed through /bin/sh (the first line in a shell script, the shebang—i.e., #!/bin/sh—tells you who is going to process the script), shell scripts can also be launched through Runtime.exec. This command returns a Process object, which in turn can return the exit value from the sh process. Powered by Java InstallAnywhere is powered by Java. Java is a full-fledged, object-oriented language. Its cross-platform capabilities make it the perfect engine for InstallAnywhere. Besides the common tasks supplied by InstallAnywhere, you might want to add custom tasks that do not fit the ordinary. Since InstallAnywhere is powered by Java, you can extend its functionality in a number of ways. • Create your own custom Java plug-ins: InstallAnywhere enables you to create custom actions written in Java. You can refer to your custom code in a single project, or package it as an InstallAnywhere plug-in that can be used in multiple projects. • Use InstallAnywhere services: In addition to being able to call Java code from your custom code actions, you can call methods from InstallAnywhere services. These services extend Java functionality with underlying native code. Example services are the System Utility Service, for working with environment variables and system startup commands; the Security Service, for working with users and groups; and the Win32 and Win32 Registry Services, for programmatically manipulating Windows services and the Windows registry. • Java Native Interface (JNI): Although Java is a powerful language, some operating system APIs have not been mapped into the core language. JNI is intended to breach that gap. If necessary, you can implement custom functionality in a native library (a Windows DLL or UNIX shared library, for example) and call the native code from an InstallAnywhere custom code action.

Customizing and Extending InstallAnywhere Advanced installer developers or development teams that need to build complex installers can take advantage of a host of enterprise-strength features: • Merge Modules: Essentially installer sub-projects that can be created independently of one another and later merged together, merge module are reusable collections of installation functionality. A Merge Module is just like an installer, complete with features, components, panels, actions, and files. However, a Merge Module cannot be installed without being part of an InstallAnywhere project; instead, use Merge Modules to include the functionality of one installer within another installer. • Support for Deployment to Application Servers and Database Servers: InstallAnywhere supports installers that target application servers (such as Geronimo, JBoss, Resin, Sun Application Server, Tomcat, WebLogic, and WebSphere) and database servers (such as MySQL, Oracle, MS SQL Server, and DB2). • Team Development Features: InstallAnywhere supports team-based installer development with source paths. Source paths allow developers to reference file resources using variable paths instead of absolute paths. This allows team members to share a project file even when file resources are located at different paths on their development systems. • Custom Code: With InstallAnywhere’s API, developers can write custom Java code that runs in the same Java VM as InstallAnywhere, creating custom actions,
Flexera Software: InstallAnywhere White Paper Series

Shell vs. Java: Overcoming t he Challenges of Shell Script ing for UNIX Installat ions

Custom code development in Java is enhanced further when you consider the following: • XML parsing: Java provides out-of-the-box XML parsing through standard parsing technologies such as DOM or SAX. • Use any Java IDE: When writing InstallAnywhere custom code, you can use your own Java IDE. • Unit testing with JUnit: JUnit is a popular regressiontesting framework, and InstallAnywhere provides classes for integrating with JUnit. • Coding standards: Create or extend existing common coding standards to accommodate the development of InstallAnywhere custom code.


Though shell scripting is being criticized for its installation development capabilities, this white paper considers shell scripting a sound technology for UNIX system administration. But for software development, shell scripts lack the robustness needed to create platform independent installations. Java as a technology has matured to the point that creating Java-based installations has become the preferred method. Furthermore, technologies such as JDBC, CORBA, JNDI, and RMI, make Java-based installations the better candidate for targeting platforms such as UNIX. Begin a Free Evaluation of InstallAnywhere You can download a free trial version of InstallAnywhere from the Flexera Software Web site at: Want to learn more best practices for building quality installations? Join an InstallAnywhere training class – visit for available classes.


Flexera Software: InstallAnywhere White Paper Series

Flexera Software LLC 1000 East Woodfield Road, Suite 400 Schaumburg, IL 60173 USA

Schaumburg (Global Headquarters): +1 800-809-5659

United Kingdom (Europe, Middle East Headquarters): +44 870-871-1111 +44 870-873-6300

Japan (Asia, Pacific Headquarters): +81 3-4360-8291

For more office locations visit:

Copyright © 2011 Flexera Software LLC. All other brand and product names mentioned herein may be the trademarks and registered trademarks of their respective owners. IA_WP_Shell_Oct11