From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: shell-command causes problems with absolute/relative paths in TAGS Date: Fri, 06 Jan 2012 17:42:55 +0200 Message-ID: <83ipkoon0g.fsf@gnu.org> References: <20120102223315.3E60F1810C9@neo.msri.org> <408087A3D7BE475B884C0F93CE2298C7@us.oracle.com> <20120105054142.GA10149@hysteria.proulx.com> <9C2570562E2A4B7BBDA61F564FCFC83F@EUROPE.ROOT.PRI> <20120105222030.GA22189@hysteria.proulx.com> <1CA9A2C2C5544CAAA163A0962C5C95F4@EUROPE.ROOT.PRI> <83pqexnjrk.fsf@gnu.org> <9287FF55897A4EED8EA883DC00F98BAC@EUROPE.ROOT.PRI> NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1325864736 9546 80.91.229.12 (6 Jan 2012 15:45:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2012 15:45:36 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jan 06 16:45:31 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RjBz1-0006gV-OU for geh-help-gnu-emacs@m.gmane.org; Fri, 06 Jan 2012 16:45:31 +0100 Original-Received: from localhost ([::1]:40585 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjByw-0001CA-3e for geh-help-gnu-emacs@m.gmane.org; Fri, 06 Jan 2012 10:45:26 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:41396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjByr-0001C5-53 for help-gnu-emacs@gnu.org; Fri, 06 Jan 2012 10:45:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjByp-0005HI-VN for help-gnu-emacs@gnu.org; Fri, 06 Jan 2012 10:45:21 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:46714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjByp-0005HD-Ni for help-gnu-emacs@gnu.org; Fri, 06 Jan 2012 10:45:19 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LXD00000VDVPJ00@a-mtaout20.012.net.il> for help-gnu-emacs@gnu.org; Fri, 06 Jan 2012 17:44:58 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.115.90]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LXD00MDTVQX2ZR0@a-mtaout20.012.net.il> for help-gnu-emacs@gnu.org; Fri, 06 Jan 2012 17:44:58 +0200 (IST) In-reply-to: <9287FF55897A4EED8EA883DC00F98BAC@EUROPE.ROOT.PRI> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 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:83374 Archived-At: > From: "David Chappaz" > Date: Fri, 6 Jan 2012 13:04:57 -0000 > > Eli Zaretskii wrote > > > If, before doing M-x shell, I evaluate > > > (setq explicit-cmdproxy.exe-args '("/q")) > > > to prevent shell commands from being echoed, then suddenly the TAGS file > > > is generated properly, with relative filenames. > > > > I see no such variable in Emacs. > > The variable name depends on which shell you use. By default, only > explicit-bash-args and explicit-sh-args are defined in emacs. > On windows, cmdproxy.exe is the default shell, hence the variable name. Well, I tried that on Windows with cmdproxy as the shell, and I still don't see this variable. > 2/ Now from e.g. a scratch buffer, I evaluate > > (progn > (cd "C:/test/") > (call-process-region (point) (point) "C:/Program > Files/Emacs/emacs-23.3/bin/cmdproxy.exe" nil (current-buffer) nil "-c" > "ctags -e -L filelist.txt")) > > which is more or less what M-x shell-command would do... then the result is > incorrect. Yes, I see the problem. > 3/ Worse, if you kill the original shell buffer created in 1/, and repeat > the same operation as in 1/... then the result is incorrect. > > So it really looks like something is happening in call-process-region... It must be a bug in ctags, no matter what call-process-region does. I suspect that it doesn't correctly handle the backslash in file names, and fails to realize that C:\foo\bar\baz.c and C:/foo/bar share the same directory. That's because the "absolute" file names it produces are of the form "C:\foo\bar\./file", note the mixture of forward- and back-slashes.