Hi Daren,


No worries about any delay in responding…. I’m pretty bad at managing emails myself !


The find command is not to blame, nor is the file list (I only want files of a specific type), as it only contains relative paths.

In fact, I’ve just tried your command and here is what happens. Please can you try to reproduce the following steps ?


Open a fresh emacs on Windows (with --no-init-file)


1/ Do M-x shell, then execute “ctags -e -R”.  The paths in the TAGS file are relative as they should be.

2/ Do M-x shell-command, and enter “ctags -e -R”. The paths in the TAGS file are absolute.

3/ Repeat step 1 in the same shell buffer. Still relative paths

4/ Kill your shell buffer and repeat step 1. Paths are absolute.


I believe emacs is to blame…. But I would like to know is, what could explain the behaviour ?

Is ctags sensitive to specific environment variables which can have such an effect ? Can a different line ending character have such an effect ? Anything else ?





From: Darren Hiebert [mailto:Darren@DarrenHiebert.com]
Sent: 17 July 2012 14:13
To: David Chappaz
Cc: Ctags Users
Subject: Re: [Ctags] Ctags generates absolute instead of relative paths




I apologize for not replying sooner, but my “offline life” has become troublesome and dominating. I won’t take up that here.


To your problem: if you simply run the command “ctags -e -R”, only relative file paths will go into the TAGS file. You can bring up the TAGS file in a suitable editor to verify this (the format of a TAGS file is many entries separated by a form-feed character, followed by the file path, followed by subentries for each tags for that file). I presume that you are using a file list with ctags because you want tags only for a limited list of files?


However, the output of “find” may be sending absolute file names into ctags, which ctags will respect. Try running just the “find” command without piping the output to ctags and see what comes out.


Now, if the TAGS file contains relative files, and you are not getting what you want out of emacs, the problem is with emacs.




On Jul 11, 2012, at 4:35 AM, David Chappaz wrote:

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:


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:

  • Can anyone reproduce the behaviour I’m seeing ?
  • Can anyone explain it ?





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.


Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Ctags-users mailing list