почему etags генерирует поврежденный файл TAGS? - PullRequest
6 голосов
/ 06 октября 2010

У меня есть следующий минимальный исходный файл:

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

Если я запускаю etags вот так, то все работает нормально:

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


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

Но если я запускаю etags через find / xargs, тегифайл поврежден:

$ 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

Обратите внимание, что имя файла отображается выше как fBoBar.c - фальшивка!

Мне нравится иметь возможность генерировать TAGS, выполняя что-то вроде find . -name '*.[ch]' | xargs etags.Но он портит большинство имен файлов, когда я делаю это.

Есть идеи, почему он так терпит неудачу, и / или что я могу сделать, чтобы заставить его работать?

Ubuntu Lucid.Etags из emacs23-bin-common 23.1 + 1-4ubuntu7.

Редактировать :

В ответ на вопрос fschmitt:

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


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

Новая информация :

Я только что заметил, что разница между этими двумя вариантами в моем первоначальном вопросе выше - это ведущий . на пути.И если я вызываю etags как etags ./path/xx/yy/fooBar.c, это повредит файл.Поэтому обходной путь - убедиться, что у аргументов etags нет ведущих тегов.(Возможно, это ошибка в etags, потому что документация описывает мой шаблон использования почти точно.)

Ответы [ 5 ]

6 голосов
/ 17 сентября 2011

Я сталкиваюсь здесь с той же проблемой. Однако, учитывая, что вы не предоставили версию etags / emacs, которую вы используете, я не на 100% говорю о той же проблеме.

Мои etags / emacs версии 23.1, и я думаю, что в etags есть ошибка, приводящая к повреждению имен файлов, когда они имеют префикс "./" Например, я выбрал один конкретный файл, имя которого было повреждено, и сгенерировал для него файл TAGS с префиксом «./» и без него. Повреждение произошло только с префиксом "./".

Мое - обойти проблему - решение состоит в том, чтобы сократить префикс "./" перед передачей имен файлов в "etags". Вот как я это делаю:

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

Это работает для меня, надеюсь, это для вас!

1 голос
/ 12 октября 2010

Я только что заметил, что разница между двумя вариантами использования в моем первоначальном вопросе выше - ведущая.на пути.И если я назову etags как etags ./path/xx/yy/fooBar.c, это повредит файл.Поэтому обходной путь - убедиться, что у аргументов etags нет ведущих тегов.(Возможно, это ошибка в etags, потому что документация описывает мой шаблон использования почти точно.)

0 голосов
/ 14 июля 2011

Вот что я делаю:

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

HTH.

0 голосов
/ 06 октября 2010

Это странно. Что произойдет, если вы сделаете

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

вместо

0 голосов
/ 06 октября 2010

Вам нужно - после etags, чтобы заставить его читать из стандартного ввода:

find . -name fooBar.c | xargs etags -

РЕДАКТИРОВАТЬ:

Ой, я действительно должен был прочитатьвесь вопрос.Я не знаю, почему это портит имена файлов.Но вы все равно должны использовать -:)

...