Nuestro team de especialistas pasados muchos días de trabajo y de recopilar de datos, obtuvieron los datos necesarios, esperamos que te sea útil en tu plan.
Solución:
Dado que CMD.EXE está muy poco documentado, no estoy seguro de cuál debería ser el comportamiento esperado. Ciertamente no he visto ninguna documentación sobre cuál es el comportamiento esperado. Así que creo que será difícil encontrar a alguien que pueda dar una respuesta definitiva sobre si alguno de los comportamientos es un error. Pero estoy de acuerdo en que ciertamente es inconsistente y me parece al menos un defecto de diseño.
No caracterizaría la situación como caótica en el sentido de que el comportamiento de un comando en particular parece ser reproducible. Pero CMD.EXE es inconsistente en el sentido de que no puedo ver ninguna forma de predecir cómo se comporta un comando sin probarlo.
No tengo ninguna explicación, pero tengo algunas clasificaciones refinadas de comportamientos.
La redirección de stdout o stderr a stdin funciona perfectamente bien siempre que ningún comando intente escribir nada en la salida redirigida. El comportamiento extraño solo ocurre cuando un comando interno intenta escribir en stdout o stderr después de haber sido redirigido a stdin.
Extendí sus pruebas y he visto los siguientes comportamientos distintos:
STDERR redirigido 2>&01
No he realizado pruebas exhaustivas, pero cada comando interno que probé que escribe en stderr terminará inmediatamente la sesión de comando si stderr ha sido redirigido a stdin. Ejemplos incluyen:
cd invalidPath 2>&0
vol x 2>&0
copy nonExistentFile 2>&0
move nonExistentFile 2>&0
set nonExistentVariable 2>&0
dir nonExistentFile 2>&0
Lo que pensó que era una excepción en realidad nunca escribe en stderr. Pruebe lo siguiente sin redirección y verá que no hay ningún mensaje de error:
dir nonExistentFIle *
Por lo tanto, no hay motivo para que el comando finalice la sesión del comando si stderr se redirige a stdin.
DIR solo imprime un mensaje de error si no encuentra ningún archivo coincidente en todas las máscaras de archivo proporcionadas.
:: This prints an error message
dir nonExistentFile1 nonExistentFile2
:: So this terminates the command session
dir nonExistentFile1 nonExistentFile2 2>&0
STDOUT redirigido 1>&0
Estos son los comportamientos que he visto para la salida estándar redirigida:
1) La salida desaparece en el éter, sin ningún mensaje de error.
Ejemplos:
vol >&0
copy /-y file1 existingFile2 >&0
move /-y file1 existingFile2 >&0
2) La salida falla y se muestra un mensaje de error en stderr. Un solo comando puede generar varios mensajes de falla, uno por cada intento fallido de escribir en la salida estándar.
Ejemplos:
cd >&0
echo Hello >&0
:: This generates 2 error messages, one for the time,
:: and another for the subsequent empty line
time /t >&0
3) La salida falla y el procesamiento por lotes finaliza. Los SETLOCAL activos permanecen vigentes, incluso después de la finalización del lote, si el error ocurre dentro de una subrutina CALLed. En este sentido, se comporta como un error de sintaxis fatal.
Hasta ahora solo he visto un comando exhibir este comportamiento:
dir >&0
Esperaría que el comando DIR genere un mensaje de error para cada intento de línea de salida. Pero parece terminar después de fallar en la primera línea, y el procesamiento por lotes también se cancela.
4) Algunos comandos exhiben múltiples comportamientos.
Ejemplos:
:: This SET command generates an error message for each
:: defined variable (behavior 2)
set >&0
:: But this SET command fails to display the prompt without
:: error message (behavior 1). Note that the echo of user input
:: is written directly to :con. It does not use stdout or stderr.
set "var=prompt" >&0
:: A single PAUSE exhibits both behaviors 1 and 2. The prompt to
:: press a key simply dissapears, and the echo of the user input
:: generates an error. Note that in this case, the echo of user
:: input is written to stdout.
pause >&0