¿Hay alguna forma de limitar la cantidad de archivos listados en un lscomando?
He visto:
ls | head -4
pero para obtener heado tailser ejecutado necesito esperar a lsque termine la ejecución, y con directorios con una enorme cantidad de archivos que pueden llevar un tiempo considerable.
Deseo ejecutar un lscomando que limite sin usar ese headcomando.
Respuestas:
Has probado
ls -U | head -4
Esto debería omitir la clasificación, lo que probablemente sea la razón por la lsque tarda tanto.
ls -Uno necesariamente lee todo el directorio antes de imprimir. Pruebe strace -e getdents,write ls -U > /dev/nullen un directorio grande, por ejemplo.
Si su versión de lstiene una manera de no ordenar archivos, como -Upara GNU ls , úselo . Sin ninguna opción, lsprimero leerá todos los archivos, luego ordenará los nombres y luego comenzará a imprimir.
Otra posibilidad es ejecutar find, que imprime los nombres a medida que los encuentra.
find . -name . -o -prune | head
(tenga en cuenta que, dado que headestá trabajando en líneas , se supone que los nombres de archivo no contienen caracteres de nueva línea).
find(a diferencia de busybox o heirloom findo GNU ls -U), parece que lee todo el directorio antes de comenzar a imprimir.
¿Quizás necesita otra herramienta que no sea ls?
Por ejemplo, Randal Schwartz tiene una entrada de blog sobre el uso perlen directorios grandes que puede contener algunos consejos sobre cómo construir algo que satisfaga sus necesidades.
En la publicación del blog, Randal explica eso lse findintenta leer todas las entradas del directorio antes de imprimir, mientras que la perlsolución que propone no lo hace.
perlprobablemente usa readdir(3)like lso find. readdir(3)en las versiones actuales de GNU / Linux, al menos llama a la llamada del getdents()sistema con un gran recuento (que en realidad optimiza el rendimiento al reducir la cantidad de llamadas al sistema que se realizan). Pero en su caso, si desea menos archivos, parece que tendría que omitir readdiry utilizar BSD getdirentries(3)o la getdents(2)llamada del sistema en su lugar.
Si el rendimiento no es la preocupación (como en la pregunta que se cerró como un duplicado de este), y desea enumerar los primeros n archivos (en oposición a las primeras n líneas de la salida de ls) en la lista de archivos ocultos ordenados por nombre de archivo, con zsh, puede usar:
ls -ld -- *([1,4])
para enumerar los primeros 4 archivos. zshsin embargo, seguirá leyendo el contenido completo del directorio, incluso si le dice que no ordene *(oN[1,4])(tenga en cuenta que ls también clasifica esa lista).
¿Quizás menos se adapta mejor a tus necesidades?
ls /usr/bin | less
Para mí, funciona instantáneamente en una computadora portátil de 5 años con HDD clásico, pero la cabeza es igual de rápida.
Puede terminar lessprematuramente con q.
Supongo que su suposición sobre la fuente del retraso de 1 es incorrecta, pero tal vez depende de su sabor de Unix o de su shell, menos o comando principal.
En Linux, con GNU-ls,
ls -R /usr | less
comienza a emitirse inmediatamente para mí, mientras toda la salida se está ejecutando y ejecutando, por lo que definitivamente no está terminada, antes de que comience menos. Puede verificar, si tiene un retraso constante de 1s o tal vez más, dependiendo de la salida o no.
Supongo que el retraso de 1 tiene una razón diferente, ¿tal vez el HDD va a dormir y necesita un despertador?
¿También tiene un retraso para muy pocos archivos?
lsresultado. Estaba buscando una forma de ls para limitar la cantidad de resultados.
ls -lrth | tail
ls -lrth | tail -n 10
ls -lrth | grep *.gz | tail
lscomando en bash. Hilo comandos como grep, head, tailu otras personas se ejecuta después de lals
$ cut -f 1,n filename
hará la tarea de buscar los primeros narchivos.
nes la cantidad de archivos que desea extraer. así que el código completo será:
$ ls|cut -f 1,n file
ls | cut -f 1,n filecomando que sugirió generaría el primer y el enésimo campo en cada línea de texto file, e ignoraría por completo el resultado de ls. Esto no hace lo que necesita el póster original.