why is etags generating a corrupted TAGS file?

Question

I have the following minimal source file:

$ cat path/xx/yy/fooBar.c 
void this_is_a_test(void)
{
}

If I run etags like this it works ok:

$ etags path/xx/yy/fooBar.c 
$ cat TAGS 


path/xx/yy/fooBar.c,25
void this_is_a_test(1,0

But if I run etags via find/xargs the TAGS file is corrupted:

$ find . -name fooBar.c
./path/xx/yy/fooBar.c
$ find . -name fooBar.c | xargs etags
$ cat TAGS


path/xx/yy/fBoBar.c,25
void this_is_a_test(^?1,0

Note the filename shows up above as fBoBar.c -- bogus!

I like to be able to generate TAGS by doing something like find . -name '*.[ch]' | xargs etags. But it is corrupting most of the filenames when I do this.

Any idea why it is failing like this, and/or what I can do to make it work?

Ubuntu Lucid. Etags is from emacs23-bin-common 23.1+1-4ubuntu7.

Edit:

In response to fschmitt's question:

$ etags $(find . -name fooBar.c)
$ cat TAGS 


path/xx/yy/fBoBar.c,25
void this_is_a_test(1,0

New info:

I just noticed that the difference between the two uses in my original question above is the leading . on the path. And if I call etags like etags ./path/xx/yy/fooBar.c, it corrupts the file. So a workaround is to make sure the args to etags don't have leading tags. (Perhaps this is a bug in etags, because the documentation describes my usage pattern almost exactly.)

Answer 1

I am facing here the same problem. However given that you haven't provided the etags/emacs version your using I am not 100% percent we are talking about the same problem.

My etags/emacs version 23.1 and I think there is a bug in etags that is corrupting file names when they are prefixed with a "./". For example I picked up one specific file that its name was being corrupted and generated the TAGS file for it with and without the "./" prefix. The corruption only occurred with the "./" prefix.

My - get around the problem - solution is to cut the "./" prefix before feeding the file names to "etags". Here is how I do it:

find . -name '*.[hc]' -print  | cut -c3- | xargs etags -

This works for me hope it does for you!

Answer 2

I just noticed that the difference between the two uses in my original question above is the leading . on the path. And if I call etags like etags ./path/xx/yy/fooBar.c, it corrupts the file. So a workaround is to make sure the args to etags don't have leading tags. (Perhaps this is a bug in etags, because the documentation describes my usage pattern almost exactly.)