barmar@think.COM (Barry Margolin) (02/01/89)
In GNU Emacs 18.52:
When running GNU Emacs in an X window (using its "-d" option), is
there any way to get shell mode to automatically set the subprocess's
DISPLAY environment variable appropriately, as xterm does? I'm
putting some customization into my .cshrc that wants to do certain
things if it's being run in an X11 window (specifically, it's checking
to see whether DISPLAY contains a ".", so it can tell whether it's in
an X10 or X11 window, since we haven't yet fully converted).
I did an apropos of "^x-" and "display" in Emacs, looking for a
variable or function that would return the current display, but didn't
see anything. Can anyone help me?
Barry Margolin
Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmarfkittred@bbn.com (Fletcher Kittredge) (02/01/89)
Check in your config.h file for a line which looks like: #define MAINTAIN_ENVIRONMENT If you don't have such a line, add it and remake emacs. This will allow you to use the elisp function setenv. Example (setenv "DISPLAY" "unix:0") It will also allow you to use the getenv function. regards, fletcher Fletcher E. Kittredge fkittred@bbn.com
jr@bbn.com (John Robinson) (02/01/89)
In article <35945@think.UUCP>, barmar@think (Barry Margolin) writes: >In GNU Emacs 18.52: > >When running GNU Emacs in an X window (using its "-d" option), is >there any way to get shell mode to automatically set the subprocess's >DISPLAY environment variable appropriately, as xterm does? If you set the DISPLAY variable coming into emacs, it will be inherited by the shell. So instead of starting emacs this way: emacs -d unix:0 say (to csh): setenv DISPLAY unix:0 ; emacs Otherwise, you can put a default into .emacs_csh (see help for function shell). >I did an apropos of "^x-" and "display" in Emacs, looking for a >variable or function that would return the current display, but didn't >see anything. Can anyone help me? You can get any environment varilable in emacs' environment with (getenv "VARNAME"). Now, the variable command-line-args ought to have your "-d" and display-name in it, but the X code strips away its args from this list when it starts up. This seems to be a bug. I suspect it is due to the X code really being a graft onto emacs at this point. Really, the switches should be handled in the same loop that handles the rest of the switches to emacs, but it has to run sooner in order to set up the new X window, etc. Maybe v19 will get this better... -- /jr jr@bbn.com or bbn!jr
meissner@tiktok.dg.com (Michael Meissner) (02/02/89)
In article <35945@think.UUCP> barmar@think.UUCP (Barry Margolin) writes: | In GNU Emacs 18.52: | | When running GNU Emacs in an X window (using its "-d" option), is | there any way to get shell mode to automatically set the subprocess's | DISPLAY environment variable appropriately, as xterm does? I'm | putting some customization into my .cshrc that wants to do certain | things if it's being run in an X11 window (specifically, it's checking | to see whether DISPLAY contains a ".", so it can tell whether it's in | an X10 or X11 window, since we haven't yet fully converted). Go into the source directory for emacs, and add a define to config.h for MAINTAIN_ENVIRONMENT, do a make clean, followed by a make. If this is defined, emacs passes the entire environment to subprocesses. You can also do (setenv "variable" "value") then from within emacs. Note, the documentation for setenv is messed up.... -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa: meissner@dg-rtp.DG.COM (or) meissner%dg-rtp.DG.COM@relay.cs.net
jr@bbn.com (John Robinson) (02/02/89)
In article <3195@xyzzy.UUCP>, meissner@tiktok (Michael Meissner) writes: >Go into the source directory for emacs, and add a define to config.h >for MAINTAIN_ENVIRONMENT, do a make clean, followed by a make. If >this is defined, emacs passes the entire environment to subprocesses. >You can also do (setenv "variable" "value") then from within emacs. >Note, the documentation for setenv is messed up.... I don't believe this is quite right. Emacs always passes its environment to its children. MAINTAIN_ENVIRONMENT adds (setenv) so that you can manipulate it. (getenv) is there regardless. I (and others) have never understood why setenv is not always built-in. -- /jr jr@bbn.com or bbn!jr