Hi again, On Thu, May 14, 2009 at 07:44:50PM +0900, Shigio YAMAGUCHI wrote: > Hi, > > First of all, I'm thinking about implementing the nofollow option for > > gtags, as > > proposed on [2]. My question is, how exactly should this behave: should that > > only omit symbolic links that point to a directory or should that ignore > > symbolic links completely (e.g. ./foo.c pointing to ./bar.c) ? > > I have not thought about details yet. > Is there something proposal?
My proposal is to introduce new 'nofollow' option for gtags that would make gtags not to descend to symbolic links pointing to directories. > > > When thinking about it and looking into the code, I don't quite understand > > the > > following part of find_read_traverse() (libutil/find.c): > ... > > To be specific, what's the purpose of lines 539-551? If I'm not mistaken, > > the > > test at line 545 can never succeed because it is the opposite of the test at > > line 538. > > It might be so. But at present, this code is harmless. OK, that's what I've thought. > > > Next, is there any benefit of determining the type of a file in getdirs() > > function (I mean prefixing the filename with f,d) instead of determining = > > the > > type directly in the find_read_traverse() function? > > This is due to a historical reason. > In some systems like BSD, dirent structure has a member named 'd_type' which > describes file type. Determining type by it, we can avoid to calling stat(2) > for each files. But another systems like GNU/Linux doesn't has it. > I wanted to hide the difference in a basic function, getdirs(). > > By the way, GLOBAL doesn't use the 'd_type' currently due to the following > bug: > [http://lists.gnu.org/archive/html/bug-global/2003-08/msg00002.html] Thanks for clarifiction. Manpage for linux readdir states that the d_type isn't supported by all filesystems, so it IMHO means that you can't rely on that (IOW it's not a bug but a feature). Is the performance gain of using d_type on BSD's worth the trouble with maintaining getdirs() ? > > > And finally: what actually made me start thinking about this is fact that > > gtags > > can not treat recursive links, like in [3]. This actually makes it > > difficult to > > use gtags on directories created by quilt setup, because quilt creates > > exactly > > this type of directory structure (for a good reason). This could be worked > > around by the nofollow option, but IMHO the recursive link detection should > > be > > done also in default mode - what do you think? > > What is quilt setup? http://linux.die.net/man/1/quilt quilt setup is a 'quilt subcommand' intended to help maintaining RPM's. Given a specfile and a tarball with sources, it extracts the tarball, cds to this directory and creates symbolic link pointing to '..' -> so running gtags in the directory with sources fails. > What should GLOBAL do? It should detect and ignore recursive links (like find,ctags,cscope,.... do). Thanks, -- Best regards / s pozdravem Petr Uzel, Packages maintainer --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: [email protected] Lihovarská 1060/12 tel: +420 284 028 964 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz _______________________________________________ Bug-global mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-global
