Thread: [Ctags] Ctags generates absolute instead of relative paths
Brought to you by:
dhiebert
From: David C. <dav...@fr...> - 2012-01-18 10:20:04
|
Hi all, I have a problem when generating TAGS from Gnu Emacs 23.3, but the problem only occurs on Windows and not on linux. Although I use the "-e" option and even the explicit "--tag-relative=yes" option, the TAGS file that is generated contains absolute paths instead of relative paths. The details of this problem can be found here: http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00035.html I originally thought this problem was related to emacs, not to ctags itself, because it only occurs when the shell command used to build the TAGS file is issued from within emacs, not from a plain windows shell. However I now have doubts, and I'm wondering if ctags is not to blame after all. To reproduce the problem, simply follow the steps at the end of this post: http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00090.html Can anyone reproduce it ? Does anyone have a guess as to what the problem is ? Is ctags sensitive to any environment variables (as opposed to command line arguments) which can explain that behaviour ? Many thanks in advance Cheers, David. |
From: David C. <dav...@fr...> - 2012-02-11 12:00:44
|
Any suggestion, anyone ? It would be nice to get to the bottom of this. Cheers, David. On 18/01/12 09:51, David Chappaz wrote: > > Hi all, > > I have a problem when generating TAGS from Gnu Emacs 23.3, but the > problem only occurs on Windows and not on linux. > > Although I use the "-e" option and even the explicit"--tag-relative=yes" option, the TAGS file that is generated contains absolute paths instead of relative paths. > > The details of this problem can be found here: > > http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00035.html > > I originally thought this problem was related to emacs, not to ctags > itself, because it only occurs when the shell command used to build > the TAGS file is issued from within emacs, not from a plain windows shell. > > However I now have doubts, and I'm wondering if ctags is not to blame > after all. > > To reproduce the problem, simply follow the steps at the end of this post: > > http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00090.html > > Can anyone reproduce it ? Does anyone have a guess as to what the > problem is ? > > Is ctags sensitive to any environment variables (as opposed to command > line arguments) which can explain that behaviour ? > > Many thanks in advance > > Cheers, > > David. > |
From: David C. <dav...@fr...> - 2012-07-10 11:04:54
|
Recently there seem to some signs of life on the mailing list.. So I'm trying my chance again.. Could anyone please have a look, explain and/or solve the problem ? Cheers !! David. _____ From: David Chappaz [mailto:dav...@fr...] Sent: 11 February 2012 11:26 To: cta...@li... Subject: Re: [Ctags] Ctags generates absolute instead of relative paths Any suggestion, anyone ? It would be nice to get to the bottom of this. Cheers, David. On 18/01/12 09:51, David Chappaz wrote: Hi all, I have a problem when generating TAGS from Gnu Emacs 23.3, but the problem only occurs on Windows and not on linux. Although I use the "-e" option and even the explicit "--tag-relative=yes" option, the TAGS file that is generated contains absolute paths instead of relative paths. The details of this problem can be found here: http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00035.html I originally thought this problem was related to emacs, not to ctags itself, because it only occurs when the shell command used to build the TAGS file is issued from within emacs, not from a plain windows shell. However I now have doubts, and I'm wondering if ctags is not to blame after all. To reproduce the problem, simply follow the steps at the end of this post: http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00090.html Can anyone reproduce it ? Does anyone have a guess as to what the problem is ? Is ctags sensitive to any environment variables (as opposed to command line arguments) which can explain that behaviour ? Many thanks in advance Cheers, David. |
From: J.D. L. <ct...@la...> - 2012-07-11 03:05:51
|
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: * Give the documentation another thorough read to see if you might have missed anything. * 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. * 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 -" * 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. * 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. On 07/10/12 04:14 AM, David Chappaz wrote: > Recently there seem to some signs of life on the mailing list…. > > So I'm trying my chance again…. Could anyone please have a look, explain and/or solve the problem ? > > Cheers !! > > David. > > ------------------------- > > FROM: David Chappaz [mailto:dav...@fr...] > SENT: 11 February 2012 11:26 > TO: cta...@li... > SUBJECT: Re: [Ctags] Ctags generates absolute instead of relative paths > > Any suggestion, anyone ? > It would be nice to get to the bottom of this. > Cheers, > David. > > On 18/01/12 09:51, David Chappaz wrote: > > Hi all, > > I have a problem when generating TAGS from Gnu Emacs 23.3, but the problem only occurs on Windows and not on linux. Although I use the " > > -e > " option and even the explicit " > > --tag-relative=yes > " option, the TAGS file that is generated contains absolute paths instead of relative paths. > > The details of this problem can be found here: > > http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00035.html [1] > > I originally thought this problem was related to emacs, not to ctags itself, because it only occurs when the shell command used to build the TAGS file is issued from within emacs, not from a plain windows shell. > > However I now have doubts, and I'm wondering if ctags is not to blame after all. > > To reproduce the problem, simply follow the steps at the end of this post: > > http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00090.html [2] > > Can anyone reproduce it ? Does anyone have a guess as to what the problem is ? > > Is ctags sensitive to any environment variables (as opposed to command line arguments) which can explain that behaviour ? > > Many thanks in advance > > Cheers, > > David. Links: ------ [1] http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00035.html [2] http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00090.html |
From: David C. <dav...@fr...> - 2012-07-11 09:37:28
|
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: * Can anyone reproduce the behaviour I'm seeing ? * Can anyone explain it ? Cheers, David. _____ From: J.D. Laub [mailto:ct...@la...] Sent: 11 July 2012 03:48 To: cta...@li... 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. |
From: Darren H. <Darren@DarrenHiebert.com> - 2012-07-17 13:13:12
|
David, 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. Darren 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: > 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: > Can anyone reproduce the behaviour I’m seeing ? > Can anyone explain it ? > > Cheers, > David. > > From: J.D. Laub [mailto:ct...@la...] > Sent: 11 July 2012 03:48 > To: cta...@li... > 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: > > Give the documentation another thorough read to see if you might have missed anything. > 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. > 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 -" > 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. > 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 > Cta...@li... > https://lists.sourceforge.net/lists/listinfo/ctags-users |
From: David C. <dav...@fr...> - 2012-07-17 13:40:20
|
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 ? Cheers, David. _____ 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 David, 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. Darren 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: 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: * Can anyone reproduce the behaviour I'm seeing ? * Can anyone explain it ? Cheers, David. _____ From: J.D. Laub [mailto:ct...@la...] Sent: 11 July 2012 03:48 To: cta...@li... 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 Cta...@li... https://lists.sourceforge.net/lists/listinfo/ctags-users |
From: David C. <dav...@fr...> - 2012-07-18 08:55:54
|
> 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 ? Let me rephrase the question, and be more specific. With the simple command "ctags -e -R", i'm guessing that ctags internally builds the list of files to be processed. With the -e option, ctags should only use relative paths in the TAGS files. However, some other criterion somehow takes precedence over the -e option, which causes ctags to use absolute paths. What can that criterion be ? Even with "ctags -e -R --tag-relative=yes" I'm seeing the same behaviour (absolute paths) Perhaps emacs is to blame for wrongly configuring "external" parameters (e.g. environment variables), but all I'm asking is, what are the parameters that ctags internally looks at, to make a decision about relative / absolute paths ? |
From: David C. <dav...@fr...> - 2012-07-19 13:05:25
|
Darren, After investigating more in details, I believe I have found a bug in ctags. The root cause of the problem I'm seeing is that the routine absoluteFilename always makes the drive letter uppercase (Windows paths only). On the other hand, the routine absoluteDirname does not do the same. This in turn causes problems in the routine setSourceFileParameters, more specifically on the line: relativeFilename (vStringValue (fileName), TagFile.directory) In effect, relativeFilename compares the two strings, which sometimes differ from the start (drive letter with a different case). The net effect is that relativeFilename identifies no common path between the two strings, and therefore returns absolute paths. There are several ways to solve the problem (which may be more widespread than just the above example). I could just suggest my own quick and dirty fix, but I believe you are in the best position to make a nice and clean one. Hope that helps, David. _____ 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 David, 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. Darren On Jul 11, 2012, at 4:35 AM, David Chappaz wrote: |
From: Darren H. <Darren@DarrenHiebert.com> - 2012-07-19 13:59:07
|
David, I have to thank you for spelunking into the code like this. However, I am confused by your analysis. If I understood your example correctly, emacs was invoking ctags from two different contexts, one from a shell started from emacs, and another from emacs directly. However, in both cases, ctags would have been started without any file name argument, leaving it generate its own list from the -R option. Your analysis does not indicate why ctags would behave differently under the two cases unless the drive letter was sometimes generated in one case and sometimes in another. Are you suggesting that etags is invoking ctags with an argument in one case? Also, absoluteDirname() calls absoluteFilename() to do it’s dirty work, so it doesn’t appear possible for one to generate a drive letter in different case than the other. Darren On Jul 19, 2012, at 8:04 AM, David Chappaz wrote: > Darren, > > After investigating more in details, I believe I have found a bug in ctags. > > The root cause of the problem I’m seeing is that the routine absoluteFilename always makes the drive letter uppercase (Windows paths only). > On the other hand, the routine absoluteDirname does not do the same. > > This in turn causes problems in the routine setSourceFileParameters, more specifically on the line: > relativeFilename (vStringValue (fileName), TagFile.directory) > > In effect, relativeFilename compares the two strings, which sometimes differ from the start (drive letter with a different case). > The net effect is that relativeFilename identifies no common path between the two strings, and therefore returns absolute paths. > > There are several ways to solve the problem (which may be more widespread than just the above example). I could just suggest my own quick and dirty fix, but I believe you are in the best position to make a nice and clean one. > > Hope that helps, > David. > > 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 > > David, > > 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. > > Darren > > On Jul 11, 2012, at 4:35 AM, David Chappaz wrote: > > > |
From: David C. <dav...@fr...> - 2012-07-19 15:40:48
|
Hi Darren, You're right to be confused because I made a mistake ! Here is what (I believe) is the real problem ! In openTagFile(), the default value of TagFile.name does not contain PATH_SEPARATOR. Therefore absoluteDirname() never calls absoluteFilename() and the drive letter in TagFile.directory is not forced to uppercase. Furthermore, when invoking ctags from a shell, the drive letter in TagFile.directory (CurrentDirectory) happens to be uppercase so the bug is invisible. But for some reason, when invoking ctags from emacs directly (with M-x shell-command), then the driver letter in TagFile.directory happens to be lowercase and the bug shows up. This eventually causes relativeFilename to fail to identify the common part in the paths, etc, etc. David. _____ From: Darren Hiebert [mailto:Darren@DarrenHiebert.com] Sent: 19 July 2012 14:59 To: David Chappaz Cc: 'Ctags Users' Subject: Re: [Ctags] Ctags generates absolute instead of relative paths David, I have to thank you for spelunking into the code like this. However, I am confused by your analysis. If I understood your example correctly, emacs was invoking ctags from two different contexts, one from a shell started from emacs, and another from emacs directly. However, in both cases, ctags would have been started without any file name argument, leaving it generate its own list from the -R option. Your analysis does not indicate why ctags would behave differently under the two cases unless the drive letter was sometimes generated in one case and sometimes in another. Are you suggesting that etags is invoking ctags with an argument in one case? Also, absoluteDirname() calls absoluteFilename() to do it's dirty work, so it doesn't appear possible for one to generate a drive letter in different case than the other. Darren On Jul 19, 2012, at 8:04 AM, David Chappaz wrote: Darren, After investigating more in details, I believe I have found a bug in ctags. The root cause of the problem I'm seeing is that the routine absoluteFilename always makes the drive letter uppercase (Windows paths only). On the other hand, the routine absoluteDirname does not do the same. This in turn causes problems in the routine setSourceFileParameters, more specifically on the line: relativeFilename (vStringValue (fileName), TagFile.directory) In effect, relativeFilename compares the two strings, which sometimes differ from the start (drive letter with a different case). The net effect is that relativeFilename identifies no common path between the two strings, and therefore returns absolute paths. There are several ways to solve the problem (which may be more widespread than just the above example). I could just suggest my own quick and dirty fix, but I believe you are in the best position to make a nice and clean one. Hope that helps, David. _____ 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 David, 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. Darren On Jul 11, 2012, at 4:35 AM, David Chappaz wrote: |
From: David C. <dav...@fr...> - 2012-07-20 13:51:50
|
I think all it takes to solve the problem is to replace the following two lines in absoluteDirname() if (slashp == NULL) res = eStrdup (CurrentDirectory); with if (slashp == NULL) res = absoluteFilename ( CurrentDirectory ); Perhaps something slightly more sophisticated needs to be done, similarly to what appears in the "else" statement, but I don't quite understand what the role of that is. Perhaps a cosmetic improvement for the windows build would be to use "..\" in relativeFilename() when building relative paths, instead of "../" (which windows emacs does not complain about. It's the just mixture of \ and / in paths which looks a bit odd) David. _____ From: David Chappaz [mailto:dav...@fr...] Sent: 19 July 2012 16:40 To: 'Darren Hiebert' Cc: 'Ctags Users' Subject: Re: [Ctags] Ctags generates absolute instead of relative paths Hi Darren, You're right to be confused because I made a mistake ! Here is what (I believe) is the real problem ! In openTagFile(), the default value of TagFile.name does not contain PATH_SEPARATOR. Therefore absoluteDirname() never calls absoluteFilename() and the drive letter in TagFile.directory is not forced to uppercase. Furthermore, when invoking ctags from a shell, the drive letter in TagFile.directory (CurrentDirectory) happens to be uppercase so the bug is invisible. But for some reason, when invoking ctags from emacs directly (with M-x shell-command), then the driver letter in TagFile.directory happens to be lowercase and the bug shows up. This eventually causes relativeFilename to fail to identify the common part in the paths, etc, etc. David. _____ From: Darren Hiebert [mailto:Darren@DarrenHiebert.com] Sent: 19 July 2012 14:59 To: David Chappaz Cc: 'Ctags Users' Subject: Re: [Ctags] Ctags generates absolute instead of relative paths David, I have to thank you for spelunking into the code like this. However, I am confused by your analysis. If I understood your example correctly, emacs was invoking ctags from two different contexts, one from a shell started from emacs, and another from emacs directly. However, in both cases, ctags would have been started without any file name argument, leaving it generate its own list from the -R option. Your analysis does not indicate why ctags would behave differently under the two cases unless the drive letter was sometimes generated in one case and sometimes in another. Are you suggesting that etags is invoking ctags with an argument in one case? Also, absoluteDirname() calls absoluteFilename() to do it's dirty work, so it doesn't appear possible for one to generate a drive letter in different case than the other. Darren On Jul 19, 2012, at 8:04 AM, David Chappaz wrote: Darren, After investigating more in details, I believe I have found a bug in ctags. The root cause of the problem I'm seeing is that the routine absoluteFilename always makes the drive letter uppercase (Windows paths only). On the other hand, the routine absoluteDirname does not do the same. This in turn causes problems in the routine setSourceFileParameters, more specifically on the line: relativeFilename (vStringValue (fileName), TagFile.directory) In effect, relativeFilename compares the two strings, which sometimes differ from the start (drive letter with a different case). The net effect is that relativeFilename identifies no common path between the two strings, and therefore returns absolute paths. There are several ways to solve the problem (which may be more widespread than just the above example). I could just suggest my own quick and dirty fix, but I believe you are in the best position to make a nice and clean one. Hope that helps, David. _____ 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 David, 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. Darren On Jul 11, 2012, at 4:35 AM, David Chappaz wrote: |
From: Kaz K. <ka...@ky...> - 2012-07-20 23:39:36
|
I might have run into a similar, possibly related issue when I worked on an embedded Linux distro. For compiling many projects, including kernels, I used symbolic link farms generated by the crusty old "lndir" tool from the XWindow project. A link farm is a cloned directory structure which is populated by individual symlinks to files in the original directory structure. So you can compile a project in one place while the source is in another place (and that place can even be read-only). This works even if the makefiles of that project are oblivious to the idea of a separate build directory. Anyway, I seem to remember noticing that ctags would get confused by the symlinks in such a tree and generate absolute paths. |
From: David C. <dav...@fr...> - 2012-07-23 08:44:03
|
> Anyway, I seem to remember noticing that ctags would get > confused by the symlinks in such a tree and generate absolute paths. If your issue is specific to symlinks, then the below is probably irrelevant, but I also have been a little confused about the effect of the option --tag-relative, where I would get absolute paths, even with --tag-relative=yes. Conversely, I would get relative paths, even with --tag-relative=no. In fact it turns out (as the manual says), that absolute paths are used in the TAGS file, if absolute paths are used in the list of source files provided to ctags. Therefore in this case --tag-relative=yes has no effect. Also (but the manual doesn't explicitly say that), paths in the list of source files appear unchanged in the TAGS file, if --tag-relative=no is used. Therefore in this case, you can get relative paths (if you supply relative paths), even with --tag-relative=no. Perhaps the above behaviour is desirable for a good reason. Nevertheless, you can always force relative or absolute paths depending on --tag-relative, by replacing the following two lines in setSourceFileParameters() if (! Option.tagRelative || isAbsolutePath (vStringValue (fileName))) File.source.tagPath = eStrdup (vStringValue (fileName)); with if (! Option.tagRelative ) File.source.tagPath = absoluteFilename (vStringValue (fileName)) Note that this strategy is not infallible. E.g. on windows, if the TAGS file and the source files are located on different drives, then you'll get absolute paths even with --tag-relative=yes, because there is no way to express paths relatively in this case. |