control@almsa-1.ARPA (William Martin) (05/21/85)
A query regarding running under 4.2 BSD, and using the standard "sh" shell: Is there any way I can change my terminal type (setting the TERM variable) while I am inside some other process? If I can do a "!sh" or push to a lower fork or child process, and then run the shell and do a TERM=xyz and export TERM, that only has an effect for that child process. Is there a way to do it so that it changes the variable in the parent process, where I am working? For example, I get on a terminal not my usual one, forget to do a TERM type setting, and then run "send", our message-sending routine which is part of the mmdf mail system we use here. I compose the message and then want to use "vi" to edit it. When I run "vi", the screen display is all messed up because the TERM type is wrong. I can :q out of vi, and use ed instead, which is what I do, but I wonder if there is something I can do at that point to reset my terminal type without saving the text data, aborting "send", and then resetting and starting over? That is, terminate the mangled "vi", do <something> that resets the terminal type to the correct one, and then restart "vi" on the message text? (I would hope that there is some generic method to do this -- I'm not looking for specific help regarding this particular local mail tool.) On a TOPS-20 machine, I can be running a process, give a "push" command which spawns a lower-level running fork of the exec, and at that lower level give terminal and environment-modification commands that are effective AFTER I subsequently issue a "pop" command which takes me back up to where I was when I did that "push". Is there an equivalent in UNIX? Maybe something that has some sort of "global" effect, or something like the way you can do ". shellscript" to get the shellsript commands to affect your own personal running shell? (This would reach UP an arbitrary number of levels.) Will Martin ARPA/MILNET: wmartin@almsa-1.ARPA UUCP/Usenet: seismo!brl-bmd!wmartin
ron@brl (Ron Natalie) (05/22/85)
No, it's not possible to change environment variables from "lower forks" because each process gets it's own copy of the environment. Changing the environment of one process does not affect any others. Same story for things like the current directory. Forks get an identical environment because fork just copies process. The exec call to the kernel tells it exactly what you want to environment of the execed process to be. The three things I do are: TERM=`process` Set TERM using what is the output process and the temporary environment setting such as TERM=vt52 vi If send used the shell to execute the editor, this would work, but alas it uses pexec or something else instead. I've refered the problem to the send maintainers here. -Ron
mash@mips.UUCP (John Mashey) (05/23/85)
William Martin writes: > Is there any way I can change my terminal type (setting the TERM variable) > while I am inside some other process? .... No, and it was on purpose. The environment was specifically designed 1) to be mostly the business of user pgms and not the OS 2) to have the same sort of inheritance semantics as everything else inherited by a child. On any UNIX, programs that want to access global state may easily do so by agreeing on a file name that contains that state, and agreeing on a signal to alert another process to look at the file. Environment variables are nothing but implicitly-passed arguments with usage agreed by programs. At one point in the design of the environment, it was contemplated that the environment be a set of global read-write variables, that lived in a new magic entity inside the kernel. This was a Wrong Thing, for 2 fundamental reasons: 1) This new magic entity could not reasonably be associated with any existing entity in the system. For example, should be owned by a uid? No, because you might be logged in twice. Did it belong to a process? No, because it would be acccessed by more than 1, or would be useless. DId it belong to a process group? This didn't make sense either. If some processes have one of these things, what happens when you fire something up in the background? Does it get its own, or not? 2) Environment variables would suddenly have indeterminate values, because their modfication sequence was now dependent on process scheduling. For example, if x were truly global, what result ought to be printed below? x=10; (x=20)& echo $x Nevertheless, the original request does illustrate a semantic discontinuity that has arisen over time. $TERM was invented originally because it was becoming obvious that even the simplest functions (like setting tabs) were terminal-dependent, and that as terminals kept getting smarter they would only get more different. At the time, people did not want to chew up the space inside the kernel to keep a terminal typename inside each tty structure, and it seemed that we could cover most normal uses of TERM with environment vars. Given all the ways that $TERM is now used, it's no longer clear exactly what it's associativity is. Maybe it (+ other useful attributes, like current window size) should belong to each virtual terminal, which would solve the original problem presented. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
naiman@pegasus.UUCP (Ephrayim J. Naiman) (05/24/85)
> For example, I get on a terminal not my usual one, forget to do a > TERM type setting, and then run "send", our message-sending routine > which is part of the mmdf mail system we use here. I compose the > message and then want to use "vi" to edit it. When I run "vi", the > screen display is all messed up because the TERM type is wrong. > I can :q out of vi, and use ed instead, which is what I do, but I > wonder if there is something I can do at that point to reset my > terminal type without saving the text data, aborting "send", and > then resetting and starting over? That is, terminate the mangled "vi", > do <something> that resets the terminal type to the correct one, and > then restart "vi" on the message text? (I would hope that there is some > generic method to do this -- I'm not looking for specific help regarding > this particular local mail tool.) As you've probably gathered by now you can't reset your TERM variable in the current process. However, in vi there IS a way to change your terminal type. The way to do it is to go into ex, change it and go back into vi. The commands are : Q (put's you in ex) set term=term_name vi (put's you in vi) -- ==> Ephrayim J. Naiman @ AT&T Information Systems Laboratories (201) 576-6259 Paths: [ihnp4, allegra, mtuxo, maxvax, cbosgd, lzmi, ...]!pegasus!naiman
peterc@ecr2.UUCP (Peter Curran) (05/27/85)
Here is a scheme for getting environment changes back to your "main" shell (this works for /bin/sh. I presume masochists could find something similar in csh): Add the following three lines to your .profile file: trap '. $SHCMDS; rm -f $SHCMDS' 8 SHCMDS=$HOME/shcmds SHPID=$$ export SHCMDS SHPID Then, in suprocess, write shell commands into the file named in $SHCMDS, and send signal 8 to the process identified by $SHPID. For example, in a shell script echo "TERM=$TERM; export TERM" >$SHCMDS signal -8 $SHPID It is probably preferably that the '>' be '>>' to allow several commands to be written out at once. This will fail if you push it too hard - the shell has to get time to execute the commands before another command is issued. However, it can be used for all sorts of tricks.
psc@lzwi.UUCP (Paul S. R. Chisholm) (05/29/85)
< Smokey the Bar says, "Help stamp out software pirates" [squish!] > > As you've probably gathered by now you can't reset your TERM variable > in the current process. > > However, in vi there IS a way to change your terminal type. > The way to do it is to go into ex, change it and go back into vi. > The commands are : > > Q (put's you in ex) > set term=term_name > vi (put's you in vi) Alas! In version 3.9 of vi (the first well distributed version to use terminfo), that confuses the list of mappings *very* badly. Don't do it. -- -Paul S. R. Chisholm The above opinions are my own, {pegasus,vax135}!lzwi!psc not necessarily those of any {mtgzz,ihnp4}!lznv!psc telecommunications company.