Quão portáveis são / dev / stdin, / dev / stdout e / dev / stderr?

Question

Ocasionalmente, preciso especificar um "caminho equivalente" de um dos fluxos de E / S padrão ( stdin , stdout , stderr ). Como 99% do tempo que eu trabalho com Linux, eu apenas prefixo /dev/ para obter /dev/stdin , etc., e isso " parece fazer a coisa certa". Mas, por um lado, eu sempre me senti desconfortável com essa lógica (porque, é claro, "parece funcionar" até que não funcione). Além disso, não tenho bom senso de quão portátil é essa manobra.

Então, tenho algumas perguntas:

1. No contexto do Linux, é seguro (sim / não) igualar stdin , stdout e stderr com /dev/stdin , /dev/stdout e /dev/stderr ?

2. Mais geralmente, esta equivalência é "adequadamente portátil "?

Não encontrei referências POSIX.

    

Answer 1

Ele está disponível no Linux de volta à sua pré-história. É não POSIX, embora muitos shells reais (incluindo AT & T ksh e bash ) o simulem, se não estiverem presentes no SO; Observe que essa simulação funciona apenas no nível do shell (por exemplo, redirecionamento ou parâmetro da linha de comando, e não como argumento explícito para, por exemplo, open() ). Dito isto, ele deve estar disponível em mais sistemas Unix comerciais, de uma forma ou de outra (às vezes é escrito /dev/fd/N para vários inteiros N , mas a maioria dos sistemas com isso fornecerá links simbólicos como Linux e * BSD).

    

Answer 2

os arquivos /dev/std{in,out,err} são normalmente apenas links simbólicos para /proc/self/fd/{0,1,2} (respectivamente). Como tal, nada ganha em usar métodos definidos por POSIX.

Se você quiser ser compatível com POSIX, a melhor maneira de fazer isso é usar o redirecionamento de saída. O redirecionamento de saída da shell é definido no padrão POSIX . Além disso, os números descritores de arquivos STDIN, STDOUT e STDERR também fazem parte de POSIX .
Resumindo, coisas como >&2 têm a garantia de funcionar.

Uma coisa importante a notar é que o uso de STDIN, STDOUT e STDERR é subjetivo para como o programa foi iniciado. Se o programa foi iniciado com o descritor de arquivo 1 sendo um identificador aberto para um arquivo, seu programa terá que aceitá-lo. Mesmo se você tivesse que abrir o programa /dev/stdout , tudo o que ele faria seria abrir o descritor de arquivo 1, que ainda vai apontar para esse arquivo.
Se é isso que você está tentando contornar, você precisa abrir o TTY diretamente. Normalmente, sem nenhum redirecionamento, STDIN, STDOUT e STDERR são apenas descritores de arquivos abertos apontando para o mesmo TTY. Não há absolutamente nada mais do que isso.

    

Answer 3

POSIX 7 diz que são extensões.

Definições de base , Seção 2.1.1 Requisitos:

The system may provide non-standard extensions. These are features not required by POSIX.1-2008 and may include, but are not limited to:

[...]

• Additional character special files with special properties (for example,  /dev/stdin, /dev/stdout,  and  /dev/stderr)

Encontrado pelo grepping do HTML POSIX: Onde está a lista das funções da API POSIX C?

Também é bastante estranho, a ferramenta uuencode dá /dev/stdout um efeito mágico :

Specifying a decode_pathname operand of /dev/stdout shall indicate that uudecode is to use standard output.

A documentação do kernel Linux diz que todos os sistemas devem tê-lo.

link

Compulsory links
These links should exist on all systems:
/dev/fd       /proc/self/fd   symbolic   File descriptors
/dev/stdin    fd/0            symbolic   stdin file descriptor
/dev/stdout   fd/1            symbolic   stdout file descriptor
/dev/stderr   fd/2            symbolic   stderr file descriptor

Eu não consegui, no entanto, encontrar onde esses links simbólicos são criados no kernel (distro provided?).

    

Answer 4

Um problema com /dev/stdout e amigos é que você pode não ter permissão para escrever para eles em determinadas circunstâncias. Por exemplo, eu encontrei isso ao invocar scripts do Nix , e imagino ferramentas semelhantes que executam scripts em jails / sandboxes / containers / VMs / etc. pode encontrar problemas semelhantes.

Usando a sintaxe como 1>&2 trabalhada nesses casos e, como sabia que estaria em execução no Bash, eu poderia usar substituição de processos para comandos que esperam nomes de arquivos.

    

Answer 5

/ dev / {stdout, stdin, stderr} funcionam no Bash nessas plataformas:

Linux debian-ppc 3.16.0-4-powerpc #1 Debian 3.16.7-ckt25-1 (2016-03-06) ppc GNU/Linux
HP-UX hpux-ia6 B.11.31 U ia64 0107668277 unlimited-user license
AIX aix7 1 7 000ACFDE4C00
FreeBSD freebsd.polarhome.com 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue Jul  8 06:37:44 UTC 2014     [email protected]:/usr/obj/usr/src/sys/GENERIC  amd64
HP-UX hpux64 B.11.11 U 9000/785 2000587908 unlimited-user license
Darwin macosx 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:26:45 PDT 2012; root:xnu-1699.32.7~1/RELEASE_I386 i386
GNU hurd 0.7 GNU-Mach 1.6-486/Hurd-0.7 i686-AT386 GNU
Linux mandriva.polarhome.com 2.6.33.7-desktop-2mnb #1 SMP Mon Sep 20 18:19:20 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
SunOS openindiana 5.11 oi_148 i86pc i386 i86pc
MirBSD miros.polarhome.com 10 Kv#10uAF-20110818 GENERIC#1330 i386
Linux pidora 3.12.23-2.20140626git25673c3.rpfr20.armv6hl.bcm2708 #1 PREEMPT Fri Jul 4 16:06:10 EDT 2014 armv6l armv6l armv6l GNU/Linux
QNX qnx 6.5.0 2010/07/09-14:44:03EDT x86pc x86
NetBSD netbsd.polarhome.com 6.1.3 NetBSD 6.1.3 (GENERIC) i386
OpenBSD openbsd.polarhome.com 4.9 GENERIC#671 i386
Linux raspbian 3.18.7+ #755 PREEMPT Thu Feb 12 17:14:31 GMT 2015 armv6l GNU/Linux
SCO_SV scosysv 5 6.0.0 i386
Linux redhat.polarhome.com 3.17.4-301.fc21.x86_64 #1 SMP Thu Nov 27 19:09:10 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
SunOS solaris-x86 5.11 11.3 i86pc i386 i86pc
Linux suse 3.4.63-2.44-desktop #1 SMP PREEMPT Wed Oct 2 11:18:32 UTC 2013 (d91a619) x86_64 x86_64 x86_64 GNU/Linux
SunOS solaris 5.10 Generic_147147-26 sun4u sparc SUNW,Sun-Fire-V210
Linux ubuntu 3.13.0-85-generic #129-Ubuntu SMP Thu Mar 17 20:50:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
UnixWare unixware 5 7.1.4 i386 x86at SCO UNIX_SVR5
OSF1 tru64.polarhome.com V5.1 2650 alpha
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02) x86_64 GNU/Linux

Mas falha no csh nestes:

HP-UX hpux-ia6 B.11.31 U ia64 0107668277 unlimited-user license
Linux centos.polarhome.com 2.6.18-409.el5 #1 SMP Tue Mar 15 18:13:50 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
HP-UX hpux64 B.11.11 U 9000/785 2000587908 unlimited-user license
AIX aix7 1 7 000ACFDE4C00
SCO_SV scosysv 5 6.0.0 i386
SunOS solaris-x86 5.11 11.3 i86pc i386 i86pc
SunOS openindiana 5.11 oi_148 i86pc i386 i86pc
SunOS solaris 5.10 Generic_147147-26 sun4u sparc SUNW,Sun-Fire-V210
UnixWare unixware 5 7.1.4 i386 x86at SCO UNIX_SVR5
OSF1 tru64.polarhome.com V5.1 2650 alpha