¿Es cierto concluir que existen 4 tipos desalida de flujo¿Podemos hacer referencia a un archivo en Linux, si no queremos que aparezcan en la CLI después de ejecutar su comando?
Posibles referencias a un archivo:
- Toda la salida de flujo
- solo stderr
- Solo salida estándar (incluido el resultado final de la salida estándar).
- stdout y stderr (excluyendo el resultado final de stdout).
Notas:
Un ejemplo para el número 4 podría ser find / -type f -name php.ini 2>/dev/null. Según tengo entendido, con este comando no obtenemos ni stderr ni stdout (aparte delresultado final de stdoutque en este caso es el archivo que buscamos, si lo encontramos).
Respuesta1
Hay dos flujos de salida conectados a cada proceso en un sistema Unix:salida estándar(salida estándar, descriptor de archivo 1) yError estándar(stderr, descriptor de archivo 2). Estos pueden redirigirse independientemente uno del otro.Entrada estándarutiliza el descriptor de archivo 0.
- Para redirigir la salida estándar al archivo
file, utilice>fileo el más explícito1>file. Reemplazarfilepor/dev/nullpara descartar los datos. - Para redirigir el error estándar al archivo
file, utilice2>file. - Para redirigir el error estándar a donde quiera que vaya la salida estándar, utilice
2>&1. - Para redirigir la salida estándar a donde vaya el error estándar, utilice
1>&2.
No existe el concepto de "resultado final" de una secuencia o proceso. Supongo que cualquier cosa que se envíe a la salida estándar puede tomarse como el "resultado" de un proceso, a menos que también envíe datos a algún archivo que abre solo o que tenga otros efectos secundarios (como desvincular un archivo de un directorio, en el caso de rm, o manejar una serie de conexiones de red, en el caso de sshd). Un proceso también devuelve un estado de salida (cero para "éxito" y distinto de cero para "fracaso") que podría verse como "el resultado" de ese proceso, pero esto no está necesariamente relacionado con los flujos de salida del proceso.
Las transmisiones también pueden redirigirse enmodo anexar, lo que significa que si la redirección es a un archivo, ese archivo no se truncará inicialmente y todos los datos de la secuencia se agregarán al final del archivo. Se hace esto usando en >>filelugar de >file.
En la nota de la pregunta, el comando
find / -type f -name php.ini 2>/dev/null
es dado. Esto redirige (descarta)soloError estándar. El flujo de salida estándar no se redirige en absoluto y, por lo tanto, será visible, en su totalidad, en la consola o terminal. Si fuera una parte intermedia de una tubería, el flujo de salida estándar se introduciría en la entrada estándar del siguiente comando en la tubería.
Para concluir, diría que haydos(no cuatro) flujos de salida. Éstos podrán ser redirigidos de forma independiente de diversas formas, incluido el descarte de sus contenidos.
Respuesta2
CadaprocesoPuede utilizar, por convención, tres descriptores de archivos estándar. Estos descriptores de archivos están disponibles como secuencias: stdin, stdouty stderr.
De forma predeterminada, cuando inicia un proceso desde un shell (CLI), el primero se conecta a la entrada de su terminal (o emulador de terminal como xterm) y los otros dos se conectan a la salida de su terminal.
Puede indicarle al shell que los redirija a otro lugar, por ejemplo /dev/null(donde simplemente son absorbidos). Y puedes hacerlo de forma independiente para stdouty stderr. Entonces, para este caso, existen efectivamente cuatro posibilidades:
command
command > /dev/null
command 2> /dev/null
command > /dev/null 2> /dev/null
Pero nada le impide redirigir uno o ambos a otro lugar:
command > /tmp/myout 2> /tmp/myerr
En ese caso, tampoco obtendrá ningún resultado en su terminal, pero podrá leerlo más tarde en los archivos /tmp/myouty /tmp/myerr.
Respuesta3
La situación es más simple y complicada de lo que sugiere su pregunta. Parafraseando lo queKusalanandadice ensu respuesta, hay dos flujos de E/S estándar (convencionales) (descriptores de archivos) que se configuran y utilizan convencionalmente para la salida: stdout (descriptor de archivo 1) y stderr (descriptor de archivo 2). Nuestra pregunta canónica, ¿Cuáles son los operadores de control y redirección del shell?, analiza cómo redirigirlos. Ingenuamente, podemos enumerar cinco combinaciones distintas:
╔══════════════════════════════╦═════════════════════════════════════════════╗
║ ║ stderr ║
║ ╟─────────────────────┬───────────────────────╢
║ ║ default │ ║
║ ║ (same as the shell) │ redirected ║
╠════════╤═════════════════════╬═════════════════════╦═══════════════════════╣
║ │ default ║ ║ ║
║ │ (same as the shell) ║ 1 ║ 2 ║
║ ├─────────────────────╠═════════════════════╬═══════════════════════╣
║ stdout │ ║ ║ 4. redirected ║
║ │ ║ ║ to the same file ║
║ │ redirected ║ 3 ╟───────────────────────╢
║ │ ║ ║ 5. redirected ║
║ │ ║ ║ to different files ║
╚════════╧═════════════════════╩═════════════════════╩═══════════════════════╝
pero si cuenta /dev/nullcomo diferente de un archivo, y el modo de agregar como un caso especial, y el modo de lectura-escritura como diferente del modo de solo escritura, y las canalizaciones como diferentes de los archivos, entonces el número de combinaciones aumenta exponencialmente. Sin embargo, como se ha dicho repetidamente, “el resultado final de stdout” no es una frase estándar de Unix/Linux/bash.
¿Sólo dos?
Las otras respuestas (quizás sabiamente) se limitaron a stdout y stderr (descriptores de archivo 1 y 2). Creo (¿imprudentemente?) que una respuesta completa a esta pregunta debería abordar el hecho de que hay otros descriptores de archivos disponibles: hasta cientos, miles o inclusomás de un millón. Por ejemplo, si ejecuta un comando como diff file1 file2, el diffprograma se abrirá file1y file2, y el kernel probablemente asignará los descriptores de archivo 3 y 4. La diferencia es que solo los descriptores de archivo 0, 1 y 2 están predefinidos. La redirección de descriptores de archivos superiores a 2 se analiza en los siguientes lugares:
- Manual de referencia de Bash: Sección 3.6 Redirecciones
- Guía avanzada de secuencias de comandos Bash: Capítulo 20. Redirección de E/S
- Diferencia entre 2>&-, 2>/dev/null, |&, &>/dev/null y >/dev/null 2>&1(pregunta de U&L)
- ¿Podemos tener más descriptores de archivos además de los habituales stdin/stdout/stderr (0, 1, 2)?(Pregunta de desbordamiento de pila)
Por ejemplo, vea este ejemplo de un descriptor de archivo alto:
$ gato canino.c
#incluir <stdio.h>
#incluir <cadena.h>
principal()
{
int i, len;
char msg[] = "Hola, perro.\n";
len = strlen(mensaje);
i = escribir(17, mensaje, len);
si (yo == len)
printf("¡Éxito! i = %d = len\n", i);
de lo contrario si (i == -1)
{
printf("¡Error! i = %d (len = %d)\n", i, len);
perror("");
}
demás
printf("Resultado inesperado: i = %d, len = %d\n", i, len);
}
$ hacer canino
cc canino.c -o canino
$ ./canino
¡Error! yo = -1 (len = 12)
descriptor de archivo incorrecto
$ ./canino 17> animal
¡Éxito! i = 12 = longitud
$ ls-l
total 70
-rw-r--r-- 1mi nombre de usuario mi nombre de grupo 12 abr 12 13:36 animal
-rwxr-xr-x 1mi nombre de usuario mi nombre de grupo67067 12 de abril 13:36 canino
-rw-r--r-- 1mi nombre de usuario mi nombre de grupo 358 12 de abril 13:36 canino.c
$ gato animal
Hola perro.
Advertencia: no estoy seguro de que lo anterior funcione para todas las versiones de todos los shells.
Los programas estándar no escriben en descriptores de archivos superiores a 2 (a menos que hayan obtenido ese descriptor de archivo del kernel al abrir un archivo, establecer una conexión de red o algo así). Pero, si tiene un programa (no estándar) que hace eso, puede redirigir esos descriptores de archivos.
Y, si tiene apenas 100 descriptores de archivos y considera solo si cada uno de ellos es redirigido o no, tendrá más de un billón (1.000.000.000.000.000.000.000.000.000.000) de combinaciones posibles.