Existe-t-il un moyen de limiter le nombre de fichiers répertoriés dans une lscommande?
J'ai vu:
ls | head -4
mais pour obtenir headou tailpour être exécuté, il faut attendre la lsfin de l'exécution, ainsi que pour les répertoires contenant une quantité énorme de fichiers pouvant prendre un temps considérable.
Je souhaite exécuter une lscommande qui limite sans utiliser cette headcommande.
Réponses:
As-tu essayé
ls -U | head -4
Cela devrait éviter le tri, ce qui explique probablement pourquoi cela lsprend si longtemps.
ls -Une lit pas nécessairement tout le répertoire avant impression. Essayez strace -e getdents,write ls -U > /dev/nulldans un grand répertoire par exemple.
Si votre version de lsa un moyen de ne pas trier les fichiers, comme -Upour GNU ls , utilisez-la. Avec aucune option, lstout d'abord lire tous les fichiers, puis trier les noms, puis commence à imprimer.
Une autre possibilité consiste à exécuter find, ce qui permet d’imprimer les noms au fur et à mesure qu’ils les trouvent.
find . -name . -o -prune | head
(notez que depuis headtravaille sur des lignes , cela suppose que les noms de fichiers ne contiennent pas de caractères de nouvelle ligne).
find(par opposition à busybox ou heirloom findou GNU ls -U), il semble que tout le répertoire soit lu avant de commencer à imprimer.
Peut-être avez-vous besoin d'un outil autre que ls?
Par exemple, Randal Schwartz a écrit une entrée de blog sur l’ utilisation perld’annuaires volumineux pouvant contenir des astuces pour créer quelque chose qui réponde à vos besoins.
Dans le blog affichage Randal explique que les deux lset une findtentative de lecture dans toutes les entrées de répertoire avant l' impression de tout, alors que la perlsolution qu'il propose ne fonctionne pas.
perlutilise probablement readdir(3)comme lsou find. readdir(3)sur les versions actuelles de GNU / Linux au moins, l’appel getdents()système est appelé avec un grand nombre (cela optimise en général les performances en réduisant le nombre d’appels système effectués). Mais dans votre cas, si vous voulez moins de fichiers, il semble que vous deviez contourner readdiret utiliser à la place des BSD getdirentries(3)ou l' getdents(2)appel système.
Si les performances ne sont pas la préoccupation (comme dans la question qui a été fermée en tant que duplicata de celle-ci), et que vous souhaitez répertorier les n premiers fichiers (par opposition aux n premières lignes de la sortie de ls) dans la liste des fichiers non fichiers cachés triés par nom de fichier, avec zsh, vous pouvez utiliser:
ls -ld -- *([1,4])
pour lister les 4 premiers fichiers. zshToutefois, même si vous lui dites de ne pas trier *(oN[1,4])(notez que cette liste est ls également triée), le contenu complet du répertoire reste lu .
Peut-être que moins est mieux adapté à vos besoins?
ls /usr/bin | less
Pour moi, cela fonctionne instantanément sur un ordinateur portable de 5 ans avec un disque dur classique, mais la tête est tout aussi rapide.
Vous pouvez terminer lessprématurément avec q.
Je suppose que votre hypothèse sur la source du délai 1s est fausse, mais dépend peut-être de votre saveur Unix ou de votre shell, de moins ou de la commande head.
Sous Linux, avec GNU-ls,
ls -R /usr | less
commence à sortir immédiatement pour moi, pendant que toute la sortie est en cours d'exécution - elle n'est donc définitivement pas terminée, avant que moins commence. Vous pouvez vérifier si vous avez un retard constant de 1 ou peut-être plus, en fonction de la sortie ou non.
Je suppose que votre retard a une raison différente, peut-être que le disque dur va se coucher et a besoin d’un réveil?
Avez-vous un tel délai pour très peu de fichiers aussi?
lsfinal. Je cherchais un moyen de limiter moi-même les résultats.
ls -lrth | tail
ls -lrth | tail -n 10
ls -lrth | grep *.gz | tail
lscommande sur bash. Les canalisations de commandes telles que grep, head, tailou autres sont exécutées après lals
$ cut -f 1,n filename
fera la tâche de récupérer les premiers nfichiers.
nest le nombre de fichiers que vous voulez extraire. code complet sera donc:
$ ls|cut -f 1,n file
ls | cut -f 1,n filecommande que vous avez suggérée afficherait les premier et nième champs de chaque ligne de texte fileet ignorerait complètement la sortie ls. Cela ne fait pas ce dont l'affiche originale a besoin.