La respuesta de Anders Lindahl es correcta, pero debe tenerse en cuenta que si está redirigiendo stdout a un archivo y desea redirigir stderr también, debe asegurarse de que 2>&1 se especifique DESPUÉS DE el redireccionamiento 1>, de lo contrario no funcionará.

REM *** WARNING: THIS WILL NOT REDIRECT STDERR TO STDOUT ****
dir 2>&1 > a.txt

Camino correcto: dir > a.txt 2>&1. Para anexar, utilice >>.

Información de fondo de MSKB

Si bien la respuesta aceptada a esta pregunta es correcta, realmente no hace mucho para explicar por qué funciona, y dado que la sintaxis no es inmediatamente clara, hice un rápido Google para averiguar lo que realmente estaba pasando. Con la esperanza de que esta información sea útil para otros, la estoy publicando aquí.

Tomado de Soporte de MS KB 110930.

De MSKB110930

Redirigiendo Mensajes de error desde el Símbolo del sistema: STDERR/STDOUT

Resumen

Cuando se redirige la salida de una aplicación utilizando el símbolo'>', los mensajes de error todavía se imprimen en la pantalla. Esto se debe a que los mensajes de error a menudo se envían al flujo de Error Estándar en lugar del flujo de Salida Estándar.

La salida de una aplicación o comando de consola (Símbolo del sistema) a menudo se envía a dos flujos separados. La salida regular se envía a Salida estándar (STDOUT) y se envían los mensajes de error a Error Estándar (STDERR). Cuando redirige la salida de la consola utilizando el símbolo">", solo redirecciona la salida estándar. Para redirigir STDERR debe especificar '2>' para el símbolo de redirección. Esto selecciona el segundo flujo de salida que es STDERR.

Ejemplo

El comando dir file.xxx (donde file.xxx no existe) mostrará la siguiente salida:

Volume in drive F is Candy Cane Volume Serial Number is 34EC-0876

File Not Found

Si redirige la salida al dispositivo NUL usando dir file.xxx > nul, todavía verá el mensaje de error parte de la salida, así:

File Not Found

Para redirigir (solo) el mensaje de error a NUL, use el siguiente comando:

dir file.xxx 2> nul

O bien, puede redirigir la salida a un lugar y los errores a otro.

dir file.xxx > output.msg 2> output.err

Puede imprimir los errores y la salida estándar en un solo archivo utilizando el comando" &1 " para redirigir la salida de STDERR a STDOUT y luego enviar la salida de STDOUT a un archivo:

dir file.xxx 1> output.msg 2>&1

Para añadir stdout y stderr al archivo de registro general de un script:

dir >> a.txt 2>&1

Correcto, el manejador de archivo 1 para el proceso es STDOUT, redirigido por el 1> o por > (1 se puede omitir, por convención, el intérprete de comandos [cmd.exe] sabe manejar eso). El controlador de archivo 2 es STDERR, redirigido por 2>.

Tenga en cuenta que si está utilizando estos para crear archivos de registro, a menos que esté enviando el outut a _uniquely_named_ (por ejemplo, con fecha y hora) archivos de registro, entonces si ejecuta el mismo proceso dos veces, el redirigido sobrescribirá (reemplazará) el registro anterior file.

El >> (ya sea para STDOUT o STDERR) ANEXARÁ no REEMPLAZARÁ el archivo. Por lo tanto, obtiene un archivo de registro acumulativo, mostrando los resultados de todas las ejecuciones del proceso, generalmente más útil.

Senderos felices...

Acabo de cortar la respuesta como @Anders acaba de publicarla, pero...

Desde mi ayuda de Windows, busqué en la redirección (URL ms-its:C:\WINDOWS\Help\ntcmds.chm::/redirección.htm ).

Es posible que desee leer acerca de >> y | (tubería), también.

No hay, sin embargo, ninguna garantía de que la salida de SDTOUT y STDERR se entrelazan línea por línea en orden oportuno, utilizando la sintaxis POSIX redirect merge.

Si una aplicación utiliza una salida en búfer, puede ocurrir que el texto de una secuencia se inserte en la otra en un límite de búfer, que puede aparecer en el medio de una línea de texto.

Un registrador de salida de consola dedicado (como el "StdOut/StdErr Logger" de 'LoRd MuldeR') puede ser más confiable para tal tarea. Ver: Los proyectos OpenSource de MuldeR