martin@zoo.toronto.edu (Martin Hofmann) (07/17/90)
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. In particular WINEDITOR is set to vi in .cshrc but Workspace still uses jot and a program that tests for terminal type receives 'unknown' instead of 'iris-ansi' Is there any way (other than running Workspace after login) to get Workspace to use the environment variables at login time? I do not want to depend on running Workspace after login because other users may want to use the application that depends on terminal from their Workspace started at login. Thanks in advance martin -- The world is sacred. You cannot improve it. | Martin Hofmann, U of Toronto If you try to change it, you will ruin it. | martin@zoo.toronto.edu If you try to hold it, you will lose it. | martin@zoo.utoronto.ca Lao Tsu, "Tao Te Ching" | uunet!attcan!utzoo!martin
betsy@vesuvius.esd.sgi.com (Betsy Zeller) (07/18/90)
In article <1990Jul17.035542.9411@zoo.toronto.edu> martin@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. In particular >WINEDITOR is set to vi in .cshrc but Workspace still uses jot and a >program that tests for terminal type receives 'unknown' instead of 'iris-ansi' >Is there any way (other than running Workspace after login) to get Workspace >to use the environment variables at login time? I do not want to depend on >running Workspace after login because other users may want to use the >application that depends on terminal from their Workspace started at login. 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. Thus, I can setenv EDITOR /usr/bin/vi in my .cshrc, and get the editor I expect (vi) when I double click or open a text file. Also, though this may have been a typo in the original message, you probably want to use the EDITOR environment variable to set up vi, because is intended for editors which don't invoke their own windows. WINEDITOR expects its editor to start its own window. Betsy Zeller betsy@sgi.com
rpw3@rigden.wpd.sgi.com (Rob Warnock) (07/18/90)
In article <64370@sgi.sgi.com> betsy@vesuvius.UUCP (Betsy Zeller) writes: +--------------- | martin@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@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311