Início / unix / Perguntas / 750523
Accepted
Ed Morton
Asked: 2023-07-04 01:39:25 +0800 CST

O `head` pode ler/consumir mais linhas de entrada do que as saídas?

  • 772

Dados os 3 scripts a seguir:

  1. printf 'a\nb\nc\n' > file && { head -n 1; cat; } < file
  2. printf 'a\nb\nc\n' | { head -n 1; cat; }
  3. { head -n 1; cat; } < <(printf 'a\nb\nc\n')

Eu esperaria que a saída de cada um fosse:

a
b
c

mas para alguns deles, em alguns sistemas, esse não é o caso. Por exemplo, no cygwin:

$ printf 'a\nb\nc\n' > file && { head -n 1; cat; } < file
a
b
c


$ printf 'a\nb\nc\n' | { head -n 1; cat; }
a


$ { head -n 1; cat; } < <(printf 'a\nb\nc\n')
a

O que está causando a saída diferente desses scripts?

Informações adicionais - aparentemente, isso não é apenas um headproblema:

$ printf 'a\nb\nc\n' | { sed '1q'; cat; }
a
$ printf 'a\nb\nc\n' | { awk '1;{exit}'; cat; }
a

$ { sed '1q'; cat; } < <(printf 'a\nb\nc\n')
a
$ { awk '1;{exit}'; cat; } < <(printf 'a\nb\nc\n')
a

Qual seria uma maneira POSIX robusta no shell (ou seja, sem apenas invocar awk ou similar uma vez para fazer tudo) para ler um certo número de linhas da entrada e deixar o restante para um comando diferente, independentemente de a entrada vir de um canal ou um arquivo?

Esta pergunta foi inspirada por comentários em uma resposta para classificar todo o .csv com base no valor de uma determinada coluna .

bash

1 respostas

  1. Best Answer

    head pode ler toda a sua entrada. Ele deve ler pelo menos o que produz (caso contrário, é logicamente impossível de implementar), mas pode ler mais.

    Normalmente pede ao sistema operacional para ler um bufferhead de tamanho fixo (chamando a chamada do sistema ou similar). Em seguida, ele procura caracteres de nova linha nesse buffer e imprime a saída até atingir o número desejado de linhas.read

    Todas as implementações compatíveis com POSIX de headchamada lseekpara redefinir a posição do arquivo na entrada para ficar logo após o final da parte que foi copiada para a saída. No entanto, isso só é possível se o arquivo for pesquisável: isso inclui arquivos comuns, mas não pipes. Se a entrada for um pipe, tudo o que headfoi lido é descartado do pipe e não pode ser colocado de volta. Isso explica a diferença que você observou entre <file(arquivo regular) e |ou <()(pipe).

    A seção relevante da norma acima é:

    Quando um utilitário padrão lê um arquivo de entrada pesquisável e termina sem erro antes de atingir o fim do arquivo, o utilitário deve garantir que o deslocamento do arquivo na descrição do arquivo aberto seja posicionado corretamente logo após o último byte processado pelo utilitário. Para arquivos que não são pesquisáveis, o estado do deslocamento do arquivo na descrição do arquivo aberto para esse arquivo não é especificado. Um aplicativo em conformidade não deve assumir que os três comandos a seguir são equivalentes:

    tail -n +2 file
(sed -n 1q; cat) < file
cat file | (sed -n 1q; cat)

    O segundo comando é equivalente ao primeiro somente quando o arquivo é pesquisável. O terceiro comando deixa o deslocamento do arquivo na descrição do arquivo aberto em um estado não especificado. Outros utilitários, como head, read e sh, têm propriedades semelhantes.

    Algumas headimplementações, como o headbuilt-in de ksh93 (ativado após builtin head, e desde que tenha sido incluído no tempo de compilação) também tentam não deixar o cursor além da última linha que ele tem como saída quando a entrada não é pesquisável, no caso de ksh93, lendo a entrada um byte de cada vez (como os shells readembutidos normalmente fazem) ou espiando o conteúdo dos canais antes de lê-lo no sistema que tem essa possibilidade (não no Linux). Mas esses são a exceção, pois há uma grande penalidade de desempenho.

    • 12

relate perguntas