manheimer@nbs-amrf.UUCP (06/05/84)
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@maryland (maybe) Metrology A127 Influence: and existence are the same Washington, DC 20234 BELL: (301)921-2381
manheimer@nbs-amrf.UUCP (06/12/84)
It just got an indication that the capacity to `suspend' a login shell is a new feature of Eunice 3.2, i.e. that it cannot be done in 3.1 . We've only had 3.2 a short while, and i just happened to stumble accross the suspend command (in a conversation with someone from TWG). I hadn't considered when i posted the article whether this was a new feature or just one of those previously undocumented ones. (As a matter of fact, the only "documentation" of the ability to suspend a login shell is still only to be found in the csh source code.) Happy hacking, Ken Manheimer {seismo,allegra}!umcp-cs!nbs-amrf!manheimer "I mean, you tell one guy it's blue. He tells his guy it's brown, and it lands on the page sorta purple." Wavy Gravy