Existe uma maneira de limitar a quantidade de arquivos listados em um lscomando?
Eu tenho visto:
ls | head -4
mas para obter headou tailser executado, preciso aguardar o lstérmino da execução e com diretórios com uma quantidade enorme de arquivos que podem levar um tempo considerável.
Desejo executar um lscomando que limite sem usar esse headcomando.
Respostas:
Você tentou
ls -U | head -4
Isso deve pular a classificação, e é provavelmente por isso que lsestá demorando tanto.
ls -Unão lê necessariamente todo o diretório antes de imprimir. Tente strace -e getdents,write ls -U > /dev/nullem um diretório grande, por exemplo.
Se a sua versão do lstiver uma maneira de não classificar arquivos, como -Upara o GNU ls , use-o. Sem opção, lsprimeiro lerá todos os arquivos, depois classificará os nomes e começará a imprimir.
Outra possibilidade é executar find, que imprime nomes à medida que os encontra.
find . -name . -o -prune | head
(observe que, como headestá trabalhando nas linhas , assume que os nomes dos arquivos não contêm caracteres de nova linha).
find(em oposição ao busybox, herança findou GNU ls -U), parece que ele lê todo o diretório antes de começar a imprimir.
Talvez você precise de uma ferramenta que não seja ls?
Por exemplo, Randal Schwartz tem uma entrada de blog sobre o uso perlem diretórios grandes que podem conter algumas dicas sobre como criar algo que atenda às suas necessidades.
Na postagem do blog, Randal explica isso lse findtenta ler todas as entradas do diretório antes de imprimir qualquer, enquanto a perlsolução que ele propõe não.
perlprovavelmente usa readdir(3)like lsou find. readdir(3)nas versões atuais do GNU / Linux, pelo menos, chama a chamada do getdents()sistema com uma contagem grande (que geralmente otimiza o desempenho, reduzindo o número de chamadas do sistema sendo feitas). Mas no seu caso, se você quiser menos arquivos, parece que você precisará ignorar readdire usar BSDs getdirentries(3)ou a getdents(2)chamada do sistema.
Se o desempenho não for a preocupação (como na pergunta que foi fechada como duplicata deste) e você desejar listar os primeiros n arquivos (em oposição às primeiras n linhas da saída de ls) na lista de arquivos ocultos classificados por nome de arquivo, com zsh, você pode usar:
ls -ld -- *([1,4])
para listar os 4 primeiros arquivos. zshainda lerá o conteúdo completo do diretório, mesmo que você não o ordene *(oN[1,4])(observe que ls também classifica essa lista).
Talvez menos seja mais adequado às suas necessidades?
ls /usr/bin | less
Para mim, ele funciona instantaneamente em um laptop de 5 anos com HDD clássico, mas a cabeça é igualmente rápida.
Você pode terminar lessprematuramente com q.
Eu acho que sua suposição sobre a origem do atraso do 1s está errada, mas talvez dependa do seu sabor Unix ou do seu shell, menos ou comando head.
No Linux, com GNU-ls,
ls -R /usr | less
começa a produzir imediatamente para mim, enquanto toda a produção está em execução e em execução - portanto, definitivamente não está concluída, antes que menos sejam iniciadas. Você pode verificar se possui um atraso constante de 1s ou mais, dependendo da saída ou não.
Eu acho que o seu atraso de 1s tem um motivo diferente, talvez o HDD vá dormir e precise de um despertador?
Você também tem um atraso para muito poucos arquivos?
lsresultado. Eu estava procurando uma maneira de si mesmo para limitar a quantidade de resultados.
ls -lrth | tail
ls -lrth | tail -n 10
ls -lrth | grep *.gz | tail
lscomando no bash. Canalizado comandos como grep, head, tailou outros são executadas após als
$ cut -f 1,n filename
fará a tarefa de buscar os primeiros narquivos.
né o número de arquivos que você deseja extrair. o código completo será:
$ ls|cut -f 1,n file
ls | cut -f 1,n filecomando que você sugeriu produziria o primeiro e o enésimo campo em cada linha de texto filee ignoraria completamente a saída de ls. Isso não faz o que o pôster original precisa.