Exporting Environments Made Easy

Chris Clifton

Working with different computer architectures and operating systems in one network can make the ability for applications to work with ease across all platforms a must. In particular, working in a multi-platform environment and logging into various machines remotely can make for a display nightmare. When done manually, as in most operating systems, exporting the DISPLAY value can be an overwhelming task. If users fail to properly export their DISPLAY environmental variable, applications will attempt to use the default 0.0 value, the host's console, while the user who needed the application waits for a display that will never appear. The display_s program, presented here, automates the process of exporting the DISPLAY environmental variable.

The network in our building consists of 11 SUN stations, eight HP 9000 series computers, two Vaxes, six Windows 95 PCs, one Windows NT box, and about 60 Linux systems. With our network being so diverse, logging in from one machine to another and running applications needs to be as painless as possible. To accomplish this objective, display_s runs on the servers (the SUN and HP systems on our network), exporting the display to the user's local machine or to the server console, as appropriate. Cross-platform portability was a key factor for the program, so I kept it as generic as possible. While it should run on most implementations of UNIX, I have verified its operation on Sun and HP systems (SUN-OS 4.1.2 to Solaris 2.5.1 and HP-UX 9.05 to 10.10). I have written several versions of display_s - shell versions for bash/ksh (shown in Listing 1) and csh Listing 2, a Perl version, and a C version. A sed script used by both shell versions is shown in Listing 3. The Perl and C versions are available on the Sys Admin FTP site (ftp://ftp.samag.com), along with installation instructions in the form of a readme file. I am also working on a Python version.

Program Development

This program started out as an innocent shell script and over time evolved into a Perl script and a C program. The script version needed two generic scripts: one for csh and tcsh users and one for bash and ksh users. Since the shell syntax is so radically different, the shell-specific scripts could not easily be combined into one.

I started this script file wanting it to be as generic as possible, but I did need the help of sed and awk to parse data. I could have chosen Perl for that task, but opted for sed and awk for portability reasons.

I used the same basic design philosophy on all three versions of display_s. First I extracted the tty port the user is accessing. Second, I checked the operating environment (i.e., SUN-OS, Linux, HP-UX, etc.). Next, I do a who system call and match up the tty port to the users computer name. By cross referencing I now know which computer to export the display back to. Last, all I need is to export the DISPLAY variable back to the users computer name. Now any applications running on this server machine know to export their displays back to the client machine.

Perl Development

The Perl version of this program works for csh, tcsh, bash, and ksh. I developed this version from the shell script version and tried to keep the same tmp file names and variable names. I also tried to follow the same internal design. This may have led to inefficient code in places, but made comparing the designs easier. For portability reasons, I chose an early version of Perl for development. Although later versions of Perl may provide more efficient ways to accomplish the same tasks, I have run this code on every version of Perl I have and it seems to run fine.

C Development

The C version of this program has a top-level script file to activate it. I have two script files again like the shell script version, one for csh and tsch users and one for bash and ksh users. I tried the same code as in the Perl version but importing environmental variables posed a problem - the customary source and dot techniques failed to do the trick. Thus, I had to write and read a file to set environmental variables and export them for the shell script controlling the program. In this respect Perl seems to work better. Again, I tried to follow the same internal design as the two shell versions. In C, this may have been a mistake. While everything works, C system calls would likely be far more efficient.

Support Programs

I wrote a Perl support program, shown in Listing 4, to create the edit_real.sed sed script used by the shell version of the display_s program. We have been in the process of changing our domain name and this program makes the change an easy one. It also allows for the use of long host names if so desired. A shell script to change protections correctly is shown in Listing 5. Examples of the temporary files used by the scripts are shown in Listing 6.

Problems

I have had problems with the csh version when I check a variable but fail to set it. I commented out this part of the code and added comments to explain. Not setting the DISPLAY variable seemed to cause a problem. By commenting out this section, if you set the display in a script file before actually logging in to the remote system, the DISPLAY variable will be overwritten. Also, logging in to a machine through another machine sets the display incorrectly. When using rsh or remsh to run a program, if the application that you are trying to access does not support the -d option to export the display, you will need to add a wrapper script. This is only a problem if you rsh or remsh via a one-line script, in which case a TTY port is not set. Thus, the workaround is to create a wrapper script. An example would be:

..
Create a wrapper file xwp_s. In it:

#---------- file xwp_s -----------------
export DISPLAY=
xwp
#---------- -end xwp_s -----------------

Then you can effectively run:

rsh hostname1:xwp -d host_name2

by calling it from the rsh or remsh script:

rsh hostname1:xwp_s -d host_name2.

Conclusion

This program helped me to see the need for standard Posix calls and standard shells. While the basic premise of the program is easy, making it work in a platform-independent manner was not. Which version of the display_s program would I recommend using? They all work well and at approximately the same speed. The next step would be to add to the program other environment variables that need to be set and exported, such as TERM, HOME, EDITOR, and AUDIO.

About the Author

Chris Clifton has worked on Tactical Software at Naval Surface Warfare Center in Crane IN for almost 10 years, and has been a System Administrator for about eight years. He received a Bachelor of Science in Electrical Engineering from Purdue University in 1987.