Hi, and many thanks for your feedback !!

 

The comments you made are very sensible, and I’ll quickly comment on the most important ones :

 

4. That also came to my mind, but did not reveal any problems…. Perhaps I should try again and double check though !

 

5. You’re not the only one to wonder what I do it that way…. On the emacs mailing list other people wondered too ! See the first few messages in this thread:

http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00035.html

 

To cut a long story short here is the reason:

 

> 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 -
> 
> 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
> more filelist.txt | ctags -e -L -

 

I also realise that using “more” was not the best choice, but the problem is the same with “cat”.

In fact, the problem is the same when (as you suggest) the command is reduced to :

 

ctags -e -L filelist.txt

 

To illustrate this, if you want to investigate but only want to do one simple thing, then simply repeat these steps (quoted from http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00090.html)
 
> In fact, after a little debugging, I've devised the following experiment for
> you to reproduce (with --no-init-file)
> 
> 1/ >From a freshly opened emacs if do M-x shell followed by:
> 
> ctags -e -L filelist.txt
> 
> or even
 
> "C:/Program Files/Emacs/emacs-23.3/bin/cmdproxy.exe" /C "ctags -e -L
> filelist.txt"
> 
> then everything is fine.
> 
> 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.
> 
> 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.

 

I guess the first two questions I need to ask are:

 

Cheers,

David.

 


From: J.D. Laub [mailto:ctags@laubster.org]
Sent: 11 July 2012 03:48
To: ctags-users@lists.sourceforge.net
Subject: Re: [Ctags] Ctags generates absolute instead of relative paths

 

I'm definitely not the guy to answer either windoze or emacs questions, but if you're desperate, here are some things I'd try were I in your shoes:

  1. Give the documentation another thorough read to see if you might have missed anything.
  2. I'm not seeing any relevant ENVIRONMENT section in the etags manpage; that's the traditional place to discuss env vars that affect behavior (LANG comes to mind).  That doesn't rule out environment differences causing problems, just reduces the likelihood.
  3. Try specifying absolute paths, to ensure you're getting the files you want.  I wouldn't know how to do that in windoze, but on linux it would be something like "/bin/more /tmp/filelist.txt | /usr/local/bin/ctags -e -L -"
  4. Perhaps the input fed to ctags isn't what you think it is; inject a tee into your pipeline to confirm it's exactly what you expect: "more filelist.txt | tee landing.txt | ctags -e -L -".  Compare the landing.txt against one generated on linux.
  5. I'm not immediately seeing why you're using a pager to feed to content to ctags; seems "cat filelist.txt | ctags -e -L -" or, even better, "ctags -e -L filelist.txt" is a better fit

Good luck.  If you run across a solution, please post it.