De vez en cuando necesito especificar un "camino equivalente" de una de las corrientes de IO estándar ( stdin, stdout, stderr). Como el 99% del tiempo trabajo con Linux, solo prefiero /dev/obtener /dev/stdin, etc., y esto " parece hacer lo correcto". Pero, por un lado, siempre me ha inquietado esa razón (porque, por supuesto, "parece funcionar" hasta que no funciona). Además, no tengo un buen sentido de lo portátil que es esta maniobra.
Entonces tengo algunas preguntas:
En el contexto de Linux, ¿es seguro (sí / no) a equiparar
stdin,stdoutystderrcon/dev/stdin,/dev/stdouty/dev/stderr?En términos más generales, ¿es esta equivalencia "adecuadamente portátil "?
No pude encontrar ninguna referencia POSIX.
Respuestas:
Ha estado disponible en Linux nuevamente en su prehistoria. Es no POSIX, aunque muchas conchas reales (incluyendo AT & T
kshybash) simulará que si no está presente en el sistema operativo; tenga en cuenta que esta simulación solo funciona a nivel de shell (es decir, redirección o parámetro de línea de comando, no como argumento explícito para, por ejemploopen()). Dicho esto, debería estar disponible en la mayoría de los sistemas comerciales de Unix, de una forma u otra (a veces se deletrea/dev/fd/Npara varios enterosN, pero la mayoría de los sistemas con eso proporcionarán enlaces simbólicos como Linux y * BSD).fuente
/dev/std{in,out,err}se enumeran específicamente como parte del estándar POSIX.1-2008 .ashno es compatible/dev/stdoutcon initrd ( git.razvi.ro/… )los
/dev/std{in,out,err}archivos normalmente son solo enlaces simbólicos a/proc/self/fd/{0,1,2}(respectivamente). Como tal, no se gana nada con el uso de métodos definidos por POSIX.Si desea cumplir con POSIX, la mejor manera de hacerlo es utilizar la redirección de salida. La redirección de salida de Shell se define en el estándar POSIX . Además, los números de descriptor de archivo STDIN, STDOUT, STDERR también forman parte de POSIX .
En resumen, cosas como
>&2están garantizadas para trabajar.Sin embargo, una cosa importante a tener en cuenta es que el uso de STDIN, STDOUT y STDERR es subjetivo de cómo se inició el programa. Si el programa se inició con el descriptor de archivo 1 como un controlador abierto para un archivo, entonces su programa solo tiene que aceptarlo. Incluso si tuviera que abrir el programa
/dev/stdout, todo lo que haría sería abrir el descriptor de archivo 1, que todavía apuntará a ese archivo.Si esto es lo que está tratando de evitar, debe abrir el TTY directamente. Normalmente, sin ninguna redirección, STDIN, STDOUT y STDERR son descriptores de archivos abiertos que apuntan al mismo TTY. No hay absolutamente nada más que eso.
fuente
/proc/self/fd/1o/dev/fd/1son parte de POSIX?/dev/std???son solo enlaces simbólicos/proc/self/fden Linux.POSIX 7 dice que son extensiones.
Definiciones básicas , Sección 2.1.1 Requisitos:
Encontrado por grep el HTML POSIX: ¿Dónde está la lista de las funciones API POSIX C?
También bastante extraño, la
uuencodeherramienta da/dev/stdoutun efecto mágico :La documentación del kernel de Linux dice que todos los sistemas deberían tenerlo.
https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/devices.rst
Sin embargo, no pude encontrar dónde se crean esos enlaces simbólicos en el núcleo (¿se proporciona la distribución?).
fuente
/ dev / {stdout, stdin, stderr} funcionan en Bash en estas plataformas:
Pero falla en csh en estos:
fuente
bashes especial, ya que se puede compilar para manejarlo/dev/fd/xsolo para redireccionamientos en sistemas que no tienen/dev/fdUn problema con
/dev/stdouty amigos es que es posible que no tenga permiso para escribirles en determinadas circunstancias. Por ejemplo, me he encontrado con esto al invocar scripts de Nix , e imagino herramientas similares que ejecutan scripts en cárceles / sandboxes / container / VMs / etc. puede encontrar problemas similares.Usar la sintaxis como
1>&2funcionó en estos casos y, dado que sabía que estaría ejecutando en Bash, podría usar la sustitución de procesos para los comandos que esperan nombres de archivo.fuente