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: Thu, 5 Jan 2012 12:20:30 -0000 Message-ID: <9C2570562E2A4B7BBDA61F564FCFC83F@EUROPE.ROOT.PRI> References: <20120102223315.3E60F1810C9@neo.msri.org> <408087A3D7BE475B884C0F93CE2298C7@us.oracle.com> <20120105054142.GA10149@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 1325766055 26582 80.91.229.12 (5 Jan 2012 12:20:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Jan 2012 12:20:55 +0000 (UTC) To: Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jan 05 13:20:51 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 1RimJO-0007RN-2p for geh-help-gnu-emacs@m.gmane.org; Thu, 05 Jan 2012 13:20:50 +0100 Original-Received: from localhost ([::1]:47115 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RimJN-0006lf-Ex for geh-help-gnu-emacs@m.gmane.org; Thu, 05 Jan 2012 07:20:49 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RimJB-0006l4-Kn for help-gnu-emacs@gnu.org; Thu, 05 Jan 2012 07:20:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RimJA-0004dE-CX for help-gnu-emacs@gnu.org; Thu, 05 Jan 2012 07:20:37 -0500 Original-Received: from cluster-d.mailcontrol.com ([85.115.60.190]:34071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RimJA-0004co-15 for help-gnu-emacs@gnu.org; Thu, 05 Jan 2012 07:20:36 -0500 Original-Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly49d.srv.mailcontrol.com (MailControl) with ESMTP id q05CKX9A006789 for ; Thu, 5 Jan 2012 12:20:33 GMT Original-Received: from DC04PC01 ([10.103.11.129]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 12:20:33 +0000 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20120105054142.GA10149@hysteria.proulx.com> Thread-Index: AczLbLfzVn5beiXIQeePNkaPanJzCAAG4dXg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 05 Jan 2012 12:20:33.0347 (UTC) FILETIME=[6BF93130:01CCCBA4] X-Scanned-By: MailControl 7.6.5 (www.mailcontrol.com) on 10.68.0.159 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:83351 Archived-At: > Bob Proulx wrote: > Please don't hijack discussion threads. You replied to Drew Adams > message with the subject "M-x mystery" and changed the subject. If > you wish to create a new topic please create a new message. Changing > the subject is used for topic drift within a discussion thread and > does not create a new thread of discussion. This is to your advantage > since people who are skipping the thread will also skip your message. I can't argue with that. You're 100% correct, and I'm just hoping Drew Adams will forgive me. I replied to an existing message and changed the subject out of laziness I suppose, and didn't realise it would have unwanted consequences. I'll learn from this mistake ! Out of curiosity, is there any way to move this discussion in a new thread, or is it too late ? > I am not using that version of tags and so I can't check the options > but to me using "-" (indicating to read standard input) looks to me > like a strange way to do things. And piping from more to it is > strange times strange creating a lot of it. > > > more filelist.txt | ctags -e -L - As you have guessed, I'm not a shell expert, but I now understand the example I gave was a bit strange indeed. In fact I ended up with this command, because I was trying to "debug" a more complex command, where the result of "find" is piped to ctags: find -type f -name "*.c" | ctags -e -L - Presumably this way of doing is more "conventional" but again I'm not an expert, and if you think this is a bit awkward for any reason, please let me know ! Because I was getting the absolute/relative path problem I mentioned, I simply split the command into two fragments, explicitly creating an intermediate file: find -type f -name "*.c" > filelist.txt cat filelist.txt | ctags -e -L - > Instead have you tried simply running ctags on the file? Try this > instead: > > ctags -e -L filelist.txt Doh, I should have thought of doing that from the start. This is by far the simplest and most natural way of doing things... > That should work more reliably the same on all operating systems. > Expecially since pipes on MS-Windows are not speedy. And yet I still get the same behaviour... Running "ctags -e -L filelist.txt" directly from the shell and doing the same in shell-command still produces two different results... How can that be ?? This is really beyond me ! > > PS, on a slightly different note: > > > > 1/ on linux, shell-command also does something funny. > > Seeing the ":::::::::::::: FILENAME ::::::::::::::" header is a clue > to your problem. It tells me that more has been told to read multiple > files. But the command you list does not have multiple files. I am > sure that when you run it from the command line and saying that it is > working okay there that it isn't getting multiple files. So somehow > when calling that pipeline from shell-command there are multiple files > being offered to the command. Yes that makes perfect sense. I tried something like "more test1.c test2.c" directly from the command line, and I did get the separator with the filename. So when doing "more filetest.txt" from shell-command, "more" is clearly getting multiple files. > That is probably somehow related to > your difference in behavior of relative paths versus absolute paths. Yes I suppose so. In fact I've just discovered that "ctags -e -L filelist.txt" works fine when directly used in a proper windows shell, but does not when used in an emacs's shell buffer (i.e. that produces the same result, with absolute paths, as with shell-command) It sounds to me that the problem is related to an extra termination character added to the command line by emacs before it's passed to the shell... But I'm not skilled enough to figure out the details... Any ideas ?