From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Peter Dyballa Newsgroups: gmane.emacs.help Subject: Re: setenv and find-file Date: Sat, 18 May 2013 12:07:02 +0200 Message-ID: References: <155DEC68569B714B86C2C7075F5EDA9828F794FC@DAKIYA1.pegasus.local> <8089B172-1D9F-4ACA-83B0-92FABA47BD5B@Web.DE> <155DEC68569B714B86C2C7075F5EDA9828F7A60D@DAKIYA1.pegasus.local> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1368871649 18487 80.91.229.3 (18 May 2013 10:07:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 May 2013 10:07:29 +0000 (UTC) Cc: "help-gnu-emacs@gnu.org" To: Doug Lewan Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat May 18 12:07:27 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ude2v-0007gY-JD for geh-help-gnu-emacs@m.gmane.org; Sat, 18 May 2013 12:07:25 +0200 Original-Received: from localhost ([::1]:54359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ude2u-000652-6t for geh-help-gnu-emacs@m.gmane.org; Sat, 18 May 2013 06:07:24 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ude2g-000641-4U for help-gnu-emacs@gnu.org; Sat, 18 May 2013 06:07:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ude2a-0006Nn-3w for help-gnu-emacs@gnu.org; Sat, 18 May 2013 06:07:10 -0400 Original-Received: from mout.web.de ([212.227.15.4]:59517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ude2Z-0006Na-RB for help-gnu-emacs@gnu.org; Sat, 18 May 2013 06:07:04 -0400 Original-Received: from sumac.fritz.box ([95.223.131.144]) by smtp.web.de (mrweb001) with ESMTPA (Nemesis) id 0Lp7HY-1Tz4Us2yiC-00fTcR; Sat, 18 May 2013 12:07:02 +0200 In-Reply-To: <155DEC68569B714B86C2C7075F5EDA9828F7A60D@DAKIYA1.pegasus.local> X-Mailer: Apple Mail (2.1085) X-Provags-ID: V02:K0:8q0Am/qysGHTkdrD9gr8fDwCWsU5P6OEI9UrJGAkB6d FQCkU/HiU7Dh/ccN82f8tor1J0r8Jr5l14cU/xsx0EmBM2EtCC xSlLaT+5kkQqGRdDnfIUSCOBgqeYxy9cNjPnKEDvZJRZaJ9HSy McmbOD4MBv0U+YJGD8yOE+bItVgeWYTKPEVbBwx72qXsZZUe/1 coFbEkmo35lTAyk4R6XDQ== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.15.4 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:90890 Archived-At: Am 17.05.2013 um 23:07 schrieb Doug Lewan: > I see a problem when M-x find-file is expanding ${VARIABLE} but not = taking it from the newly defined environment variable. Everything else = picks it up (I presume just via fork/exec). >=20 > I hope this script is clearer. >=20 > In shell: > $ echo ${VARIABLE} > /a/very/long/path > $ emacs & > Inside emacs: > C-x C-f ${VARIABLE}/to/work <=3D=3D Finds = "/a/very/long/path/to/work". > (setenv "VARIABLE" "/shorter/path") > =3D> "/shorter/path" > M-! echo ${VARIABLE} > "/shorter/path" > M-x shell > In shell inside emacs: > $ echo ${VARIABLE} > "/shorter/path" > Back in emacs: > C-x C-f ${VARIABLE}/to/Grandmothers/house > This finds the file "/a/very/long/path/to/Grandmothers/house", where I = sort of expect it to find "/shorter/path/to/Grandmothers/house". No, this cannot work in GNU Emacs with a regular *shell* buffer =96 = maybe it works in VIM? GNU Emacs is a host (or a PC) that allows other programmes to run inside = it. Every variable the external (whatsoever: Korn, Bourne, C, =85) shell = interpreter is setting, is a private variable of and only inside this = shell interpreter. And since it's just a shell interpreter it has no = access to the variables of GNU Emacs. No shell function exists for this = purpose. The situation is a bit different when some shell variables are defined = in a shell from which GNU Emacs is launched. These environment variables = also exist in the GNU Emacs process, they are inherited by it, so they = can be accessed: (getenv "PATH") With this Elisp statement GNU Emacs has read an environment variable = which the shell inside its *shell* buffer also has (the shell's $PATH = can be different, because shell interpreter init files can set their own = values), but GNU Emacs cannot use the shell interpreter's private value = because there is no specialised function (yet) that creates = automatically a GNU Emacs variable when you try to access either a = (private) shell or an environment variable. In your init file you would = need to create "normal" GNU Emacs variables and set their values with = what you get from reading environment variables (not: private own shell = variables). Another different situation is when you use eshell instead of an = external shell interpreter. This in Emacs Lisp written interpreter has = access to all of GNU Emacs variables and functions and vice versa =96 = presumingly! I'm not using it on a regular basis=85 Since GNU Emacs and inferior processes are cleanly separated processes, = there is no way that both can easily share variables and their values. = They would need "neutral" external locations like regular files, pipes, = sockets, FIFOs, LIFOs, shared memory areas, servers or services for data = exchange (and extra programme code to make use of these external = things). Since eshell and GNU Emacs are not separated they probably can = share what you are thinking of. But used eshell users should comment on = my opinion! -- Greetings Pete =3D=3D=3D -Q =3D=3D<__/% >> _____________(_)____@_____________________________