2008-10-24 244 views

Respuesta

42

En realidad, se necesitan 2 condiciones para que esto suceda:

  • el archivo por lotes no deben utilizar los finales de línea CRLF
  • la etiqueta de saltar a debe abarcar un límite de bloque (en contraposición a y: fin etiqueta que es solo un atajo al final de su script)

See. The system cannot find the batch label specified y Batch-as-batch-can!

+2

Tuve este problema con el archivo de lotes de hormigas enviado con eclipse y se lo llamó desde MSVC, cambiando todas las terminaciones de línea, gracias. –

+0

Otra razón que explica aquí: http://stackoverflow.com/q/1522129/471214 – mmdemirbas

+0

Encontré este problema con los scripts por lotes enviados con Groovy: todos los scripts solo contenían LF, tuve que reemplazarlo manualmente con CRLF. – Neel

9

Si el archivo por lotes tiene una línea Unix, esto puede suceder a veces.

Solo unix2dos y el problema debe ser resuelto.

5

También debe asegurarse de que al llamar a otras secuencias de comandos utilice CALL, en lugar de llamarlos en el entorno de la persona que llama.

11

Aquí está el problema y cómo solucionarlo. El problema es un error o una característica en el programa cmd de lote de DOS. Primero la declaración clara del problema. Si tiene un archivo por lotes DOS con etiquetas de destino como ": dothis", y al final de la etiqueta no tiene espacio, entonces el archivo por lotes no funcionará si el final de línea son terminaciones de línea UNIX. Esto significa que debe ejecutar unix2dos en el archivo antes de poder usarlo.

La causa principal es el procesador de línea de comandos de DOS, (programa de shell), toma el carácter de fin de línea de UNIX como parte de la etiqueta. Como la parte ir nunca usa esto como la etiqueta, nunca se encuentra, ya que tal etiqueta realmente no existe. La solución es poner un espacio extra al final de cada etiqueta de destino, o incluso mejor cada línea. Ahora el final de líneas de UNIX no viene a jugar, ya que el espacio actúa como separador y todo funciona.

24

Tengo el mismo problema antes. Sin embargo, la causa raíz no era CRLF en absoluto. Fue porque en el script ejecuté un programa externo como Ant, pero no puse un CALL antes de Ant. Por lo tanto, asegúrese de CALL cada programa externo utilizado en su secuencia de comandos por lotes.

+0

Me gustaría señalar que esta es una razón adicional. Tuve este problema al llamar y al programa externo y esta sugerencia resolvió el problema. –

+0

Encontré este problema con los scripts por lotes enviados con Groovy, ¡no estoy seguro de por qué no tienen el exe en lugar de Windows! – Neel

+2

¡En Windows, podría estar ejecutando un '.bat' y no darse cuenta! Acabo de enterarme de que ejecutar 'mvn' en realidad ejecuta un archivo por lotes,' mvn.cmd', y perdí una hora tratando de entender por qué mis scripts fallaban con este error cada vez que ejecutaba 'mvn'. – jordanpg

2

tuve este problema después de copiar un comando de inicio de palabra y pegarlo en la ventana de comandos. Había una opción con "-" en el frente, y pensé que el aspecto era el mismo que en el DOS "-" no lo era :) Después de escribir el "-" solo el problema se resolvió y el lote funcionó ... un disco duro para encontrar un problema ...

1

Encontré un problema similar en este momento con un archivo .cmd y Windows 8. La solución fue cambiar todas las terminaciones de línea al estilo CR + LF DOS. El problema era confuso porque el archivo por lotes funcionaba principalmente y las líneas cambiaban el efecto.

El archivo .cmd parecía:

call:function_A "..\..\folderA\" 
call:function_B "..\..\folderB\" 
call:function_C "..\..\folderC\" 
call:function_D "..\..\folderD\" 
goto:eof 

:function_A 
rem do stuff 
goto:eof 

...etc... 

Función C causaría error "El sistema no puede encontrar la etiqueta del lote especificado". Extrañamente, podría desaparecer reorganizando las llamadas. El cambio de las terminaciones de línea de 0x0A a 0x0D0A parece haberlo solucionado.

Quizás VonC significaba "el archivo por lotes debe usar terminaciones de línea CRLF".

+0

Con respecto al comentario de VonC, es lógicamente correcto, aunque redactado de manera confusa. Él dice (parafraseando), para que ocurra el error, estas dos condiciones deben ser verdaderas. ERROR == (A && B), por lo tanto, si, como la mayoría de las personas, NO desea un error, ¡entonces invierta lo que dijo! ERROR == (! A ||! B), por lo que para evitar el error, la inversión de una condición, la otra o ambas deben ser verdaderas. Para evitar errores, use CRLF o evite abarcar un límite de bloque. Para archivos de lotes más simples, CR LF probablemente funcione. – user314159

Cuestiones relacionadas