From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: simple useful functions Date: Mon, 06 Dec 2010 22:24:30 -0500 Message-ID: References: <20101206.103945.379575954.Takaaki.Ota@am.sony.com> <20101206.132502.318846750.Takaaki.Ota@am.sony.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1291692282 5331 80.91.229.12 (7 Dec 2010 03:24:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Dec 2010 03:24:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tak Ota Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 07 04:24:38 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PPoAQ-0002To-8A for ged-emacs-devel@m.gmane.org; Tue, 07 Dec 2010 04:24:38 +0100 Original-Received: from localhost ([127.0.0.1]:32829 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPoAP-0001QX-Ik for ged-emacs-devel@m.gmane.org; Mon, 06 Dec 2010 22:24:37 -0500 Original-Received: from [140.186.70.92] (port=47838 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPoAK-0001PT-GT for emacs-devel@gnu.org; Mon, 06 Dec 2010 22:24:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPoAJ-0008Pi-CO for emacs-devel@gnu.org; Mon, 06 Dec 2010 22:24:32 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:10270 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PPoAJ-0008Pe-7E for emacs-devel@gnu.org; Mon, 06 Dec 2010 22:24:31 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQHACY3/UxFxLmf/2dsb2JhbACiMYEGcr9+hUkEhF+NfQ X-IronPort-AV: E=Sophos;i="4.59,308,1288584000"; d="scan'208";a="84721062" Original-Received: from 69-196-185-159.dsl.teksavvy.com (HELO ceviche.home) ([69.196.185.159]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 06 Dec 2010 22:24:30 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 56D13661BF; Mon, 6 Dec 2010 22:24:30 -0500 (EST) In-Reply-To: <20101206.132502.318846750.Takaaki.Ota@am.sony.com> (Tak Ota's message of "Mon, 6 Dec 2010 13:25:02 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133483 Archived-At: >> >> IIUC these scripts are written for /bin/sh, right? How do (t)csh users >> >> handle that? >> >> [ Sorry, I'm not that familiar with cross-compiling: OpenWRT is about >> >> as far as I got into this, and it "takes care of things" in ways >> >> I haven't tried to understand. They don't use such setup scripts, at >> >> least in a user-visible way (although the user does perform the >> >> cross-compiling). ] >> >> > Those scripts are written for the shell the tool provider intends user >> > to use. The shell to use is not always our choice. >> >> In the case of the scripts you've used, was there some way to >> mechanically figure out which shell was intended? I'm thinking that >> using shell-file-name is probably not the right choice, and we should >> instead default to /bin/sh (which I'd expect to be the most common >> case). >> >> > This is a good point. I am contaminating the whole emacs. It made me >> > review compile.el and I learned the existence of >> > compilation-environment which I think is more appropriate than >> > `setenv' function. >> So only `compile' needs to know about these env-vars? > No, the debugger also needs. I don't find similar consideration in > gdb-ui.el. Do you have a better suggestion? Well, we could imagine a new var (like compilation-environment) and make all relevant commands obey it (maybe it could be implemented directly within call/start-process and the new var set via dir-locals.el). Stefan