From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Compile Mode and "host" Emacs Date: Tue, 29 Oct 2013 10:22:22 -0700 Message-ID: <91DCEFA2-F588-48BA-921A-A05B38212B9A@mit.edu> References: <874n80l0b3.fsf@nbtrap.com> <874n80w7cl.fsf@nbtrap.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1383067384 22585 80.91.229.3 (29 Oct 2013 17:23:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Oct 2013 17:23:04 +0000 (UTC) Cc: "emacs-devel@gnu.org devel" To: Sebastian Wiesner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 29 18:23:07 2013 Return-path: Envelope-to: ged-emacs-devel@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 1VbD0S-0002jo-H7 for ged-emacs-devel@m.gmane.org; Tue, 29 Oct 2013 18:23:04 +0100 Original-Received: from localhost ([::1]:48539 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbD0S-0000Vh-3t for ged-emacs-devel@m.gmane.org; Tue, 29 Oct 2013 13:23:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38163) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbD00-0008U2-Un for emacs-devel@gnu.org; Tue, 29 Oct 2013 13:22:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VbCzs-0002gS-6D for emacs-devel@gnu.org; Tue, 29 Oct 2013 13:22:36 -0400 Original-Received: from dmz-mailsec-scanner-2.mit.edu ([18.9.25.13]:49294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VbCzs-0002gN-1d for emacs-devel@gnu.org; Tue, 29 Oct 2013 13:22:28 -0400 X-AuditID: 1209190d-b7f528e0000009b4-b8-526feed31353 Original-Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id AF.15.02484.3DEEF625; Tue, 29 Oct 2013 13:22:27 -0400 (EDT) Original-Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r9THMQ9U013619; Tue, 29 Oct 2013 13:22:27 -0400 Original-Received: from [10.0.1.10] (c-98-247-148-125.hsd1.wa.comcast.net [98.247.148.125]) (authenticated bits=0) (User authenticated as yandros@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r9THMNPB023739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Oct 2013 13:22:25 -0400 In-Reply-To: X-Mailer: Apple Mail (2.1816) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixG6nrnv5XX6QQfNTbYvHC56wWqzs+sPs wOSxc9Zddo+2aWYBTFFcNimpOZllqUX6dglcGXNWlxc8lat4/buTqYFxlkQXIyeHhICJxMQJ /xghbDGJC/fWs3UxcnEICexjlLh4q4EVwtnIKNF66DQjhHOcSeLKqT1MIC3MAnoSO67/YgWx eYHscxM+gsWFBbQkjl+/x9zFyMHBJiADNFYDJMwpECix4lQXWAmLgKrEwX+L2EFKmAVMJRb3 qEBM1JZYtvA1WCevgJXEh5WKIGEhgUlMEo0nPEDCIkAl15riIU6WlZj49wTjBEbBWUjOmYXk nFlIhi5gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6SXm1mil5pSuokRFLackrw7GN8dVDrE KMDBqMTDa/AgP0iINbGsuDL3EKMkB5OSKO+/t0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzT jwPleFMSK6tSi/JhUtIcLErivDc57IOEBNITS1KzU1MLUotgsjIcHEoSvP7A+BQSLEpNT61I y8wpQUgzcXCCDOcBGs4IUsNbXJCYW5yZDpE/xagoJc7rDpIQAElklObB9cLSyitGcaBXhHn9 QKp4gCkJrvsV0GAmoMF7WPJABpckIqSkGhjX/V+sICajIctywMs1QFxb4VotTyOf1ruK9jLP qa+Dfvqnbu57wrx2N6OVTP17LoZn/9tY1647K+qrflZlQ7jjXrkLSR+sj8gxCXYyv1h/jzfh 99nVS61bpy2LCmucrzxjyp+kre/qljKbTOA03NfnO63t5d9qr8dJ714z+TwV+lSo X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 18.9.25.13 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164647 Archived-At: On 29 Oct 2013, at 06:18, Sebastian Wiesner wrote: >>=20 >> I don't think there's any portable way. >=20 > That's unfortunate. It was (is?) an early design principle of unix systems that there isn't = necessarily any such thing as `the path' or even `a path' to anything. = This has a number of positive benefits surrounding hard links, soft = links, movable files, and [un/re]mountable filesystems. Instead, we got = conventions (not rules) about where things should be, and how to find = them. It also has a cost, but it's relatively low - most of the time, = when someone said "I want my program to know its place in the = filesystem.", they really didn't need to know that, and there were = better ways to accomplish their goals. For example, often these requests = are an effort to work around the user's configuration choices, and that = desire gets things wrong at least as often as it gets things right - = even if it seems better in the short-term, narrow-focus view. That said, there are times when the program really does want to know = that data, so emacs provides a way to find it (invocation-*, mentioned = above). Under macosx, for example, if you build a relocatable bundle, it = really wants to be able to find its lisp libraries. > I cannot but wonder what (stupid?) rationale let to the design of > "$EMACS" and "$INSIDE_EMACS", if I have no chance to find out *what* > Emacs I am actually inside of=85 In most cases, programs don't care at all. When they do care, in most = cases they care if they're running inside any sort of emacs at all or = not. Your case appears to care inside which specific filesystem = invocation of emacs it was run, which is unusual. Most cases, when = examined, really are better off using rather than bypassing the user's = configuration (PATH in this case). If I were using some code that wanted = to know where emacs was installed, and I changed PATH for that code, I = wouldn't want it poking around and guessing that it should ignore PATH. = Conversely, if the user hasn't set PATH, but wants to interact with = emacs, they generally will get similar sorts of wrong behavior if = they're shell uses the wrong programs from bin and libexec (ctags, = etags, emacsclient, etc). In most cases, then, the right thing to do is to get/help the user = configure emacs on their system correctly, rather than second-guess = their intentions - it's harder to do, but gives the right result in more = cases. >> A better way would probably be to set some environment variable to = the >> full path in your init file, and then using that from the compile >> process: >>=20 >> ;;;; .emacs >>=20 >> (setenv "EMACS_EXE_PATH" >> (file-truename (concat (file-name-as-directory >> invocation-directory) >> invocation-name))) >=20 > I am not in control of my users' configurations, nor can I reasonably > demand them to change their "init.el" just to support a single script. > Besides, if I tell them to change their "init.el", I might just as > well tell them to select the target Emacs via the corresponding option > of my script right away. That's a good idea; you can also have your script run emacs (probably = -batch) and have that emacs stash the info you need somewhere. I'll = point out that if you expect your users to interact with emacs both from = a gui launcher and from the command-line, it's almost never a bad idea = to suggest and/or help them to configure their environment so that emacs = works well in both situations. Hopefully that helps explain why what seemed like a simple question = wasn't quite as simple as you'd thought. If you can explain a bit more = what it is you're actually trying to do, we can probably provide some = helpful suggestions about how to accomplish your goals. Thanks, ~Chad