Traversing between Eunice and VMS

manheimer at nbs-amrf.UUCP manheimer at nbs-amrf.UUCP
Wed Jun 6 01:15:49 AEST 1984


In the following fragment from my login.com, i define some symbols that
provide a convenient way to initiate a shell such that its suspension will
take you back to the superior process (instead of instigating a new shell,
with its attendent startup costs).  The convolutions with the pid provide a
per-process distinct name for the shell, so that every login process may
have one (and only one if they stick to this mechanism) Eunice shell with a
distinct name.

$ pid ==  f$getjpi("","PID")
$ resh == "shell_" + pid
$ ecsh == "SPAWN/PROCESS=''RESH' CSH"
$ resh == "attach ''resh'"

With this done i go into the cshell using the command `ecsh'.  To return to
the cshell (after `suspend'ing out of it) I would say `resh'.  Traversing
between VMS and Eunice is considerably quicker this way, generally much
faster, say, than an `ls' command, more on par with a `ps'.

The benefits of this come from a sort of arcane behavior of Eunice process
images that can suspend themselves; if they're subordinate to another
process, even a normal DCL process, they pass control back to that process.
Another example of this is the way i call vi from VMS.  Here's some more
from that same login file:

$ vimage == "$UNIX:[USR.UCB]VI VI"
$ vi == "spawn/process=vi_klm vimage"

Again, when this vi is paused control returns to VMS, and i can return to vi
by saying `attach vi'.

Unfortunately, this doesn't account for one Eunice limitation that I've been
looking to get around for a while.  I'd like to be able to dynamically
effect the VMS environment of a Eunice shell (specifically, privileges and
logicals) from within the shell itself.  Of course, the shell environment is
inherited when it is spawned from the parent process, but they're distinct
from then on.  Changing the environment of the parent afterwards will not
effect the child (hard to ignore the psychological interpretations, hmm?).
Furthermore, setenv, which is supposed to provide the mechanism for
effecting VMS logicals works very strangely (and wrongly) with symbols that
include $ signs in them, no matter how they're escaped.  Since the majority
of important VMS logicals (e.g. sys${output,input,error}, etc.) have these,
setenv is no help for this purpose.

(Try issuing the commands:
setenv 'sys$output' foo
setenv 'sys$output' bop
twice in a row.  printenv will reveal both entries for sys$output, and
neither will be removed if you then try:
unsetenv 'sys$output'
I don't think that any escaping will solve the problem (I talked with
somebody at TWG about this, and he confirmed the problem.))

Anyone have suggestions?

Ken Manheimer		      UUCP: {seismo,allegra}!umcp-cs!nbs-amrf!manheimer
National Bureau of Standards  ARPA: manheimer.nbs-amrf at maryland (maybe)
Metrology A127		      Influence: and existence are the same
Washington, DC 20234	      BELL: (301)921-2381



More information about the Comp.os.eunice mailing list