É verdade que existem 4 tipos de ** saída ** que podemos referenciar a um arquivo no Linux?

2

É verdade que existem 4 tipos de fluxo de saída que podemos referenciar a um arquivo no Linux, se não queremos que apareçam na CLI depois de executar o comando?

Possíveis referências a um arquivo:

  1. Toda a saída de fluxo
  2. Apenas stderr
  3. Apenas stdout (incluindo o resultado final do stdout).
  4. stdout e stderr (excluindo o resultado final do stdout).

Notas:

Um exemplo para o número 4 pode ser find / -type f -name php.ini 2>/dev/null . Pelo que entendi, com este comando nós não obtemos nenhum stderr e nenhum stdout (além do resultado final do stdout que neste caso é o arquivo que procuramos, se ele foi encontrado).

    
por JohnDoea 10.04.2017 / 04:10

3 respostas

4

Existem dois fluxos de saída conectados a cada processo em um sistema Unix: saída padrão (stdout, descritor de arquivo 1) e erro padrão (stderr, descritor de arquivo) 2). Estes podem ser redirecionados independentemente um do outro. Entrada padrão usa o descritor de arquivo 0.

  • Para redirecionar a saída padrão para o arquivo file , use >file ou o mais explícito 1>file . Substitua file por /dev/null para descartar os dados.
  • Para redirecionar o erro padrão para o arquivo file , use 2>file .
  • Para redirecionar o erro padrão para onde a saída padrão estiver indo, use 2>&1 .
  • Para redirecionar a saída padrão para onde quer que o erro padrão esteja acontecendo, use 1>&2 .

Não há conceito "o resultado final" de um fluxo ou processo. Suponho que tudo o que é enviado para saída padrão pode ser tomado como o "resultado" de um processo, a menos que ele também envie dados para algum arquivo que ele abrir sozinho ou tenha outros efeitos colaterais (como desvincular um arquivo de um diretório, no caso de rm ou manipulando várias conexões de rede, no caso de sshd ). Um processo também retorna um status de saída (zero para "sucesso" e diferente de zero para "falha") que pode ser visto como "o resultado" desse processo, mas isso não está necessariamente relacionado aos fluxos de saída do processo. / p>

Os fluxos também podem ser redirecionados no modo de acréscimo , o que significa que, se o redirecionamento for para um arquivo, esse arquivo não será inicialmente truncado e todos os dados no fluxo serão anexados ao final do arquivo. Um faz isso usando >>file em vez de >file .

Na nota da pergunta, o comando

find / -type f -name php.ini 2>/dev/null

é dado. Isso redireciona (descarta) o erro padrão somente . O fluxo de saída padrão não é redirecionado e, portanto, estará visível, na sua totalidade, no console ou no terminal. Se fosse uma parte intermediária de um pipeline, o fluxo de saída padrão seria alimentado na entrada padrão do próximo comando no pipeline.

Então, para concluir, eu diria que existem dois (não quatro) fluxos de saída. Estes podem ser redirecionados independentemente de várias maneiras, o que inclui descartar seu conteúdo.

    
por 10.04.2017 / 13:12
3

Todo processo pode usar, por convenção, três descritores de arquivos padrão. Esses descritores de arquivos estão disponíveis como fluxos: stdin , stdout e stderr .

Por padrão, quando você inicia um processo a partir de um shell (CLI), o primeiro é conectado à entrada do seu terminal (ou emulador de terminal como o xterm) e os outros dois são conectados à saída do terminal.

Você pode instruir o shell para redirecioná-los em outro lugar, por exemplo, para /dev/null (onde eles são engolidos). E você pode fazer isso independentemente para stdout e stderr . Então, para este caso, existem quatro possibilidades:

command 
command > /dev/null
command 2> /dev/null
command > /dev/null 2> /dev/null

Mas nada impede que você redirecione um ou ambos para outro lugar:

command > /tmp/myout 2> /tmp/myerr

Nesse caso, você também não obterá nenhuma saída em seu terminal, mas poderá lê-lo posteriormente nos arquivos /tmp/myout e /tmp/myerr .

    
por 10.04.2017 / 08:08
0

A situação é mais simples e mais complicada do que sua pergunta sugeriria. Parafraseando o que Kusalananda diz em sua resposta , existem dois fluxos de E / S padrão (convencionais) (descritores de arquivo) que são convencionalmente configurados e usados para saída: stdout (descritor de arquivo1) e stderr (descritor de arquivo2). Nossa pergunta canônica, Quais são os operadores de controle e redirecionamento do shell? , discute como redirecioná-los. Naïvely, podemos enumerar cinco combinações 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 ║
╚════════╧═════════════════════╩═════════════════════╩═══════════════════════╝

mas se você contar /dev/null como diferente de um arquivo, e anexar modo como um caso especial, e o modo de leitura / gravação como sendo diferente do modo somente gravação, e pipes como sendo diferentes dos arquivos, então o número de combinações aumenta exponencialmente. No entanto, como afirmado repetidamente, "O resultado final do stdout" não é uma frase normal do Unix / Linux / bash.

Apenas dois?

As outras respostas (talvez sabiamente) se restringiram para stdout e stderr (descritores de arquivo 1 e 2). Eu (imprudentemente?) Acredito que uma resposta completa a esta pergunta deve abordar o fato de que outros descritores de arquivos estão disponíveis - até centenas, milhares ou até mesmo mais de um milhão . Por exemplo, se você executar um comando como diff file1 file2 , o programa diff abrirá file1 e file2 , e o kernel provavelmente irá designar os descritores de arquivo3 e4. A diferença é que apenas os descritores de arquivo 0, 1 e 2 são pré-definidos. Redirecionando descritores de arquivo maiores que 2 é discutido nos seguintes locais:

Por exemplo, veja este exemplo de um descritor de arquivo alto:

$ cat canine.c
#include <stdio.h>
#include <string.h>

main()
{
        int     i, len;
        char    msg[] = "Hello, dog.\n";

        len = strlen(msg);
        i = write(17, msg, len);
        if (i == len)
                printf("Success!  i = %d = len\n", i);
        else if (i == -1)
            {
                printf("Error!  i = %d (len = %d)\n", i, len);
                perror("");
            }
        else
                printf("Unexpected result: i = %d, len = %d\n", i, len);
}

$ make canine
cc     canine.c   -o canine

$ ./canine
Error!  i = -1 (len = 12)
Bad file descriptor

$ ./canine 17> animal
Success!  i = 12 = len

$ ls -l
total 70
-rw-r--r-- 1 myusername mygroupname    12 Apr 12 13:36 animal
-rwxr-xr-x 1 myusername mygroupname 67067 Apr 12 13:36 canine
-rw-r--r-- 1 myusername mygroupname   358 Apr 12 13:36 canine.c

$ cat animal
Hello, dog.

Aviso: não tenho certeza de que o acima funcionará para todas as versões de todos os shells.

Os programas padrão não escrevem para descritores de arquivo superiores a 2 (a menos que tenham esse descritor de arquivo do kernel abrindo um arquivo, fazendo uma conexão de rede, ou algo parecido). Mas, se você tem um programa (não padrão) que faz isso, você pode redirecionar esses descritores de arquivos.

E, se você tiver apenas 100 descritores de arquivos, e você considera apenas se cada um é redirecionado ou não, você tem mais de um não-milhão (1.000.000.000.000.000.000.000.000.000.000) combinações possíveis.

    
por 13.04.2017 / 07:53