perform other tasks such as setting variables and assigning processes to other users. For example, an application may need a Java™ Virtual Machine (JVM) to execute. In that case, shell scripts can set the appropriate environment variables and then execute the Java command to run the Java Archive (JAR) or class file. This holds true for applications using Perl, Python, and even C#. (Yes, C# compiled applications can run on Linux!)
You can execute a command from the command line or shell prompt with just the file name if the command is a part of the shell’s built in commands, or if the command’s directory location is included in the PATH variable. Commands such as "ls" and "cd" are examples of commands that are generally included in the PATH by default as they typically reside in the /usr/local/bin or /usr/bin directories. But if the file location is not set in the PATH, you must include the pathname to the file. For example, if the executable myapp resides in the /usr/share/scripts directory, type
/usr/share/scripts/myapp to execute the script. You can also use the relative path by adding the dot (.) and slash (/) before the file name and type
./myapp. The dot (.) in the shell specifies the "current directory." (Windows includes the working directory on the execution path and some system administrators have been known to include the dot (.) in the PATH to emulate this, but this is not advisable for security reasons.) Likewise, you can precede the file name with the language environment such as:
More often though, packaged applications have shell scripts that set the
environment variables and provide the runtime executable path of the language
#! symbol, such as
#!/usr/bin/python. You should become familiar
with this approach as well.
Listing 1 uses the
catalina.sh default script to start the Apache
Tomcat application server using the
approach. Then it starts the server using the
sh approach. Since the default port is 8080, no
special modifications are required to start the service as a standard
Listing 1. Executing an application from the command line
$ ./catalina.sh start Using CATALINA_BASE: /opt/apache-tomcat-7.0.26 Using CATALINA_HOME: /opt/apache-tomcat-7.0.26 Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.26/temp Using JRE_HOME: /usr Using CLASSPATH: /opt/apache-tomcat-7.0.26/bin/bootstrap.jar: /opt/apache-tomcat-7.0.26/bin/tomcat-juli.jar $ ./catalina.sh stop ..................................................................... $ sh catalina.sh start Using CATALINA_BASE: /opt/apache-tomcat-7.0.26 Using CATALINA_HOME: /opt/apache-tomcat-7.0.26 Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.26/temp Using JRE_HOME: /usr Using CLASSPATH: /opt/apache-tomcat-7.0.26/bin/bootstrap.jar: /opt/apache-tomcat-7.0.26/bin/tomcat-juli.jar
Consider starting a typical Hypertext Transfer Protocol (HTTP) web server. In Linux, any port less than port 1024 is considered a privileged port, and only root can open privileged ports. Because web servers by default run on port 80, root needs to start the process. As noted, however, it is considered insecure to run a service as the root user. The correct procedure is to start the service as root and then hand it off to a standard user or service account.
Fortunately, a lot of server services have the scripts in place to do just
that. If you build the Apache web server from source, you find it starts
as root and then hands off the httpd threads to the
Listing 2 starts a default compilation of the Apache 2
web server. The install process does a few things, including making the
apachectl command executable. Because this
process requires use of port 80, it starts with root user privileges.
ps command reveals the httpd
processes are running under the apache user account.
Listing 2. Starting the Apache web server
# cd /usr/local/apache2/bin # apachectl start #ps aux | grep httpd apache 23094 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start apache 23095 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start apache 23096 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start apache 230