emacs - recuperarlos - reparar archivos dañados online

¿Por qué los etags generan un archivo corrupto de TAGS?

Question

Tengo el siguiente archivo fuente mínimo:

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

Si ejecuto etags como este, funciona bien:

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


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

Pero si ejecuto etags a través de find / xargs, el archivo TAGS está dañado:

$ 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

Tenga en cuenta que el nombre de archivo aparece arriba como fBoBar.c - ¡falso!

Me gusta poder generar TAGS haciendo algo como find . -name ''*.[ch]'' | xargs etags find . -name ''*.[ch]'' | xargs etags find . -name ''*.[ch]'' | xargs etags . Pero está corrompiendo la mayoría de los nombres de archivo cuando hago esto.

¿Alguna idea de por qué está fallando así y / o qué puedo hacer para que funcione?

Ubuntu Lucid. Etags es de emacs23-bin-common 23.1 + 1-4ubuntu7.

Editar :

En respuesta a la pregunta de fschmitt:

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


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

Nueva información :

Me acabo de dar cuenta de que la diferencia entre los dos usos en mi pregunta original anterior es la principal . en el camino. Y si llamo a etags como etags ./path/xx/yy/fooBar.c , corrompe el archivo. Entonces, una solución es asegurarse de que los argumentos a los etags no tengan etiquetas líderes. (Quizás esto es un error en etags, porque la documentación describe mi patrón de uso casi exactamente).

Answer 1

Esto es extraño. Que pasa si tu lo haces

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

¿en lugar?

Answer 2

Esto es lo que hago:

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

HTH.

Answer 3

Estoy enfrentando aquí el mismo problema. Sin embargo, dado que no ha proporcionado la versión de etags / emacs que utiliza, no estoy al 100%, estamos hablando del mismo problema.

Mi etags / emacs versión 23.1 y creo que hay un error en los etags que está corrompiendo los nombres de los archivos cuando están prefijados con un "./". Por ejemplo, recogí un archivo específico que decía que su nombre estaba dañado y generé el archivo TAGS para él con y sin el prefijo "./". La corrupción solo se produjo con el prefijo "./".

Mi solución para solucionar el problema es cortar el prefijo "./" antes de pasar los nombres de los archivos a "etags". Así es como lo hago:

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

¡Esto funciona para mí, espero que te sirva!

Answer 4

Me acabo de dar cuenta de que la diferencia entre los dos usos en mi pregunta original anterior es la principal. en el camino. Y si llamo a etags como etags ./path/xx/yy/fooBar.c, corrompe el archivo. Entonces, una solución es asegurarse de que los argumentos a los etags no tengan etiquetas líderes. (Quizás esto es un error en etags, porque la documentación describe mi patrón de uso casi exactamente).

Answer 5

Necesitas un - después de etags para que lea de stdin:

find . -name fooBar.c | xargs etags -

EDITAR:

Oops, realmente debería haber leído toda la pregunta. No sé por qué está corrompiendo los nombres de los archivos. Pero aún debes usar - :)