No shell, o que significa "2> & 1"?


2285

Em um shell Unix, se eu quiser combinar stderre stdoutentrar no stdoutfluxo para manipulação adicional, posso acrescentar o seguinte no final do meu comando:

2>&1

Então, se eu quiser usar heada saída de g++, posso fazer algo assim:

g++ lots_of_errors 2>&1 | head

para que eu possa ver apenas os primeiros erros.

Eu sempre tenho problemas para lembrar disso, e eu constantemente tenho que procurar, e é principalmente porque eu não entendo completamente a sintaxe desse truque em particular.

Alguém pode acabar com isso e explicar caráter a caráter, o que 2>&1 significa?


50
@ dbr Eu não acho que é apenas uma festa - eu acredito que é uma coisa de bourne shell; portanto, SH, festa, ksh, cinzas, traço, etc
armas

8
Isso faz parte do parágrafo de redirecionamento que descreve shells compatíveis com POSIX, ou shell POSIX, para abreviar. O ksh é um shell POSIX, por exemplo. Veja: pubs.opengroup.org/onlinepubs/009695399/utilities/…
jim mcnamara 04/04

12
Essa construção também funciona no Windows.
Vadzim 22/10

2
É geralmente melhor fazer 2>&1do que 2> / dev / null ;-)
F. Hauri

11
Eu pensei em mencionar que |& é uma abreviação para 2>&1 |se você estiver usando o zsh. Não sei se isso se aplica a outras conchas do tipo bourne ou se é um recurso exclusivo do zsh.
amigos estão dizendo sobre chrixian

Respostas:


2557

O descritor de arquivo 1 é a saída padrão ( stdout).
O descritor de arquivo 2 é o erro padrão ( stderr).

Aqui está uma maneira de lembrar essa construção (embora não seja totalmente precisa): a princípio, 2>1pode parecer uma boa maneira de redirecionar stderrpara stdout. No entanto, ele será realmente interpretado como "redirecionar stderrpara um arquivo chamado 1". &indica que o que segue é um descritor de arquivo e não um nome de arquivo. Assim, a construção torna-se: 2>&1.


281
mas então não deveria ser &2>&1?
Dokaspar

319
@ Dominik: Não, &só é interpretado como "descritor de arquivo" no contexto de redirecionamentos. A escrita command &2>&é analisada como command &e 2>&1, ou seja, "execute commandem segundo plano, execute o comando 2e redirecione seu stdout para seu stdout".
Adam Rosenfield

15
Por que eles escolheram coisas tão misteriosas como essa? Apenas curioso.
CommaToast

81
Mas como você redirecionaria o stderr para um arquivo chamado '& 1'?
Martín Fixman

120
@Martin:2>'&1'

632
echo test > afile.txt

redireciona o stdout para afile.txt. É o mesmo que fazer

echo test 1> afile.txt

Para redirecionar o stderr, você deve:

echo test 2> afile.txt

>& é a sintaxe para redirecionar um fluxo para outro descritor de arquivo - 0 é stdin, 1 é stdout e 2 é stderr.

Você pode redirecionar o stdout para o stderr fazendo o seguinte:

echo test 1>&2 # or echo test >&2

Ou vice-versa:

echo test 2>&1

Portanto, resumindo ... 2>redireciona o stderr para um arquivo (não especificado), acrescentando o &1redirecionamento do stderr ao stdout.


5
isso faz algum sentido para você java ... 2&1 >> data.log, eu vi um colega fazer isso?
Thang Pham

5
@Harry que se parece com qualquer um shell que não é bash, ou um erro de digitação .. cmd 2>&1 >> somefile.loganexará stdout / stderr para um arquivo - é basicamente o mesmo que acima, com >> filea acrescentar
DBR

73
O @dbr cmd 2>&1 >>filenão redireciona o stderr para o arquivo, mas cmd >> file 2>&1sim. Ordem importa. No primeiro caso, stderr é redirecionado para o stdout do shell (possivelmente um tty se o comando for digitado interativamente) e, em seguida, stdout é direcionado para o arquivo. No segundo caso, stdout é direcionado para o arquivo e stderr é direcionado para o mesmo local.
22613 William Pursell

2
Gosto da resposta acima, mas poderia ser um toque mais claro. "2> & 1" redireciona o stderr para o destino do stdout. Portanto, se você tiver algo como "ls -l >> directoryContents 2> & 1" O resultado será um arquivo chamado directoryContents, que terá o conteúdo do diretório de trabalho anexado a ele. Se houver algum erro na execução: as mensagens de erro também serão anexadas ao arquivo directoryContents, à medida que ocorrem.
Max Oeste

1
É 0(or 1,2)>&0(or 1,2)como uma opção para controlar a saída? É o echo test >test.log 2>&1mesmo que echo test 2>&1 >test.log?
Simin Jie

318

Alguns truques sobre redirecionamento

Alguma particularidade de sintaxe sobre isso pode ter comportamentos importantes. Há algumas amostras pouco sobre redirecionamentos, STDERR, STDOUT, e os argumentos ordenação .

1 - Substituindo ou acrescentando?

Redirecionamento> médio do símbolo .

  • >significa enviar para o arquivo completo como um todo , substituindo o destino, se existir (consulte o noclobberrecurso bash no nº 3 mais tarde).
  • >>significa enviar além de acrescentaria ao destino, se existir.

De qualquer forma, o arquivo seria criado se não existir.

2 - A linha de comando do shell depende da ordem !!

Para testar isso, precisamos de um comando simples que envie algo nas duas saídas :

$ ls -ld /tmp /tnt
ls: cannot access /tnt: No such file or directory
drwxrwxrwt 118 root root 196608 Jan  7 11:49 /tmp

$ ls -ld /tmp /tnt >/dev/null
ls: cannot access /tnt: No such file or directory

$ ls -ld /tmp /tnt 2>/dev/null
drwxrwxrwt 118 root root 196608 Jan  7 11:49 /tmp

(Esperando que você não tenha um diretório chamado /tnt, é claro;). Bem, nós temos !!

Então, vamos ver:

$ ls -ld /tmp /tnt >/dev/null
ls: cannot access /tnt: No such file or directory

$ ls -ld /tmp /tnt >/dev/null 2>&1

$ ls -ld /tmp /tnt 2>&1 >/dev/null
ls: cannot access /tnt: No such file or directory

A última linha de comando despeja STDERRno console e parece não ser o comportamento esperado ... Mas ...

Se você deseja fazer alguma pós-filtragem sobre uma saída, a outra ou ambas:

$ ls -ld /tmp /tnt | sed 's/^.*$/<-- & --->/'
ls: cannot access /tnt: No such file or directory
<-- drwxrwxrwt 118 root root 196608 Jan  7 12:02 /tmp --->

$ ls -ld /tmp /tnt 2>&1 | sed 's/^.*$/<-- & --->/'
<-- ls: cannot access /tnt: No such file or directory --->
<-- drwxrwxrwt 118 root root 196608 Jan  7 12:02 /tmp --->

$ ls -ld /tmp /tnt >/dev/null | sed 's/^.*$/<-- & --->/'
ls: cannot access /tnt: No such file or directory

$ ls -ld /tmp /tnt >/dev/null 2>&1 | sed 's/^.*$/<-- & --->/'

$ ls -ld /tmp /tnt 2>&1 >/dev/null | sed 's/^.*$/<-- & --->/'
<-- ls: cannot access /tnt: No such file or directory --->

Observe que a última linha de comando deste parágrafo é exatamente igual à do parágrafo anterior, onde escrevi parece não ser o comportamento esperado (portanto, esse pode até ser um comportamento esperado).

Bem, existem alguns truques sobre redirecionamentos, para realizar operações diferentes nas duas saídas :

$ ( ls -ld /tmp /tnt | sed 's/^/O: /' >&9 ) 9>&2  2>&1  | sed 's/^/E: /'
O: drwxrwxrwt 118 root root 196608 Jan  7 12:13 /tmp
E: ls: cannot access /tnt: No such file or directory

Nota: o &9descritor ocorreria espontaneamente por causa de ) 9>&2.

Adendo: nota! Com a nova versão do( >4.0) há um novo recurso e uma sintaxe mais sexy para fazer esse tipo de coisa:

$ ls -ld /tmp /tnt 2> >(sed 's/^/E: /') > >(sed 's/^/O: /')
O: drwxrwxrwt 17 root root 28672 Nov  5 23:00 /tmp
E: ls: cannot access /tnt: No such file or directory

E, finalmente, para uma formatação de saída em cascata:

$ ((ls -ld /tmp /tnt |sed 's/^/O: /' >&9 ) 2>&1 |sed 's/^/E: /') 9>&1| cat -n
     1  O: drwxrwxrwt 118 root root 196608 Jan  7 12:29 /tmp
     2  E: ls: cannot access /tnt: No such file or directory

Adendo: nota! A mesma nova sintaxe, nos dois sentidos:

$ cat -n <(ls -ld /tmp /tnt 2> >(sed 's/^/E: /') > >(sed 's/^/O: /'))
     1  O: drwxrwxrwt 17 root root 28672 Nov  5 23:00 /tmp
     2  E: ls: cannot access /tnt: No such file or directory

Onde STDOUTpassar por um filtro específico, STDERRpara outro e finalmente as duas saídas mescladas passam por um terceiro filtro de comando.

3 - Uma palavra sobre noclobberopção e >|sintaxe

É sobre substituição :

Embora set -o noclobberinstrua o bash a não substituir nenhum arquivo existente, a >|sintaxe permite passar por esta limitação:

$ testfile=$(mktemp /tmp/testNoClobberDate-XXXXXX)

$ date > $testfile ; cat $testfile
Mon Jan  7 13:18:15 CET 2013

$ date > $testfile ; cat $testfile
Mon Jan  7 13:18:19 CET 2013

$ date > $testfile ; cat $testfile
Mon Jan  7 13:18:21 CET 2013

O arquivo é substituído a cada vez, agora:

$ set -o noclobber

$ date > $testfile ; cat $testfile
bash: /tmp/testNoClobberDate-WW1xi9: cannot overwrite existing file
Mon Jan  7 13:18:21 CET 2013

$ date > $testfile ; cat $testfile
bash: /tmp/testNoClobberDate-WW1xi9: cannot overwrite existing file
Mon Jan  7 13:18:21 CET 2013

Passe com >|:

$ date >| $testfile ; cat $testfile
Mon Jan  7 13:18:58 CET 2013

$ date >| $testfile ; cat $testfile
Mon Jan  7 13:19:01 CET 2013

Desativando esta opção e / ou perguntando se já estiver definido.

$ set -o | grep noclobber
noclobber           on

$ set +o noclobber

$ set -o | grep noclobber
noclobber           off

$ date > $testfile ; cat $testfile
Mon Jan  7 13:24:27 CET 2013

$ rm $testfile

4 - Último truque e mais ...

Para redirecionar as duas saídas de um determinado comando, vemos que uma sintaxe correta pode ser:

$ ls -ld /tmp /tnt >/dev/null 2>&1

para este caso especial , há uma sintaxe de atalho: &>... ou>&

$ ls -ld /tmp /tnt &>/dev/null

$ ls -ld /tmp /tnt >&/dev/null

Nota: se 2>&1existir, também 1>&2é uma sintaxe correta:

$ ls -ld /tmp /tnt 2>/dev/null 1>&2

4b- Agora, vou deixar você pensar em:

$ ls -ld /tmp /tnt 2>&1 1>&2  | sed -e s/^/++/
++/bin/ls: cannot access /tnt: No such file or directory
++drwxrwxrwt 193 root root 196608 Feb  9 11:08 /tmp/

$ ls -ld /tmp /tnt 1>&2 2>&1  | sed -e s/^/++/
/bin/ls: cannot access /tnt: No such file or directory
drwxrwxrwt 193 root root 196608 Feb  9 11:08 /tmp/

4c- Se você estiver interessado em mais informações

Você pode ler o manual fino pressionando:

man -Len -Pless\ +/^REDIRECTION bash

em um console ;-)


5
Leitura complementar: Se você gostou deste, você pode apreciate: Como abuso de redirecionamento poderia dar comportamentos estranhos
F. Hauri


130

Encontrei este post brilhante sobre redirecionamento: Tudo sobre redirecionamentos

Redirecione a saída padrão e o erro padrão para um arquivo

$ command &> arquivo

Essa linha única usa o &>operador para redirecionar os fluxos de saída - stdout e stderr - do comando para o arquivo. Este é o atalho do Bash para redirecionar rapidamente os dois fluxos para o mesmo destino.

Aqui está como é a tabela do descritor de arquivos após o Bash redirecionar os dois fluxos:

Digite a descrição da imagem aqui

Como você pode ver, stdout e stderr agora apontam para file. Portanto, qualquer coisa escrita em stdout e stderr é gravada file.

Existem várias maneiras de redirecionar os dois fluxos para o mesmo destino. Você pode redirecionar cada fluxo um após o outro:

$ command> arquivo 2> & 1

Essa é uma maneira muito mais comum de redirecionar os dois fluxos para um arquivo. O primeiro stdout é redirecionado para o arquivo e, em seguida, stderr é duplicado para ser o mesmo que stdout. Então, os dois fluxos acabam apontando para file.

Quando o Bash vê vários redirecionamentos, ele os processa da esquerda para a direita. Vamos seguir as etapas e ver como isso acontece. Antes de executar qualquer comando, a tabela de descritores de arquivos do Bash é assim:

Digite a descrição da imagem aqui

Agora o Bash processa o primeiro arquivo de redirecionamento. Já vimos isso antes e faz stdout apontar para o arquivo:

Digite a descrição da imagem aqui

O próximo Bash vê o segundo redirecionamento 2> & 1. Não vimos esse redirecionamento antes. Este duplica o descritor de arquivo 2 para ser uma cópia do descritor de arquivo 1 e obtemos:

Digite a descrição da imagem aqui

Ambos os fluxos foram redirecionados para o arquivo.

No entanto, tenha cuidado aqui! Escrita

comando> arquivo 2> & 1

não é o mesmo que escrever:

$ comando 2> & 1> arquivo

A ordem dos redirecionamentos é importante no Bash! Este comando redireciona apenas a saída padrão para o arquivo. O stderr ainda será impresso no terminal. Para entender por que isso acontece, vamos seguir as etapas novamente. Portanto, antes de executar o comando, a tabela do descritor de arquivos é semelhante a esta:

Digite a descrição da imagem aqui

Agora o Bash processa os redirecionamentos da esquerda para a direita. Ele vê primeiro 2> & 1 e duplica stderr para stdout. A tabela do descritor de arquivo se torna:

Digite a descrição da imagem aqui

Agora, o Bash vê o segundo redirecionamento >filee redireciona o stdout para o arquivo:

Digite a descrição da imagem aqui

Você vê o que acontece aqui? Stdout agora aponta para o arquivo, mas o stderr ainda aponta para o terminal! Tudo o que é gravado no stderr ainda é impresso na tela! Portanto, tenha muito, muito cuidado com a ordem dos redirecionamentos!

Observe também que, no Bash, escrever

$ command &> arquivo

é exatamente o mesmo que:

$ command> & arquivo


3
Os dois últimos são diferentes se "comando" terminar em um número, pois isso será considerado como descritor opcional de arquivo para>&
MM

Desenho e explicação muito agradáveis! Você poderia elaborar o que "duplicado" realmente significa? Você mencionou: "Este [2> & 1] duplica o descritor de arquivo 2 para ser uma cópia do descritor de arquivo 1". Parece que o stderr é duplicado para o stdout. Mas se for esse o caso, eu também deveria ver errado /dev/tty0?
HCSF 22/07/19

87

Os números se referem aos descritores de arquivo (fd).

  • Zero é stdin
  • Um é stdout
  • Dois é stderr

2>&1 redireciona o fd 2 para 1.

Isso funciona para qualquer número de descritores de arquivo, se o programa os usar.

Você pode ver /usr/include/unistd.hse os esquece:

/* Standard file descriptors.  */
#define STDIN_FILENO    0   /* Standard input.  */
#define STDOUT_FILENO   1   /* Standard output.  */
#define STDERR_FILENO   2   /* Standard error output.  */

Dito isto, escrevi ferramentas C que usam descritores de arquivo não padrão para log personalizado, para que você não o veja, a menos que o redirecione para um arquivo ou algo assim.


58

Essa construção envia o fluxo de erro padrão ( stderr) para o local atual da saída padrão (stdout ) - esse problema de moeda parece ter sido negligenciado pelas outras respostas.

Você pode redirecionar qualquer identificador de saída para outro usando esse método, mas é usado com mais frequência para canalizar stdoutestderr transmitir em um único fluxo para processamento.

Alguns exemplos são:

# Look for ERROR string in both stdout and stderr.
foo 2>&1 | grep ERROR

# Run the less pager without stderr screwing up the output.
foo 2>&1 | less

# Send stdout/err to file (with append) and terminal.
foo 2>&1 |tee /dev/tty >>outfile

# Send stderr to normal location and stdout to file.
foo >outfile1 2>&1 >outfile2

Observe que o último não direcionará stderrpara outfile2- ele o redireciona para o que stdoutera quando o argumento foi encontrado ( outfile1) e, em seguida, redireciona stdoutpara outfile2.

Isso permite alguns truques bastante sofisticados.


5
Embora esse último exemplo seja muito mais claro como: foo> outfile2 2> outfile1 #
Michael Cramer

3
Mais claro, sim, mas isso não mostraria a natureza "posicional" do redirecionamento. O exemplo é artificial, já que geralmente não é útil fazer isso em uma única linha - o método se torna realmente útil quando diferentes partes são responsáveis ​​pelas diferentes partes do redirecionamento. Por exemplo, quando um script faz um redirecionamento e você o executa com outro bit.
paxdiablo

5
Eu só percebi que o último exemplo também resolve a confusão de longa data que eu tinha a respeito de por que isso: some_program 2>&1 > /dev/nullnão funciona assim: some_program > /dev/null 2>&1.
snapfractalpop

Seu comentário sobre o último exemplo vale suas letras em ouro :-) Nunca pensei que esses argumentos de redirecionamento fossem posicionais ... Acho que isso é muito importante de se saber.
Nils-o-mat

20

2>&1é uma construção de shell POSIX. Aqui está um detalhamento, token por token:


2: Descritor de arquivo de saída " Erro padrão ".

>&: Duplique um operador Descritor de Arquivo de Saída (uma variante do operador Redirecionamento de Saída> ). Dado [x]>&[y], o descritor de arquivo indicado por xé feito para ser uma cópia do descritor de arquivo de saída y.

1" Saída padrão " descritor de arquivo de saída.

A expressão 2>&1copia o descritor de arquivo 1para o local 2, para que qualquer saída gravada em 2("erro padrão") no ambiente de execução vá para o mesmo arquivo originalmente descrito por 1("saída padrão").


Mais explicações:

Descritor de arquivo : "Um número inteiro único e não negativo por processo usado para identificar um arquivo aberto para fins de acesso a arquivos".

Saída / erro padrão : Consulte a seguinte nota na seção Redirecionamento da documentação do shell:

Os arquivos abertos são representados por números decimais começando com zero. O maior valor possível é definido pela implementação; no entanto, todas as implementações devem suportar pelo menos 0 a 9, inclusive, para uso do aplicativo. Esses números são chamados de "descritores de arquivos". Os valores 0, 1 e 2 têm significado especial e usos convencionais e estão implícitos em certas operações de redirecionamento; eles são referidos como entrada padrão, saída padrão e erro padrão, respectivamente. Os programas geralmente recebem sua entrada da entrada padrão e gravam a saída na saída padrão. As mensagens de erro geralmente são escritas com erro padrão. Os operadores de redirecionamento podem ser precedidos por um ou mais dígitos (sem caracteres intermediários permitidos) para designar o número do descritor de arquivo.


19

2 é o erro padrão do console.

1 é a saída padrão do console.

Este é o Unix padrão e o Windows também segue o POSIX.

Por exemplo, quando você corre

perl test.pl 2>&1

o erro padrão é redirecionado para a saída padrão, para que você possa ver as duas saídas juntas:

perl test.pl > debug.log 2>&1

Após a execução, você pode ver toda a saída, incluindo erros, no debug.log.

perl test.pl 1>out.log 2>err.log

Em seguida, a saída padrão vai para out.log e o erro padrão para err.log.

Eu sugiro que você tente entender isso.


A segunda amostra está errado: como ordem de precedência STDERR é redirecionado para STDOUT , única padrão STDOUT serão gravados debug.log (não STDERR ) ver a minha resposta (o parágrafo # 2)! Para garantir que ambos sejam redirecionados para o mesmo arquivo, você deve inverter as diretivas de redirecionamento:perl test.pl > debug.log 2>&1
F. Hauri

16

Para responder sua pergunta: Pega qualquer saída de erro (normalmente enviada ao stderr) e grava-a na saída padrão (stdout).

Isso é útil com, por exemplo, 'more' quando você precisa de paginação para toda a saída. Alguns programas, como imprimir informações de uso no stderr.

Para ajudá-lo a lembrar

  • 1 = saída padrão (onde os programas imprimem saída normal)
  • 2 = erro padrão (onde os programas imprimem erros)

"2> & 1" simplesmente aponta tudo enviado para stderr, para stdout.

Também recomendo a leitura deste post sobre o redirecionamento de erro, onde este assunto é abordado em todos os detalhes.


11

Do ponto de vista de um programador, significa exatamente isso:

dup2(1, 2);

Veja a página do manual .

Entender que 2>&1é uma cópia também explica por que ...

command >file 2>&1

... não é o mesmo que ...

command 2>&1 >file

O primeiro enviará os dois fluxos para file, enquanto o segundo enviará erros para stdoute a saída comum para file.


9

Achei isso muito útil se você é iniciante, leia isso

Atualização:
No sistema Linux ou Unix, existem dois locais onde os programas enviam a saída para: Saída padrão (stdout) e Erro padrão (stderr) . Você pode redirecionar essas saídas para qualquer arquivo.

Como se você fizer isso

ls -a > output.txt

Nada será impresso no console. Toda a saída (stdout) é redirecionada para o arquivo de saída.

E se você tentar imprimir o conteúdo de qualquer arquivo que não saia significa que a saída será um erro como se você imprimir test.txt que não estiver presente no diretório atual A

cat test.txt > error.txt

saída será

cat: test.txt :No such file or directory

Mas o arquivo error.txt estará vazio porque redirecionamos o stdout para um arquivo não stderr.

portanto, precisamos do descritor de arquivo (um descritor de arquivo nada mais é que um número inteiro positivo que representa um arquivo aberto. Você pode dizer que o descritor é o ID exclusivo do arquivo) para informar ao shell qual tipo de saída estamos enviando para o arquivo. No sistema Unix / Linux 1 é para stdout e 2 para stderr .

agora, se você fizer isso

ls -a 1> output.txt, estará enviando a saída padrão (stdout) para o output.txt.

e se você fizer isso

cat test.txt 2> error.txtsignifica que está enviando erro padrão (stderr) para error.txt.

&1é usado para referenciar o valor do descritor de arquivo 1 (stdout).

Agora, o ponto 2>&1significa "Redirecionar o stderr para o mesmo local em que estamos redirecionando o stdout"

Agora você pode fazer isso

cat maybefile.txt > output.txt 2>&1

a saída padrão (stdout) e o erro padrão (stderr) serão redirecionados para output.txt.

Agradecimentos a Ondrej K. por apontar


1
As respostas apenas para links são problemáticas. O link pode se tornar extinto, tornando a resposta inútil. Você sempre deve incluir detalhes suficientes na resposta em si.
Ondrej K.

7

Pessoas, lembre-se sempre paxdiablo dica 's sobre a atual localização do alvo redirecionamento ... Ele é importante.

Meu mnemônico pessoal para o 2>&1operador é este:

  • Pense &no significado 'and'ou 'add'(o personagem é um ampere - e , não é?)
  • Então, torna-se: 'redirecione 2(stderr) para onde 1(stdout) já está / atualmente e adicione os dois fluxos' .

O mesmo mnemônico também funciona para o outro redirecionamento usado com frequência 1>&2:

  • Pense em &significado andouadd ... (você entendeu o e comercial, não é?)
  • Então, torna-se: 'redirecione 1(stdout) para onde 2(stderr) já está / atualmente e adicione os dois fluxos' .

E lembre-se sempre: você precisa ler cadeias de redirecionamentos 'do final', da direita para a esquerda ( não da esquerda para a direita).


7

Redirecionando Entrada

O redirecionamento de entrada faz com que o arquivo cujo nome resulta da expansão da palavra seja aberto para leitura no descritor de arquivo n ou na entrada padrão (descritor de arquivo 0) se n não for especificado.

O formato geral para redirecionar a entrada é:

[n]<word

Redirecionando a saída

O redirecionamento de saída faz com que o arquivo cujo nome resulta da expansão da palavra seja aberto para gravação no descritor de arquivo n ou na saída padrão (descritor de arquivo 1) se n não for especificado. Se o arquivo não existir, ele será criado; se existir, será truncado para tamanho zero.

O formato geral para redirecionar a saída é:

[n]>word

Movendo descritores de arquivo

O operador de redirecionamento,

[n]<&digit-

move o dígito do descritor de arquivo para o descritor de arquivo n ou a entrada padrão (descritor de arquivo 0) se n não for especificado. dígito é fechado depois de duplicado para n.

Da mesma forma, o operador de redirecionamento

[n]>&digit-

move o dígito do descritor de arquivo para o descritor de arquivo n ou a saída padrão (descritor de arquivo 1) se n não for especificado.

Ref:

man bash

Digite /^REDIRECTpara localizar noredirection seção e saiba mais ...

Uma versão online está aqui: 3.6 Redirecionamentos

PS:

Muitas vezes, manera a ferramenta poderosa para aprender Linux.


6

Desde que /foonão exista no seu sistema e exista /tmp

$ ls -l /tmp /foo

imprimirá o conteúdo /tmpe imprimirá uma mensagem de erro para/foo

$ ls -l /tmp /foo > /dev/null

irá enviar o conteúdo de /tmppara /dev/nulle imprimir uma mensagem de erro para/foo

$ ls -l /tmp /foo 1> /dev/null

fará exatamente o mesmo (observe o 1 )

$ ls -l /tmp /foo 2> /dev/null

imprimirá o conteúdo /tmpe enviará a mensagem de erro para/dev/null

$ ls -l /tmp /foo 1> /dev/null 2> /dev/null

enviará a listagem e a mensagem de erro para /dev/null

$ ls -l /tmp /foo > /dev/null 2> &1

é taquigrafia


5

É como passar o erro ao stdout ou ao terminal.

Ou seja, cmdnão é um comando:

$cmd 2>filename
cat filename

command not found

O erro é enviado para o arquivo assim:

2>&1

Erro padrão é enviado para o terminal.


1

0 para entrada, 1 para stdout e 2 para stderr.

Uma dica : somecmd >1.txt 2>&1está correto, enquanto somecmd 2>&1 >1.txtestá totalmente errado, sem efeito!


1

unix_commands 2>&1

Isso é usado para imprimir erros no terminal.

A seguir, ilustra o processo

  • Quando erros são produzidos, eles são gravados no endereço de memória de erro padrão &2"buffer", a partir do qual o fluxo de erros padrão faz 2referência.
  • Quando a saída é produzida, ela é gravada no endereço de memória de saída padrão &1"buffer", a partir do qual o fluxo de saída padrão faz 1referência.

Portanto, pegue o unix_commandsfluxo de erros padrão 2e redirecione >o fluxo (de erros) para o endereço da memória de saída padrão &1, para que eles sejam transmitidos para o terminal e impressos.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.