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: Wed, 4 Jan 2012 16:27:00 -0000 Message-ID: References: <20120102223315.3E60F1810C9@neo.msri.org> <408087A3D7BE475B884C0F93CE2298C7@us.oracle.com> <1328337488-1325693643-cardhu_decombobulator_blackberry.rim.net-1323737730-@b13.c12.bise7.blackberry> 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 1325694514 16564 80.91.229.12 (4 Jan 2012 16:28:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2012 16:28:34 +0000 (UTC) To: , Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jan 04 17:28:30 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 1RiThV-0005sp-VS for geh-help-gnu-emacs@m.gmane.org; Wed, 04 Jan 2012 17:28:30 +0100 Original-Received: from localhost ([::1]:44417 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiThQ-0002T2-8y for geh-help-gnu-emacs@m.gmane.org; Wed, 04 Jan 2012 11:28:24 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:36801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiThI-0002Sp-Ac for help-gnu-emacs@gnu.org; Wed, 04 Jan 2012 11:28:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiThH-0006lG-2S for help-gnu-emacs@gnu.org; Wed, 04 Jan 2012 11:28:16 -0500 Original-Received: from cluster-g.mailcontrol.com ([208.87.233.190]:45310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiThG-0006l8-JL for help-gnu-emacs@gnu.org; Wed, 04 Jan 2012 11:28:15 -0500 Original-Received: from rly11g.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly11g.srv.mailcontrol.com (MailControl) with ESMTP id q04GS9T0010531 for ; Wed, 4 Jan 2012 16:28:10 GMT Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rly11g.srv.mailcontrol.com (MailControl) id q04GRCK2003681 for ; Wed, 4 Jan 2012 16:27:12 GMT Original-Received: from CAMEUREXB02.EUROPE.ROOT.PRI ([193.128.72.68]) by rly11g-eth0.srv.mailcontrol.com (envelope-sender ) (MIMEDefang) with ESMTP id q04GRA5K003431; Wed, 04 Jan 2012 16:27:12 +0000 (GMT) Original-Received: from DC04PC01 ([10.103.11.129]) by CAMEUREXB02.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 16:27:10 +0000 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <1328337488-1325693643-cardhu_decombobulator_blackberry.rim.net-1323737730-@b13.c12.bise7.blackberry> Thread-Index: AczK++HALkczHbjkQD6/gWwCt0BZjgAAJ+rw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 04 Jan 2012 16:27:10.0096 (UTC) FILETIME=[B51C2900:01CCCAFD] X-Scanned-By: MailControl 7.6.5 (www.mailcontrol.com) on 10.71.1.121 X-detected-operating-system: by eggs.gnu.org: Windows 98 (1) X-Received-From: 208.87.233.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:83318 Archived-At: Vladimir, thanks for the very prompt reply ! Unfortunately, "cat" does not change the behaviour... I understand that "more" was perhaps not the best choice, but, I can't help thinking that shell-command somehow does something more than just sending a command to the shell.... -----Original Message----- From: Vladimir Murzin [mailto:murzin.v@gmail.com] Sent: 04 January 2012 16:15 To: David Chappaz; help-gnu-emacs-bounces+murzin.v=gmail.com@gnu.org; help-gnu-emacs@gnu.org Subject: Re: shell-command causes problems with absolute/relative paths in TAGS Hi David AFAIK "less"/"more" are pagers and suitable for reading files by human. Have you tried using "cat"? Best wishes, Vladimir Murzin -----Original Message----- From: "David Chappaz" Sender: help-gnu-emacs-bounces+murzin.v=gmail.com@gnu.orgDate: Wed, 4 Jan 2012 16:05:13 To: Subject: shell-command causes problems with absolute/relative paths in TAGS Hi everyone, I'm having trouble when generating a TAGS file on windows. I should say that everything works fine on Linux (almost, see bottom of the message), so it really seems to be a windows specific problem. Note that I'm using GNU Emacs 23.3.1, with Exuberant CTags 5.8 So here is the thing. Say I have a "test" folder, with 2 source files, e.g. test1.c and test2.c I also have a "filelist.txt", e.g. generated with "GnuWin32 find", which contains : ./test1.v ./test2.v Now, I generate my TAGS file from a plain windows shell, with the following command: more filelist.txt | ctags -e -L - This works fine, and, as expected, the paths to the source files in the TAGS file are relative, so the entire "test" folder and the TAGS file can be moved to a different location. I'm developing a small emacs package to provide some sort of IDE. So now I'm trying to do the same from within emacs. If I do: M-x shell-command more filelist.txt | ctags -e -L - ...then the result is different, and now paths in the TAGS file become absolute. Even using the explicit option --tag-relative=yes does not change anything. I am not sure whether Exuberant CTags or Emacs shell-command is to blame. I believe it's got something to do with "shell-command", but it's just a guess really. Can anyone reproduce the problem and/or explain what's happening ? PS, on a slightly different note: 1/ on linux, shell-command also does something funny. Try "more filelist.txt" and check the output buffer. It contains some sort of "header" with "::::::::::::::" so the same command obviously fails. Use "less" instead of "more" and then everything works 2/ I have also found that "GnuWin32 find" is painfully slow on network (unix) drives, and that using the built-in dos command "dir /b /s" is much faster (but less powerful of course). Has anyone experienced the same ? Also "find" miserably fails if any directory it traverses contains (unix) symbolic links (which can't be resolved from windows, of course, but this shouldn't be a problem).