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 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.)