|< Free Open Study >|| |
This section will discuss how to tailor the generic example shown in the preceding section to specific distributions. Since generally installing the J2SDK consists of extracting the files and modifying the users' login environments, tailoring the installation for a distribution is as simple (or as complicated!) as hooking Listing 13-1 into the global user login scripts.
As discussed in Chapter 4, Red Hat Linux makes extensive use of the drop-in configuration file directory technique. The drop-in directory for user shell environment customization is /etc/profile.d. Recall that the top-level login scripts simply invoke files in /etc/profile.d-the bash shell invokes files that end in .sh, and the tcsh shell invokes files that end in .csh.
See the section "User Environment" in Chapter 4 for details on Red Hat Linux's user environment configuration.
Customizing the J2SDK installation on Red Hat Linux, then, is as easy as placing the shell script in Listing 13-1 into the /etc/profile.d directory; a good choice might be to name the file /etc/profile.d/java.sh. For tcsh users, the version of Listing 13-1 in csh syntax could be placed in /etc/profile.d/java.csh. (This version of Listing 13-1 can be found on the book's web site.)
One important caveat, however, is how users individually override the default JDK location. The script in Listing 13-1 checks to see if the user already has a JAVA_HOME variable set and only sets it to the default if the user doesn't already have one. However, since this script will be invoked from the global login process before the user's personal scripts are, the user will have no opportunity to reset the JAVA_HOME variable. Fortunately, all the user has to do is simply log in, set the JAVA_HOME variable manually, and then re-source /etc/profile.d/java.sh to reconfigure the shell (using the command such as . /etc/java.sh for users of bash).
As discussed in the section "Customizing the User Environment" in Chapter 5, Slackware Linux has a fairly simple mechanism for handling login scripts. On the one hand, this makes it easy to customize manually, but on the other hand makes it more difficult to customize automatically. That is, adding Listing 13-1 to the login process on Slackware Linux isn't as easy as just dropping a file into a directory (as is true of Red Hat Linux mentioned earlier).
Instead, the administrator will have to modify the global login scripts to add support for Java to the users' environments. The first solution to suggest itself is to simply copy the script in Listing 13-1 and paste it directly into the /etc/bashrc file (after removing the first line-#!/bin/sh). This would work fine, but then the global script is that much longer. A better solution might be to copy the contents of Listing 13-1 into the /etc directory (such as a file named /etc/javarc.sh), and then add a reference to it from /etc/bashrc, as this example shows:
if [ -f /etc/javarc.sh ]; then . /etc/javarc.sh fi
The disadvantage of this approach is that if there are many such files being installed (in addition to just the one file for the J2SDK), then the /etc directory may become cluttered. So, it's a trade-off: a single monolithic shell script, or multiple files that may add clutter. It really comes down to a matter of preference on the administrator's part.
The users' login shell environment on Debian GNU/Linux is set up in a similar fashion to that of Slackware Linux. That is, the files /etc/profile, /etc/bashrc, /etc/csh.cshrc, and /etc/csh.login are used to configure the users' various shells. These scripts on Debian GNU/Linux are similar to but have different contents from their counterparts on Slackware Linux. As a result, connecting the J2SDK installation described in this chapter is very similar to the process described in the previous section on Slackware Linux, though there will be some minor differences. By now you should have no trouble with this.
|< Free Open Study >|| |