Lote: Escapar con cuidado

Question

Siempre he odiado el lote y todavía lo hago, incluso para las cosas más simples prefiero C o PHP/Perl. Pero esta vez no podría ir sin él, **** suspiro ****.

Quería redirigir un comando echo a otro comando. Por ejemplo:

echo example | more 

pero también quería ser capaz de utilizar caracteres especiales en la parte eco de la tubería:

echo & | more 

Lo que por supuesto no funcionó. Así que probé:

echo ^& | more 

Lo que tampoco funcionó. Luego, por ensayo y error, encontré:

echo ^^^& | more 

y funcionó. Pero como programador interesado me pregunto por qué. ¿Por qué no funcionó ^& y ^^^&?

Answer 1

La razón tiene que ver con la forma en que Windows implementa las tuberías: cada lado de la tubería se ejecuta en su propio shell CMD. Su comando echo ^& | more realidad intenta ejecutar

C:\Windows\system32\cmd.exe /S /D /c" echo & " 

a la izquierda y

C:\Windows\system32\cmd.exe /S /D /c" more " 

a la derecha. Puede ver por qué falla el lado izquierdo, intentando hacer eco de un & sin enclavamiento. El escape fue consumido por la fase de análisis inicial antes de que se ejecute el lado izquierdo real.

También es fácil ver por qué funciona su solución. El lado izquierdo de echo ^^^& | more se convierte en

C:\Windows\system32\cmd.exe /S /D /c" echo ^& " 

hay muchas complicaciones sutiles cuando se trabaja con tubos de Windows. Consulte Why does delayed expansion fail when inside a piped block of code? para obtener más información. La respuesta seleccionada tiene la mejor información, pero recomiendo leer la pregunta y todas las respuestas para obtener el contexto de la respuesta seleccionada.

Answer 2

La primera ^ está escapando el carácter ^ en sí (la segunda ^) y la tercera ^ está escapando de las &.

Cuando se ejecuta un comando como ECHO ^& | MORE, la ^& se sustituye con & por la cáscara antes de que el resultado se canaliza a MORE.

Por lo tanto, cuando se ejecuta ECHO ^^^& | MORE, la cáscara reemplaza ^^ con ^ y la ^& con & y luego canaliza la salida a MORE.