Comprensión de secuencias de archivos y descriptores de archivos

Para un contexto adicional, hice esta pregunta antes, y pensé que entendía las cosas, pero ya no.

Sé que echoignora stdin. Yo sé que stdin, stderry stdoutexisto y, en este contexto, no sé que las "cosas" que no sean éstos existen.

Entonces, si echoignora stdin, ¿de dónde obtiene su entrada? Parece stdin, stdouty stderrno cuentan toda la historia.

— Redirigir
fuente

echoobtiene toda la información que necesita de los argumentos que se le pasan.

— William Pursell

Sí, la historia es mucho más que eso. Un proceso tiene muchas más propiedades que los tres descriptores de archivo. echoobtiene información del argv (argumentos de línea de comando, una de las propiedades del proceso).

— 炸鱼薯条德里克

@ 炸鱼薯条德里克 ¡Gracias! Esto me señaló en la dirección correcta ( visión general de los procesos ). Ahora tengo una mejor idea de todo esto (creo).

— Redireccionar

No estoy seguro de entender la fuente de su confusión, pero tenga en cuenta que en Unix los argumentos de la línea de comandos (el fooy barde echo foo bar) y las cadenas de entorno (el FOO=barde env - FOO=bar printenv) simplemente son copiados por el núcleo en el espacio de direcciones del proceso, donde simplemente se accede como cualquier otra memoria (a través de punteros, etc.); no se pasan como archivos que podrían ser leídos, escritos o mapeados en memoria por el proceso, como lo son los stdin estándar, stdout, stderr o cualquier descriptor de archivo adicional.

Esta no es una ley de la naturaleza, es solo cómo funciona en Unix. Se podría argumentar que esto es arcaico, inconsistente e ineficiente (se hace una copia de todo el entorno para cada proceso, incluso si se ignora todo o la mayor parte).

Se pueden hacer diferentes arreglos: en el plan9 , las cadenas de entorno son en realidad archivos /env(lo que también significa que se pueden compartir entre procesos).

Además, se LD_PRELOADpodría usar un hack en Linux para evitar el límite argv + env al pasar todo a través de un archivo creado con memfd_create.

— Mosvy
fuente

Gracias Mosvy. Eso ayuda. Trataré de explicar por qué estoy un poco confundido. Tenemos el concepto de entrada . Este no es un concepto tecnológico, es solo algo que existe. Cuando se usa un shell, específicamente cuando se ejecuta el comando echo foo bar, esto se ingresa de acuerdo con la definición del diccionario. Ahora los recursos mencionan stdin, stderry stdoutnada más (no se cuenta toda la historia) y no sé cómo dar sentido a esto.

— Redireccionar

Su primer párrafo me dice que no todas las entradas son manejadas por descriptores de archivo. ¿Estoy inferiendo esto correctamente? Sin embargo, ¿no es el caso que todo es un descriptor de archivo ? Entonces, ¿dónde están fooy barhacia dónde van?

— Redireccionar

No, no todo es un archivo . La primera referencia de esa página wiki ya te dijo que ... este no es exactamente el caso. Y de todos modos, la única operación común a todos los descriptores de archivos es close (2): muchos fds no se pueden usar para ninguna E / S (por ejemplo, busque O_PATH en la página de manual de open (2)). Además, un proceso puede tener otras fuentes de entrada (señales + siginfo asociado, leer la memoria de otro proceso con process_vm_readv (2), etc.). Y eso es solo rascar la superficie.

— Mosvy

Creo que esto está más allá de mí en este momento, gracias por toda la ayuda. Pero no dije que todo es un archivo. Dije (pregunté en realidad) si todo es un descriptor de archivo, esa misma fuente dice que lo es (en verdad dice que todo es un FD o un proceso, me perdí esto).

— Redireccionar

En realidad, el enlace de mi comentario es la segunda referencia en la wiki, lo siento ;-)

— mosvy