1. Shell vs. Java: Overcoming the
W H I T E PA P E R
Challenges of Shell Scripting for
UNIX Installations

2. Shell vs. Java: Overcoming the Challenges
of Shell Scripting for UNIX Installations
Introduction Web servers, shell-based installations are rarely a viable
A shell is a command-line interpreter that takes and executes delivery option. This delivery mechanism becomes more
commands, and in doing so, implements a programming difficult when you reanalyze how the tar archive is built. The
language commonly referred to as “shell scripting.” Shell configuration management team has to produce a directory
scripting is traditionally used by UNIX system administrators structure that will mimic the final destination.
to automate the execution of system tasks, but developers
also use shell scripts to create enterprise-level software In addition, it is well known that tar-ball installations are
installations, and that is where problems occur. not user-friendly to regular users. This is due to the absence
of visually guided installations, as is the accepted standard
This white paper highlights the major difficulties with for Windows applications. As a result, they often introduce
attempting to develop UNIX installations using shell scripts. barriers to user adoption of applications, and may even
It focuses on shell scripting as a language and how it is cause problems with the installation and maintenance of
used in the context of UNIX installation development. It also the applications.
discusses how Java is being used as a successful alternative
to shell scripting for enterprise installations. UNIX Installations: The Way They Ought to Be
Installations, regardless of the targeted operating system,
Finally, this white paper details how the tools in should be easier to implement. The “tar-ball” file archive
InstallAnywhere®, the multi-platform installation tool from structure should not be decided upon by the build system.
Flexera Software, can help developers overcome the This should be loosely packaged so that the installation can
inherent problems with shell scripting and create high- make the final decision on how the final file structure
quality multi-platform installations ideal for enterprise should look.
environments.
The installation technology used should be based on a more
UNIX Installations: The Tar-Ball Archive robust language with built-in parsing capabilities for XML,
Most UNIX shell-based installations are constructed using Java properties files, and so on. Finally, the installation
a “tar-ball” (tar archive) paradigm. A tar file is delivered should give the user the option of running the installation
whose contents include a shell script and the files to be in a graphical mode.
installed. For the most part the files are stored in a structure
mimicking that of their final destination. This potentially Ultimately, customers and installation developers want
means that a single copy (cp) command is invoked to copy the same thing, a robust installation system. However,
the entire directory to the home directory. All necessary their perspective is different. The customer cares about
configurations are done with the help of commands such the final product, whereas the developer cares about
as “sed”, “awk”, and so on. The user interface provided is the development environment needed to produce UNIX
console only. installations. The following lists are a subset of requirements
as demanded by customers and installation developers.
By and large, the above scenario is acceptable for simple
applications. However, it becomes very hard to follow when For customers:
even the most straightforward enterprise installations are • Ease of use – Most customers want an easy way to
attempted. If the installation you are attempting to construct interact with an installation, preferably one that is
is required to configure application servers, databases, or visually guided, such as those offered by Windows.
2 Flexera Software: InstallAnywhere White Paper Series

3. Shell vs. Java: Overcoming t he Challenges of Shell Script ing for UNIX Installat ions
• Single point of initiation – An end user attempting installation and received the same error. Only this time the
to invoke your installation should not be confronted error occurs at line 4559. Debugging is not available unless
by a plethora of installation options. A single native you type:
launcher should suffice.
• Native look and feel – It is important that users receive % sh -x install.sh
an installation that looks and feels like any other
application targeted for that particular operating The above does not yield results that someone with limited
system. shell-scripting knowledge can understand.
• Get the product installed – The ultimate goal of
the installation is to get the product installed and The problem is worsened when the script contains a
configured. statement similar to myvar=`cat $1`. If $1 is not initialized,
the script will be stuck. Of course, a diligent programmer
For installation developers: doesn’t allow this to happen, but if it does happen,
debugging can be a nightmare.
• Single point of development – A true cross-platform
development platform that would allow the developer Other issues with the script come to light when you consider
to maintain a single code base for numerous platforms. the problems associated with localization and permissions
• The development environment should use a familiar (“To install, you need admin rightsn”), and dealing with a
language, preferably object oriented – To allow nonstandard logging (to install.log) mechanism.
extensibility, the installation development tool should
enable the developer to extend it. The point of this exercise was to show how difficult it can be
• Operating system abstraction – When developing to develop elaborate enterprise installations using shell.
cross-platform installations, the developer should focus
on product installation and configuration tasks and not Interoperability
how each operating system works. Even though shell was never intended for large
development, shell scripting is sometimes used to create
Analyzing the Shell Scripting Environment large installation projects, such as enterprise installations.
The concept of shell scripting was introduced to help These installations need to directly communicate
system administrators automate low-level shell commands. configuration settings to the product being installed. For
For a long time most companies have used shell scripts as shell-based installations, this is done using input files or the
delivery mechanisms (that is, installations), which, for the command line. Error handling, for the most part, is done
most part, worked well. Since shell scripts are delivered using return codes.
in clear, readable ASCII, they can potentially expose
implementations that can pose as security holes. Unfortunately, return codes are not always reliable.
Sometimes a command may return 0 when in fact it should
Unfortunately, that is not the only weakness shell scripting return anything but 0. Extra steps need to be taken to ensure
exposes. The following sections highlight why shell scripting reliability, which can turn into unnecessary complex if-
does not scale when enterprises attempt to use it as an statements that make interoperability all the more difficult.
installation development platform.
Sharing Code
The Development Environment When developing large-scale enterprise installations, you
Shell is littered with hard-to-understand regular expressions can expect more than one developer to work on the same
and lacks a true integrated development environment (IDE). code. Your plan, of course, is to develop reusable libraries
It often takes a truly senior UNIX developers to properly that can be used across the installation system. However,
handle such complex scripting environments. Consider the shell was not designed with that in mind. Shell is for the
following syntax: most part used to automate administration tasks such as
“empty the temp space” or “manage users.” It was designed
CURRENT_USER=`whoami | awk ‘{print $1}’` to deal with low-level tasks, not code sharing.
if [ “$CURRENTUSER” != “root” ] && [ “$CURRENT_USER”
!= “admin” ]; then printf “To install, you need admin Portability
rightsn” | tee -a Not all UNIX environments are created equal. Some
install.log fi commands work in every UNIX environment; some do
not. Sometimes commands such as “pidof” do not exist in
If you take a closer look, you will notice how awkward the environments other than Linux. Furthermore, some utilities
if-statement really is. If you play with the white-spacing in do not share the same command-line arguments across all
the if-statement, you may receive an error similar to this one: UNIX implementations. Besides, would you like to learn all
the command-line options offered by UNIX commands such
./install.sh: line 2: [CURRENT_USER: command not found] as “ls”? To account for portability, a great deal of code must
be written.
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 3

4. 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 public String getInstallStatusMessage( ) { return
XML were available. Therefore, its abilities for parsing such “Computing time stamp...”; }
formats are based on regular expressions. For the most part,
regular expressions are hard to write and even harder to public void uninstall(UninstallerProxy up) { /* do nothing
debug. To consider writing regular expressions for parsing on uninstall */ }
XML would put you in the business of building XML parsers public String getUninstallStatusMessage( ) { return “...”; }
from scratch. Modern languages such as Java and C++ }
have XML parsers built-in.
First and foremost, the above code is standard Java code.
Parsing becomes more of a problem when unknown formats In addition to being able to use standard Java functionality,
are met. New regular expressions must be built, or you Java code can use JNI to call in to native code. The
could write a native executable using C/C++ to do the job. interesting thing about JNI is the fact that as far as the
Once again, interoperability becomes questionable. Java developer is concerned, the JNI call is just another
Java call.
The Linux Factor
With the introduction of Linux, a large number of non- Worth noticing is also the exception handling offered by
UNIX users entered the UNIX arena. From a strategic Java. Logging is another powerful Java feature. To facilitate
point of view, it gives a large number of users the chance readability, logging information can be categorized by
to diversify. On the other hand, most of these new users severity and the output can be formatted as XML, which in
come from GUI-driven operating systems, and they want turn can be transformed into HTML so that customers can
everything be done with graphical tools. But shell-based view install logs in a readable format.
installations are made to be console-driven – no
graphical interface. Java has emerged as a very popular technology, and for
good reasons. Most educators have embraced Java as
Mac OS X their teaching language of choice, creating a large pool
Mac OS X is further proof that UNIX is becoming more of Java developers. The attractiveness of Java as a “write
accepted as a graphical operating system. Besides making once, run everywhere” language has certainly been another
Mac OS X the most optimized UNIX environment to run contributing factor to its popularity.
Java, Apple has made Java an integral part of Mac OS X,
which is good news if your strategy is to create Java-based Another strong supporting argument for Java-based
installations. But shell-based installations must once again installations is that numerous companies deploy application
take a back seat. servers such as IBM® WebSphere®, BEA® WebLogic®,
Sun® Java Enterprise System, or JBoss. For scalability and
Java-Based Installations reliability purposes, these are mostly deployed on the UNIX
If not shell scripting, what then is a feasible alternative platform and are Java-based.
technology for developing cross-platform installations?
What about Java? Its “write once, run everywhere” makes Most application servers expose Java configuration APIs.
it an ideal technology for targeting platforms such as UNIX. This allows for a seamless integration strategy that can
Java transforms the installation development into a more ultimately give users an out-of-the-box delivery solution. The
robust environment. interesting point here is that “write once, run everywhere”
becomes an attainable reality.
To appreciate the power of Java to extend an installation,
consider an example. The following is a simple Java class As an alternative to shell scripting, however, Java requires
that computes a time stamp and stores the result in a custom additional help before it can be considered as a logical
InstallAnywhere variable. successor. A reliable, user-friendly Windows-like setup
experience would be a great thing to have for UNIX
import com.zerog.ia.api.pub.*; developers. The ability to target UNIX and Windows
import java.util.*; platforms with a Java-based application install would be
even better, especially given how difficult it is to accomplish
public class GenerateTimeStamp extends this with shell scripting.
CustomCodeAction
{ For the developer with lots of experience with tar-balls and
public void install(InstallerProxy ip) cryptic script commands, any alternative needs to offer
{ clear and compelling benefits. The balance of this paper
// compute time stamp with Java... will offer just such an argument, based on the capabilities
String now = new Date( ).toString( ); of InstallAnywhere from Flexera Software.
// ...and set a custom variable to the value
ip.setVariable(“$NOW$”, now);
}
4 Flexera Software: InstallAnywhere White Paper Series

5. Shell vs. Java: Overcoming t he Challenges of Shell Script ing for UNIX Installat ions
Building Multi-Platform Installations with graphical interface, which allows developers to manage
InstallAnywhere all aspects of their installer project. All the features of
InstallAnywhere from Flexera Software provides an out-of- InstallAnywhere are available in this easy to use integrated
the-box Java-based installation solution. Developing cross- development environment.
platform installations with Java and InstallAnywhere’s multi-
platform installation IDE provides many benefits, including Advanced Designer Tasks
making it easy to: The Advanced Designer is divided into tasks that are
represented by tabs found along the left-hand side of the
• Tightly integrate installation development into the window. Each of the following tabs represents tasks and
development department settings specific to each installation project:
• Conceal code so that proprietary implementations are
kept safe • Project: Settings related to your specific project.
• Create installations that can be extended and These include general settings, file settings, and
developed using Java technologies localization settings.
• Installer UI: Set the look and feel for the installer by
Learn More about InstallAnywhere adding background images, billboards, and other
If you wish to learn more about the capabilities of graphical components.
InstallAnywhere, please visit the Flexera Software Web • Organization: Manages Install Sets, Features,
site at www.flexerasoftware.com/installanywhere. Components, and Merge Modules.
• Pre-Install: An ordered sequence of panels and
actions that occur before file installation.
With InstallAnywhere, developers can build installers for all • Install: Manage File installation tree and install
supported platforms from a single project. InstallAnywhere’s time actions.
capabilities (highlighted below) make it the ideal tool for • Post-Install: An ordered sequence of panels and actions
quickly developing industrial-strength installers. that occur after file installation.
• Pre-Uninstall: An ordered sequence of panels and
Rapid Prototyping with the Project Wizard actions that occur before file uninstallation.
Developers can build their first installer in less than five • Post-Uninstall: An ordered sequence of panels and
minutes with InstallAnywhere’s six-step Project Wizard. This actions that occur after file uninstallation.
intuitive design tool also sets the class path and finds the • Build: Manage build settings, including bundling of a
main class for a Java application automatically. When you Java Virtual Machine.
complete the Project Wizard steps, the result is an installer
project that targets a number of major operating systems. Each Advanced Designer task contains sub-tabs that offer
greater fine-tuning of InstallAnywhere’s features.
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.
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
This, for the most part, means that the installation should frequently used actions include Install File, Create Folder,
have the capability to run in graphical mode and have a Create Alias, Link, Shortcut, Execute Target File, Execute
consistent look and feel regardless of the operating system. Command, and Expand Archive.
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 5

6. 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 Build and Try
can use to group files and actions; however, components InstallAnywhere users can quickly examine the results of
are internal organization units that are never shown to the their project changes by building installers from the project
end user. Conversely, features can group one or more and running the resulting installer with the click of a button.
components, files, and actions into combinations from In addition, InstallAnywhere includes several built in features
which the installer end users can choose. And groups of for previewing and debugging your installers and installer
features can be combined into install sets—a convention panels.
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 Get User Input Panels
Advanced Designer. 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 text-
display 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, LaunchAnywhere Launchers
and Components. Rules commonly direct the execution Create launchers that look and behave like the operating
of platform-specific actions on the target system, but they system your installation is running on. Your end users are
may check other conditions such as system architecture, file accustomed to a particular behavior. Windows users are
and folder attributes, and user-chosen language. Rules can quite familiar with the ubiquitous installer.exe concept.
also be used to compare the values of two InstallAnywhere InstallAnywhere LaunchAnywhere launchers extend that
variables, match a regular expression, or to execute a philosophy to all of its supported platforms.
custom coded rule. (InstallAnywhere Enterprise edition also
includes rules specific to System i (i5/OS).)
6 Flexera Software: InstallAnywhere White Paper Series

7. Shell vs. Java: Overcoming t he Challenges of Shell Script ing for UNIX Installat ions
A LaunchAnywhere launcher is a unique executable custom panels, custom consoles, and custom rules that
that launches a Java application on Windows, UNIX interact with and extend InstallAnywhere functionality.
(including Solaris, Linux, HP-UX, AIX, BSD, and others),
and Mac OS X platforms. On Windows, LaunchAnywhere Custom Dialog Boxes
technology creates double-clickable icons that invoke a InstallAnywhere provides many built-in dialog boxes for
Java application. For Mac OS X, it generates application displaying information to the user and collecting user
bundles. On UNIX platforms, end users type a simple information. Moreover, InstallAnywhere’s Get User Input
command to launch the application. panels enable you to build up custom dialog boxes by
inserting text-display and user-input components into a
LaunchAnywhere technology sets the classpath, redirects standard dialog box frame. For more sophisticated user-
stdout and stderr, passes in system properties and command- interface requirements, you can create custom panels that
line parameters, and performs other configuration functions. share the dimensions, images, navigation buttons, and
For graphical users a Web-based applet installation is also other elements used by built-in panels.
available. This further simplifies the distribution model of
your product. 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.
Customizing and Extending InstallAnywhere
Advanced installer developers or development teams that Besides the common tasks supplied by InstallAnywhere, you
need to build complex installers can take advantage of a might want to add custom tasks that do not fit the ordinary.
host of enterprise-strength features: Since InstallAnywhere is powered by Java, you can extend
its functionality in a number of ways.
• Merge Modules: Essentially installer sub-projects that
can be created independently of one another and • Create your own custom Java plug-ins: InstallAnywhere
later merged together, merge module are reusable enables you to create custom actions written in Java.
collections of installation functionality. A Merge You can refer to your custom code in a single project,
Module is just like an installer, complete with features, or package it as an InstallAnywhere plug-in that can be
components, panels, actions, and files. However, a used in multiple projects.
Merge Module cannot be installed without being part • Use InstallAnywhere services: In addition to being able
of an InstallAnywhere project; instead, use Merge to call Java code from your custom code actions, you
Modules to include the functionality of one installer can call methods from InstallAnywhere services. These
within another installer. services extend Java functionality with underlying
• Support for Deployment to Application Servers and native code. Example services are the System Utility
Database Servers: InstallAnywhere supports installers Service, for working with environment variables
that target application servers (such as Geronimo, and system startup commands; the Security Service,
JBoss, Resin, Sun Application Server, Tomcat, for working with users and groups; and the Win32
WebLogic, and WebSphere) and database servers and Win32 Registry Services, for programmatically
(such as MySQL, Oracle, MS SQL Server, and DB2). manipulating Windows services and the Windows
• Team Development Features: InstallAnywhere supports registry.
team-based installer development with source paths. • Java Native Interface (JNI): Although Java is a powerful
Source paths allow developers to reference file language, some operating system APIs have not been
resources using variable paths instead of absolute mapped into the core language. JNI is intended to
paths. This allows team members to share a project file breach that gap. If necessary, you can implement
even when file resources are located at different paths custom functionality in a native library (a Windows
on their development systems. DLL or UNIX shared library, for example) and call the
• Custom Code: With InstallAnywhere’s API, developers native code from an InstallAnywhere custom code
can write custom Java code that runs in the same action.
Java VM as InstallAnywhere, creating custom actions,
Flexera Software: InstallAnywhere White Paper Series 7

8. 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 regression-
testing 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.
Summary
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: www.flexerasoftware.com/installanywhere/eval.
Want to learn more best practices for building quality
installations? Join an InstallAnywhere training class – visit
www.flexerasoftware.com/training for available classes.
8 Flexera Software: InstallAnywhere White Paper Series

9. Flexera Software LLC Schaumburg United Kingdom (Europe, Japan (Asia, For more office locations visit:
1000 East Woodfield Road, (Global Headquarters): Middle East Headquarters): Pacific Headquarters): www.flexerasoftware.com
Suite 400 +1 800-809-5659 +44 870-871-1111 +81 3-4360-8291
Schaumburg, IL 60173 USA +44 870-873-6300
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