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 ?
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: