Environment variables in Workspace

[Rob Warnock]

In article <64370 at sgi.sgi.com> betsy at vesuvius.UUCP (Betsy Zeller) writes:
+---------------
| martin at zoo.toronto.edu (Martin Hofmann) writes:
| >The default setup on our system is for Workspace to run at login time.
| >It appears that Workspace is run before .cshrc and thus all environment
| >variables that are set in .cshrc are ignored by Workspace...
| If you run the User Tool from the System Administration tool, open the icon
| representing your account, and set WorkSpace 'on' by clicking that button, 
| WorkSpace will automatically start up each time you start up the system.
| Both your .login and .cshrc variables will be exported to the NeWS 
| environment before WorkSpace is started.
+---------------

In case Betsy's suggestion doesn't fix it, here are some additional things
that can cause trouble. [Note: I am not a developer of WorkSpace or the
window system, just a user who has bumped into similar difficulties before.]

1. As things are coming up, in "init.ps" the routine "basicRestartActions"
   runs "establishEnvironment" before anything else, including "autoWorkSpace".
   It is "establishEnvironment" which sucks your environment variables up into
   the NeWS server (from your .login and .cshrc). The "basicRestartActions"
   routine also starts up the standard set of toolchests. A common thing for
   users to do is to redefine "basicRestartActions" to be empty, and do the
   whole thing from "RestartActions" in their "~/user.ps" file, so they can
   reconfigure the order of the toolchests, etc. If you have changed either
   "RestartActions" or "basicRestartActions" in this way, make sure that
   "establishEnvironment" is still run before anything else, or your
   environment variables will not get defined. (Once a toolchest -- or
   anything else, for that matter -- has been forked, there is no way to
   communicate environment changes to it.)

2. The method "establishEnvironment" uses to get your environment variables
   (a program called "exporttonews") can be confused by spurious output during
   the execution of your .cshrc or .login files, possibly leading to some of
   your environment variables not being passed back up to the NeWS server
   correctly (and thus not ever getting passed down to WorkSpace). There is
   a way for your .cshrc/.login files to know when they are being called by
   "exporttonews", so they can 'be quiet': "exporttonews" defines the
   environment variable "ENVONLY". Thus, if you put any commands which
   might do output inside a negative test for "ENVONLY" being defined,
   things may improve. For example:

	if( ! $?ENVONLY )then   # avoid confusing "exporttonews"
		stty line 1 erase '^H' kill '^U' intr '^C' echoe 
		eval `tset -s -Q`
		setenv TTY `tty`
	endif

   Note that any program that requires a "tty" on its stdin/stdout/stderr is
   likely to generate an error message when run from "exporttonews", and thus
   should be 'protected' by such a test of "ENVONLY".

3. There was a bug in the 3.2 version of the NeWS server (fixed in 3.3) which
   could lose a bunch of environment variables in the server (and thus in any
   program it forked, such as WorkSpace) if an environment variable was defined
   whose name was a leading prefix of the name of a variable already defined.
   For example, if "EDITOR" were already defined, then defining "EDIT" could
   corrupt the environment. You can work around this one by putting the defines
   for one the conflicting variables (either the long one or the short one)
   inside a conditional test for $ENVONLY, as shown in #2. [Of course, the
   workaround is not perfect. Any variables you so shield will not be available
   from within WorkSpace or programs run from WorkSpace.]

You can debug these environment variable problems by putting the following
code at the beginning of your .login, then logging out and back in again:

	# debug NeWS environment
	if( $?ENVONLY )then
	       /bin/env > ENV.initial
	else
	       /bin/env > ENV.news
	endif

[This assumes that you define no environment variables in .cshrc. If you do,
a more complicated procedure is necessary to prevent overwriting the capture
files at the wrong time. I leave that as an "exercise for the reader".] After
you are logged in again, run the command:

	/bin/env > ENV.wsh

Now, the file "ENV.initial" will show you what the environment was just
as "exporttonews" was about to get your environment variables; "ENV.news"
will show what it was after "exporttonews" but before any changes made
during your .login processing; and "ENV.wsh" will show you what you've
got now. The variables defined in "ENV.news" are the ones which programs
run directly from the NeWS server (such as WorkSpace, if it's autostart'd)
will inherit. If there are any significant differences between "ENV.news"
and "ENV.wsh" (other than perhaps "$TTY"), then you probably have one or
more of the above problems.

The reason you don't see the problem(s) when you run WorkSpace manually
from "wsh" is that by then your environment has been fixed up again by your
.cshrc/.login being run a second time as "csh" was coming up inside the "wsh".
(Actually, they're run once for each "wsh/csh" window you have.) And "csh"
doesn't have any of the above problems.

Hope this helps,


-Rob

-----
Rob Warnock, MS-9U/510		rpw3 at sgi.com		rpw3 at pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311