Por que canalizar para o gato apenas para redirecionar? [duplicado]

Question

Ocasionalmente vejo coisas como:

cat file | wc | cat > file2

Por que isso?

Quando os resultados (ou desempenho) serão diferentes (favoravelmente) simplesmente:

cat file | wc > file2

    

Answer 1

cat file | wc | cat > file2

normalmente seriam dois usos inúteis de cat , pois isso é funcionalmente equivalente a:

< file wc > file2

No entanto, pode haver um caso para:

cat file | wc -c

mais de

< file wc -c

Isso é para desativar a otimização que muitas implementações de wc fazem para arquivos regulares.

Para arquivos regulares, o número de bytes no arquivo pode ser obtido sem ter que ler todo o conteúdo do arquivo, mas apenas fazendo uma chamada stat() do sistema e recuperando o tamanho como armazenado no inode. / p>

Agora, pode-se querer que o arquivo seja lido, por exemplo, porque:

• as informações de stat() não são confiáveis (como para alguns arquivos em /proc ou /sys no Linux):

  $ < /sys/class/net/lo/mtu wc -c
  4096
  $ cat /sys/class/net/lo/mtu | wc -c
  6
  

• se deseja verificar a quantidade de dados que podem ser lidos (como no caso de um disco rígido com falha).
• um só quer obter pontos de referência sobre a rapidez com que os dados podem ser lidos.
• se deseja que o conteúdo do arquivo seja armazenado em cache na memória.

Claro, essas são exceções. No caso geral, você prefere usar < file wc -c por motivos de desempenho.

Agora, você pode imaginar cenários ainda mais improvisados onde se pode querer usar: cat file | wc | cat > file2 :

• talvez wc tenha um perfil apparmor ou outro mecanismo de segurança que proíba a leitura ou gravação em arquivos enquanto é permitido por cat (isso seria inédito)
• talvez cat seja capaz de lidar com arquivos grandes (como em > 2 ³² bytes), mas não wc nesse sistema (coisas assim foram necessárias para alguns comandos em alguns sistemas no passado).
• talvez alguém queira que wc (e o primeiro cat ) seja executado e leia o arquivo inteiro (e seja eliminado no último minuto), mesmo que file2 não possa ser aberto para gravação.
• talvez alguém queira ocultar a falha (status de saída) de abrir ou ler o conteúdo de file . Embora wc < file > file2 || : faria mais sentido.
• talvez alguém queira ocultar (da saída de lsof (list open files)) o fato de que ele está recebendo uma contagem de palavras de file ou que ele está armazenando uma contagem de palavras em file2 .

Answer 2

Ambos os exemplos são usos inúteis do gato . Ambos são equivalentes a wc < file1 > file2 . Não há razão para usar cat neste exemplo, a menos que você esteja usando cat file como um substituto temporário para algo que gera dinamicamente a saída.

    

Answer 3

Embora eu não discorde do argumento para dizer que é um 'uso inútil de gato', pode ser razões para isso:

Em muitos idiomas (incluindo o inglês), as palavras e frases são lidas da esquerda para a direita, portanto, mostrar o fluxo de dados da mesma forma pode parecer mais natural para o leitor.

Um motivo para o segundo cat poderia ser mascarar o código de retorno. Tais como:

$ wc < /etc/passw
sh: /etc/passw: Cannot find or open the file.
$ echo $?
1

Considerando que com cat :

$ wc < /etc/passw | cat
sh: /etc/passw: Cannot find or open the file.
$ echo $?
0

Isso pode entrar em jogo se o shell tiver set -e set. No primeiro exemplo, isso abortaria o shell após wc , enquanto no último exemplo continuaria. Obviamente, existem outras maneiras de lidar com isso.

Além disso, a diferença de desempenho das duas declarações (ou seja, com ou sem gato) é insignificante (especialmente nas máquinas atuais) e, se fosse importante, o shell é a linguagem errada a ser usada.

    

Answer 4

Vamos supor que prog bifurque um novo subprocesso e saia, e o novo subprocesso grave algo em sua saída padrão e saia.

Então o comando

prog

não esperará o subprocesso sair e exibirá o prompt do shell no início. Mas o comando

prog | cat

aguardará um EOF no stdin de cat , que efetivamente aguarda a saída do subprocesso. Então, esse é um uso útil de cat .

    

Answer 5

A declaração contém dois usos de cat.

cat file | wc | cat > file2

Claramente, o 2º gato não tem valor, já que

cat file | wc > file2

tem o mesmo significado em todos os shells que já usei.

No entanto

< file wc > file2

não funciona em shells all .

Nem todo mundo está usando um shell de modem em uma versão de modem do unix. (Pode ser uma desvantagem escrever o pipeline de uma maneira que funcione em todos os sistemas que possuem os comandos no pipe instalados, mesmo que alguns desses recursos comuns não sejam fornecidos como padrão com o sistema operacional fornecido.)