From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: shell-command causes problems with absolute/relative paths in TAGS Date: Thu, 5 Jan 2012 15:20:30 -0700 Message-ID: <20120105222030.GA22189@hysteria.proulx.com> References: <20120102223315.3E60F1810C9@neo.msri.org> <408087A3D7BE475B884C0F93CE2298C7@us.oracle.com> <20120105054142.GA10149@hysteria.proulx.com> <9C2570562E2A4B7BBDA61F564FCFC83F@EUROPE.ROOT.PRI> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1325802047 9107 80.91.229.12 (5 Jan 2012 22:20:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Jan 2012 22:20:47 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: David Chappaz Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jan 05 23:20:43 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 1Rivft-00007a-Q1 for geh-help-gnu-emacs@m.gmane.org; Thu, 05 Jan 2012 23:20:42 +0100 Original-Received: from localhost ([::1]:55647 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rivfs-0003Eg-VJ for geh-help-gnu-emacs@m.gmane.org; Thu, 05 Jan 2012 17:20:40 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:35006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rivfm-0003EO-8O for help-gnu-emacs@gnu.org; Thu, 05 Jan 2012 17:20:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rivfk-0007oI-QQ for help-gnu-emacs@gnu.org; Thu, 05 Jan 2012 17:20:34 -0500 Original-Received: from joseki.proulx.com ([216.17.153.58]:35054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rivfk-0007oC-Eq for help-gnu-emacs@gnu.org; Thu, 05 Jan 2012 17:20:32 -0500 Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id D80C7211D2; Thu, 5 Jan 2012 15:20:30 -0700 (MST) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 8AF3E2DCDC; Thu, 5 Jan 2012 15:20:30 -0700 (MST) Mail-Followup-To: Bob Proulx , David Chappaz , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <9C2570562E2A4B7BBDA61F564FCFC83F@EUROPE.ROOT.PRI> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 216.17.153.58 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:83363 Archived-At: David Chappaz wrote: > Bob Proulx wrote: > > > 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. Oh good. We all have to start somewhere. > 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 ! Yes. That way is much more normal. Because the find is doing something useful and contributing positively to the overall task. That way is a very typical way of doing things. Good! Unfortunately it suffers problems when people embed newlines inside of filenames. As long as you don't do that, and it is unusual to do so, then I would keep on doing it exactly that way. Not using newlines in a C source code file name is good conventional practice. If I found anyone putting newlines in a C source code filename I would convince them otherwise. :-) So you are fine. But it is useful to understand where the convention breaks down. > 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 - I can now see how you got there. Like most things knowing the background story fills in all of the details and makes everything make sense. (But in case anyone jumped into the thread here we are all agreed that the improvement below is better.) > > 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... Yay! Much simpler and more direct. Simple is good. > > 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 ! Drat! I was hoping that the direct filename method would clean things up and solve your problem. I don't really have any other hints. Because I can't recreate your problem. It works fine for me. > > 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. Can you make out the filenames that it is getting from the output? Can you do some testing and try to figure out what filenames are being added to the command? I think if you could deduce what the extra file names are then that would be a huge big clue to determining where they are coming from and then fixing the problem. Perhaps using 'echo' to echo the args out would be useful. But the problem is that you are using an operating system that I don't know the right debug techniques and so do not know what to suggest. I would suggest echo but I fear that the echo I would see and the echo you would see would be completely different and that will just confound things. For me a program such as echo that just echo printed all of its arguments would allow me to see the extra arguments supplied. But I don't know what it will do on your system. It may or may not be useful. M-! echo > > 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, That makes sense so far. > 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 like a bug in your port of emacs in the area of shell-command. Is there a different port that you could try? Maybe it would behave differently. > 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 ? I am one of those people what has been using Unix and GNU systems all of my life and have virtually bypassed ever using an MS machine. When I try to use one I am lost and frustrated. Which is why I have sympathy for people going the other direction and try to help out when I can. But it means that I really have no advice available for you. 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. I would create a helper script which did the actions I wanted (find piped to ctags in this case) and then call the script instead of the raw commands. That could help debug things too since then once you are inside the helper script you can add more debugging there. Bob