From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "David Chappaz" Newsgroups: gmane.emacs.help Subject: RE: shell-command causes problems with absolute/relative paths in TAGS Date: Fri, 6 Jan 2012 11:12:12 -0000 Message-ID: <1CA9A2C2C5544CAAA163A0962C5C95F4@EUROPE.ROOT.PRI> References: <20120102223315.3E60F1810C9@neo.msri.org> <408087A3D7BE475B884C0F93CE2298C7@us.oracle.com> <20120105054142.GA10149@hysteria.proulx.com> <9C2570562E2A4B7BBDA61F564FCFC83F@EUROPE.ROOT.PRI> <20120105222030.GA22189@hysteria.proulx.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1325848356 18307 80.91.229.12 (6 Jan 2012 11:12:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2012 11:12:36 +0000 (UTC) To: Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jan 06 12:12:32 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 1Rj7in-0007wy-9b for geh-help-gnu-emacs@m.gmane.org; Fri, 06 Jan 2012 12:12:29 +0100 Original-Received: from localhost ([::1]:34856 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rj7im-0000di-Pu for geh-help-gnu-emacs@m.gmane.org; Fri, 06 Jan 2012 06:12:28 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:36545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rj7ii-0000dd-9Y for help-gnu-emacs@gnu.org; Fri, 06 Jan 2012 06:12:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rj7ih-0000nq-Fg for help-gnu-emacs@gnu.org; Fri, 06 Jan 2012 06:12:24 -0500 Original-Received: from cluster-d.mailcontrol.com ([85.115.60.190]:56722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rj7ih-0000nh-1l for help-gnu-emacs@gnu.org; Fri, 06 Jan 2012 06:12:23 -0500 Original-Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly20d.srv.mailcontrol.com (MailControl) with ESMTP id q06BCJwg032232 for ; Fri, 6 Jan 2012 11:12:19 GMT Original-Received: from DC04PC01 ([10.103.11.129]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 11:12:19 +0000 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20120105222030.GA22189@hysteria.proulx.com> Thread-Index: AczL+DzX0483TbgwTX2q7oGQ1mIvwwAa73SQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 06 Jan 2012 11:12:19.0175 (UTC) FILETIME=[0E11DF70:01CCCC64] X-Scanned-By: MailControl 7.6.5 (www.mailcontrol.com) on 10.68.0.130 X-detected-operating-system: by eggs.gnu.org: Windows 98 (1) X-Received-From: 85.115.60.190 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:83367 Archived-At: > > So when doing "more filetest.txt" from shell-command, "more" is > > clearly getting multiple files. > > Can you make out the filenames that it is getting from the output? I tried, and tried... but didn't succeed. From a plain shell, "more" does not insert any header, unless there are multiple files Now, when I do "more test1.c" from shell-command, a header is inserted (as if there were multiple files), but no second or third header appears (as if there was only one...), would it be with a blank file name. But I'm only seeing this behaviour on linux, and although it might be related to my problem (on windows), it doesn't really affect me. Perhaps this is something you can reproduce and investigate. Now, on Windows, > > I've just discovered that "ctags -e -L filelist.txt" does not [work] > > when used in an emacs's shell buffer (i.e. that produces the same > > result, with absolute paths, as with shell-command) After more detailed investigations, I've found out the following. 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. In other words, the same command has two different behaviours when issued in an emacs shell buffer, depending on if explicit-cmdproxy.exe-args is set to "" or "/q". That does not make any sense, or does it ? Something looks really odd. Also, shell-command is not affected by the value of explicit-cmdproxy.exe-args, and always behaves the same. > Which is why I have > sympathy for people going the other direction and try to help out when > I can. I appreciate your support, and even if you're not a MS-Windows expert, your ideas are very welcome ! To be honest, most of the time I use emacs on linux, so the lisp package I'm developing works fine. But occasionally I use it on Windows, which is why I'm trying to get it to work on this platform too... > Since it looks like an operating system interface bug in shell-command > I think I would try to work around it by using a helper script. Yeah, in the short term, that's a very good plan indeed to work around the problem!