Warum generiert Etags eine beschädigte TAGS-Datei?

Question

Ich habe die folgende minimale Quelldatei:

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

Wenn ich etags wie folgt ausführen es funktioniert ok:

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


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

Aber wenn ich etags über find/xargs die TAGS-Datei ausgeführt wird beschädigt:

$ 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 

Beachten Sie den Dateinamen oben als fBoBar.c - gefälscht!

Ich mag in der Lage sein, TAGS zu generieren, indem Sie etwas wie find . -name '*.[ch]' | xargs etags tun. Aber es beschädigt die meisten Dateinamen, wenn ich das tue.

Eine Idee, warum es so versagt und/oder was ich tun kann, damit es funktioniert?

Ubuntu Lucid. Etags kommt von emacs23-bin-common 23.1 + 1-4ubuntu7.

bearbeitet:

Als Reaktion auf fschmitt Frage:

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


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

Neue Informationen:

Ich habe gerade bemerkt, dass der Unterschied zwischen den beiden Anwendungen in meiner ursprünglichen Frage oben ist der führende . auf dem Weg. Und wenn ich Etags wie etags ./path/xx/yy/fooBar.c aufrufen, korrumpiert es die Datei. Ein Workaround besteht also darin, sicherzustellen, dass die Argumente für Etags keine führenden Tags haben. (Vielleicht ist dies ein Bug in etags, weil die Dokumentation Muster meiner Nutzung beschreibt ziemlich genau.)

Answer 1

Ich habe gerade festgestellt, dass der Unterschied zwischen den beiden Anwendungen in meiner ursprünglichen Frage oben ist der führende. auf dem Pfad. Und wenn ich Etags wie Etags ./path/xx/yy/fooBar.c anrufe, verdirbt es die Datei. Ein Workaround besteht also darin, sicherzustellen, dass die Argumente für Etags keine führenden Tags haben. (Vielleicht ist dies ein Bug in etags, weil die Dokumentation Muster meiner Nutzung beschreibt ziemlich genau.)

Answer 2

Sie benötigen ein - nach etags, um es von stdin zu lesen:

find . -name fooBar.c | xargs etags - 

EDIT:

Hoppla, ich hätte wirklich die ganze Frage lesen sollen. Ich weiß nicht, warum es die Dateinamen verdirbt. Aber du solltest immer noch - verwenden :)

Answer 3

Das ist seltsam. Was passiert wenn Sie

etags `find . -name '*.c'` `find . -name '*.h'` 

stattdessen tun?

Answer 4

Das ist, was ich tue:

etags --members `find ./ | grep [ch]$` 

HTH.

Answer 5

Ich stehe hier das gleiche Problem gegenüber.Da Sie jedoch nicht die Version von etags/emacs angegeben haben, die ich nicht 100% Prozent verwende, sprechen wir über das gleiche Problem.

Meine etags/emacs Version 23.1 und ich denke, es gibt einen Fehler in Etags, die Dateinamen beschädigt, wenn ihnen ein "./" vorangestellt wird. Zum Beispiel habe ich eine bestimmte Datei gelesen, deren Name beschädigt wurde, und die TAGS-Datei dafür mit und ohne das Präfix "./" generiert. Die Beschädigung trat nur mit dem Präfix "./" auf.

Mein - umgehen Sie das Problem - Lösung ist das "./" Präfix vor dem Einziehen der Dateinamen zu "Etags" zu schneiden. Hier ist, wie ich es mache:

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

Das funktioniert für mich, ich hoffe, es tut für Sie!