C'è un modo per limitare la quantità di file elencati su un lscomando?
Ho visto:
ls | head -4
ma per ottenere heado tailper essere eseguito devo aspettare lsche finisca l'esecuzione, e con le directory con un'enorme quantità di file che può richiedere molto tempo.
Vorrei eseguire un lscomando che limiti senza usare quel headcomando.
Risposte:
Hai provato
ls -U | head -4
Questo dovrebbe saltare l'ordinamento, che è probabilmente il motivo per cui lssta impiegando così tanto tempo.
ls -Unon legge necessariamente l'intera directory prima della stampa. Prova strace -e getdents,write ls -U > /dev/nullad esempio in una directory di grandi dimensioni.
Se la tua versione di lsha un modo per non ordinare i file, come -Uper GNU ls , usalo . Senza alcuna opzione, lsprima leggerà tutti i file, quindi ordinerà i nomi, quindi inizierà a stampare.
Un'altra possibilità è quella di eseguire find, che stampa i nomi come li trova.
find . -name . -o -prune | head
(nota che poiché headsta lavorando su linee , presuppone che i nomi dei file non contengano caratteri di nuova riga).
find(al contrario di busybox o heirloom findo GNU ls -U), sembra che legga l'intera directory prima di iniziare a stampare.
Forse hai bisogno di uno strumento diverso da ls?
Ad esempio, Randal Schwartz ha un post sul blog sull'uso perlin grandi directory che può contenere alcuni suggerimenti su come costruire qualcosa che soddisfi le tue esigenze.
Nel blog distacco Randal spiega che sia lse findtentativo di leggere in tutte le voci di directory prima di stampare qualsiasi, mentre la perlsoluzione che si propone non lo fa.
perlprobabilmente usa readdir(3)like lso find. readdir(3)sulle attuali versioni di GNU / Linux almeno chiama la chiamata di getdents()sistema con un grande conteggio (che in realtà generalmente ottimizza le prestazioni riducendo il numero di chiamate di sistema effettuate). Ma nel tuo caso, se vuoi un numero inferiore di file, sembra che dovresti bypassare readdire utilizzare BSD getdirentries(3)o la getdents(2)chiamata di sistema.
Se la prestazione non è la preoccupazione (come nella domanda che è stata chiusa come duplicata di questa), e si desidera elencare i primi n file (al contrario delle prime n righe dell'output di ls) nell'elenco di non- file nascosti ordinati per nome file, con zsh, è possibile utilizzare:
ls -ld -- *([1,4])
per elencare i primi 4 file. zshleggerà comunque l'intero contenuto della directory, anche se gli dici di non ordinare con *(oN[1,4])(nota che ordina ls anche quell'elenco).
Forse meno è più adatto alle tue esigenze?
ls /usr/bin | less
Per me, funziona istantaneamente su un laptop di 5 anni con un classico HDD, ma la testa è altrettanto veloce.
Puoi terminare lessprematuramente con q.
Immagino che la tua ipotesi sulla fonte del ritardo 1s sia errata, ma forse dipende dal tuo sapore Unix o dalla tua shell, meno o comando head.
Su Linux, con GNU-ls,
ls -R /usr | less
inizia a produrre immediatamente per me, mentre l'intero output è in esecuzione e in esecuzione - quindi non è definitivamente terminato, prima che inizi meno. È possibile verificare, se si ha un ritardo costante di 1s o forse più, a seconda dell'uscita o meno.
Immagino che il tuo ritardo di 1s abbia una ragione diversa, forse l'HDD sta per dormire e ha bisogno di un risveglio?
Hai un tale ritardo anche per pochissimi file?
lsrisultato. Stavo cercando un modo per limitare se stesso i risultati.
ls -lrth | tail
ls -lrth | tail -n 10
ls -lrth | grep *.gz | tail
lscomando su bash. Piped comandi come grep, head, tailo altro vengono eseguite dopo lals
$ cut -f 1,n filename
farà il compito di recuperare i primi nfile.
nè il numero di file che si desidera estrarre. quindi il codice completo sarà:
$ ls|cut -f 1,n file
ls | cut -f 1,n filecomando che hai suggerito avrebbe generato il primo e l'ennesimo campo su ciascuna riga di testo filee ignorerebbe completamente l'output di ls. Questo non fa ciò di cui ha bisogno il poster originale.