bash redirection novamente: questione a dificuldade em compreender 2 comandos semelhantes

Question

Gostaria que alguém explicasse por que o seguinte funciona :

# < /dev/urandom  tr -dc 'a-zA-Z' | head -c 12

Não há '|' antes de tr , mas o seguinte não:

# < /dev/urandom | tr -dc 'a-zA-Z' | head -c 12

(Este é um gerador de senhas simples)

Você também pode explicar como isso é diferente do seguinte:

# gunzip < HP-Fax4-hpcups.ppd.gz cat > ouT1 --- que obviamente falha:

gzip: cat.gz: No such file or directory 

se o '|' é deixado de fora antes do gato; funciona, no entanto, com o '|' (pipe) antes do cat , ou seja,

 # gunzip < HP-Fax4-hpcups.ppd.gz | cat >  ouT1

    

Answer 1

1. O que é < ?

   É o redirecionamento de INPUT do comando para ler FROM de um arquivo. Você pode colocá-lo antes ou depois do comando:

   $ echo abcd > in
   $ cat in
   abcd
   $ cat <in
   abcd
   $ <in cat
   abcd
   

   Em termos simples, o comando lê o arquivo. A diferença entre cat in e cat <in é que < define um redirecionamento de STDIN (entrada padrão) para o processo cat , enquanto em cat in o in é um argumento e o comando cat tem que fazer algo com isso internamente. (Abra, leia, etc.)

2. O que é | ?

   É o redirecionamento para um processo. Só pode seguir um comando:

   $ | cat in
   bash: syntax error near unexpected token '|'
   $ cat in | cat
   abcd
   $ cat in | cat |
   > 
   

   (... e aguardando entrada ...)

3. O que isso faz: < /dev/urandom tr -dc 'a-zA-Z' | head -c 12 ?

   Divida em pedaços menores (comandos com redirecionamentos):

   • < /dev/urandom tr -dc 'a-zA-Z' = tr -dc 'a-zA-Z' e < /dev/urandom

     Significado: faça a tradução para o que você leu em urandom .

   • | - redireciona para um processo usando um canal anônimo

   • head -c 12 - este é o processo que recebe o redirecionamento

   Toda a linha faz sentido, não é?

4. O que é isso: < /dev/urandom | tr -dc 'a-zA-Z' | head -c 12 ?

   Quebra:

   • < /dev/urandom - sem comando e redirecionamento de /dev/urandom
   • | - redireciona para um processo usando um canal anônimo
   • tr -dc 'a-zA-Z' - o processo que recebe o redirecionamento
   • e assim por diante ...

   O que há de errado aqui? Não há comando na primeira "frase".

5. O que é > ?

   Este é um redirecionamento do OUTPUT TO deste arquivo para um arquivo. O mesmo que < , pode ser usado antes ou depois de um comando:

   $ >out echo abcd
   $ cat out
   abcd
   $ echo dcba >tuo
   $ cat tuo
   dcba
   

6. O que é que isto deveria fazer: gunzip < HP-Fax4-hpcups.ppd.gz | cat > ouT1 ?

   Análise:

   • gunzip < HP-Fax4-hpcups.ppd.gz = redirecionar de HP-Fax4-hpcups.ppd.gz para gunzip (deixe gunzip ler este arquivo)
   • | - redireciona a saída para um processo
   • cat > ouT1 = cat é o processo para receber o redirecionamento e, em seguida, sua saída é redirecionada para o arquivo ouT1

   Tudo bem. Todas as peças fazem sentido.

7. O que é isso então: gunzip < HP-Fax4-hpcups.ppd.gz cat > ouT1 ?

   Não tenho 100% de certeza de como isso é interpretado por todas as partes envolvidas aqui, mas especulemos. O erro é este:

   gzip: cat.gz: No such file or directory 
   

   A primeira palavra neste erro é gzip , então sabemos que o gzip foi executado. Também sabemos (pelo menos eu) que os redirecionamentos são definidos pela venda antes que o comando seja interpretado. Então eu analiso dessa maneira:

   • < HP-Fax4-hpcups.ppd.gz - shell define o redirecionamento INPUT do processo para HP-Fax4-hpcups.ppd.gz , ie. o comando a ser executado irá ler este arquivo
   • > ouT1 - o OUTPUT do comando deve ser redirecionado para ouT1

   Até aí tudo bem. O que resta na mesa agora é este: gunzip cat . A interpretação padrão disso é que gunzip é um comando e cat é seu argumento. Portanto, agora gunzip é executado (com os redirecionamentos IN e OUT definidos) e obtém a string cat como seu primeiro argumento. E de alguma forma isso gera o erro:

   gzip: cat.gz: No such file or directory
   

   O que significa, de novo? É gzip dizendo que não é possível encontrar cat.gz . Ele quer fazer algo com ele (provavelmente abri-lo), e não existe tal arquivo ou diretório. Portanto, deve ser uma questão de seus internos porque isso faz com que cat.gz de cat tenha como argumento. Um experimento simples revela que espera que o argumento esteja no formato gzip:

   $ echo asdf > cat.gz
   $ gunzip < in  cat >  ouT1
   
   gzip: cat.gz: not in gzip format
   

   O arquivo in aqui é um arquivo de texto simples, então, portanto, a linha em branco, eu entendo.