Por que não consigo ler / dev / stdout com um editor de texto?

Question

Acabei de começar a aprender como Tudo é um arquivo ^TM no Linux, o que me fez pensar no que aconteceria se eu literalmente lesse / dev / stdout:

$ cat /dev/stdout 
^C
$ tail /dev/stdout 
^C

(O ^C é eu matando o programa depois que ele trava).

Quando eu tento com vim , recebo a mensagem impensável: "/ dev / stdout" não é um arquivo. Suspiro!

Então, o que dá, por que estou recebendo desligamentos ou mensagens de erro quando tento ler esses "arquivos"?

    

Answer 1

why am I getting hangups

Você não está recebendo "restrições" de cat(1) e tail(1) , eles estão apenas bloqueando a leitura. cat(1) aguarda a entrada e imprime assim que vê uma linha completa:

$ cat /dev/stdout
foo
foo
bar
bar

Aqui eu digitei foo Entre bar Digite CTRL - D .

tail(1) aguarda a entrada e imprime apenas quando consegue detectar EOF :

$ tail /dev/stdout
foo
bar
foo
bar

Aqui eu digitei novamente foo Digite bar Digite CTRL - D .

or error messages

O Vim é o único que apresenta um erro. Ele faz isso porque executa stat(2) against /dev/stdout , e acha que não tem o conjunto% bit_de% definido.

S_IFREG é um arquivo, mas não um arquivo regular . De fato, há alguma dança no kernel para dar uma entrada no sistema de arquivos. No Linux:

$ ls -l /dev/stdout
lrwxrwxrwx 1 root root 15 May  8 19:42 /dev/stdout -> /proc/self/fd/1

No OpenBSD:

$ ls -l /dev/stdout
crw-rw-rw-  1 root  wheel   22,   1 May  7 09:05:03 2015 /dev/stdout

No FreeBSD:

$ ls -l /dev/stdout
lrwxr-xr-x  1 root  wheel  4 May  8 21:35 /dev/stdout -> fd/1

$ ls -l /dev/fd/1
crw-rw-rw-  1 root  wheel  0x18 May  8 21:35 /dev/fd/1

    

Answer 2

(Quase) tudo é um arquivo, mas nem tudo é um arquivo regular . Não faz sentido chamar um editor de texto em algo que é um arquivo especial, como um diretório, um soquete de rede, uma porta serial, etc.

O arquivo /dev/stdout pode ser uma de várias coisas dependendo da variante do unix:

• um arquivo "especial", normalmente um dispositivo de caractere;
• um link simbólico "mágico" que aponta para o arquivo que o processo que o acessa abriu neste descritor;
• um link simbólico para um dos itens acima.

Em qualquer caso, abrir /dev/stdout e arquivos semelhantes cria um novo descritor de arquivo associado ao mesmo arquivo que o aplicativo já tem aberto no descritor de arquivo 1. “Saída padrão” significa descritor de arquivo 1 e é apenas uma convenção que este descritor de arquivo é usado para saída - o kernel não se importa.

Quando você executa um programa em um terminal, todos os três descritores padrão (0 = entrada padrão, 1 = saída padrão, 2 = erro padrão) são abertos no dispositivo terminal. A leitura desse dispositivo retorna caracteres digitados pelo usuário e a gravação nesse dispositivo exibe o texto na janela do terminal. (Não há um modo padrão, dado um dispositivo terminal, de ler a saída que é exibida ou de injetar entrada nele).

Quando você executa cat /dev/stdout , isso faz exatamente a mesma coisa que cat /dev/stdin ou cat /dev/stderr , porque esses três descritores de arquivo estão conectados ao mesmo arquivo: ele indica cat para ler do terminal. Isso é o que cat sem argumento também.

Se você executou cat /dev/stdout >foo , então /dev/stdout se referiria ao arquivo foo - esse comando é equivalente a cat foo >foo . Dependendo da implementação do cat , ele pode errar (a versão GNU reclama que “arquivo de entrada é um arquivo de saída”) ou pode não fazer nada porque lê do arquivo foo que está vazio ( >foo apenas truncado). Com uma versão de cat que não detecta esse caso especial, se foo não estiver vazio, cat /dev/stdout >>foo ou o equivalente cat foo >>foo acrescentaria o conteúdo do arquivo a si mesmo indefinidamente.

Quando você executa vim /dev/stdout , ele reclama porque não sabe como editar um terminal (isso simplesmente não faz sentido).

    

Answer 3

cat e tail estão procurando conteúdo opcional seguido por um final de arquivo. /dev/stdout permanece aberto, por isso cat e tail continuam procurando.