L'utilisation du disque de fichiers dont les noms correspondent à une expression régulière, dans Linux?

Ainsi, dans de nombreuses situations, je voulais un moyen de savoir comment beaucoup de mon espace disque est utilisé par quoi, donc je sais à quoi s'en débarrasser, de les convertir dans un autre format, stocker ailleurs (comme les Dvd de données), de les déplacer vers une autre partition, etc. Dans ce cas, je suis à la recherche d'une partition Windows à partir d'un Linux SliTaz un support de démarrage.

Dans la plupart des cas, ce que je veux, c'est la taille des fichiers et des dossiers, et pour que j'utilise basé sur NCurses ncdu:

Mais dans ce cas, je veux un moyen d'obtenir la taille de tous les fichiers correspondant à regex. Un exemple regex pour .bak fichiers:

.*\.bak$

Comment puis-je obtenir de l'information, compte tenu d'un standard de Linux avec le noyau de GNU utilitaires ou BusyBox?

Edit: La sortie est prévu pour être parseable par un script.

InformationsquelleAutor Camilo Martin | 2012-02-28

43

Je suggère quelque chose comme: find . -regex '.*\.bak' -print0 | du --files0-from=- -ch | tail -1

Quelques remarques:
- La -print0 option pour find et --files0-from pour du sont là pour éviter les problèmes avec les espaces dans les noms de fichier
- L'expression régulière est mise en correspondance avec le chemin complet, par exemple ./dir1/subdir2/file.bak, pas seulement file.bak, donc si vous de le modifier, d'en tenir compte
- J'ai utilisé h drapeau du à produire un "lisible" format mais si vous voulez analyser les données en sortie, vous pourriez être mieux avec k (toujours utiliser le kilo-octets)
- Si vous supprimez le tail de commande, vous devrez en plus de voir la taille des fichiers et des répertoires
Sidenote: une belle interface outil pour trouver qui a mangé votre espace disque est FileLight. Il ne fait pas de regexes, mais est très pratique pour trouver des grands répertoires ou fichiers le colmatage de votre disque.
- +1, a l'air cool! Qu'en est -s pour du? Ne peut pas vérifier, mais je crois du pouvez afficher le total, sans la nécessité pour tail. Que FileLight outil de rappel de Gnome Analyseur d'Utilisation des Disques. Pourtant, je trouve la "affichage des détails comme" de l'interface de la ncdu app je l'ai mentionné dans l'OP plus simple, mais la diversité est une bonne chose 🙂 (je l'ai déjà ouvert Analyseur d'Utilisation des Disques pour rendre quelqu'un pense que de celui de la nappe de l'INTERFACE utilisateur que ce que j'étais en train de fixer son PC était plus complexe que ce qu'il était réellement... Ça marche!!! Hehe).
- -s affiche le total pour chaque argument séparément, ici, nous avons plusieurs arguments, donc -c est l'option que nous avons besoin.
- Merci, vérifié, et il fonctionne (mais pas avec BusyBox' du, car il ne prend pas en charge --files0-from, j'ai donc installé coreutils), donc je vais accepter celle-ci, comme il semble inmune terroristes les noms de fichiers.
- Je obtenir un nom de fichier trop long d'erreur (je filtre pour 100k ou plusieurs fichiers)
- Il y a une faille ici. Le trouver comme indiqué comprendra des répertoires. du sera alors total, à la fois pour le répertoire et les fichiers dans le répertoire. Répertoires imbriqués seront comptés plusieurs fois. Je suggère l'utilisation de "type f" dans la sélection.
InformationsquelleAutor Michał Kosmulski
23

du est mon préféré de réponse. Si vous avez un fixe de la structure du système de fichiers, vous pouvez utiliser:
```
du -hc *.bak
```
Si vous avez besoin d'ajouter des sous-dossiers, il suffit d'ajouter:
```
du -hc *.bak **/*.bak **/**/*.bak
```
etc etc

Cependant, ce n'est pas une commande très utile, donc, à l'aide de votre trouver:
```
TOTAL=0;for I in $(find . -name \*.bak); do  TOTAL=$((TOTAL+$(du $I | awk '{print $1}'))); done; echo $TOTAL
```
Que se fera l'écho de la taille totale, en octets de tous les fichiers que vous trouvez.

Espère que ça aide.
- cela ne prend pas en charge les expressions régulières
- Il a le même problème que j'ai constaté sur une autre réponse. Depuis les répertoires peuvent être nommés "*.bak" du permettra à la fois de compter les fichiers dans le répertoire nommé .bak ainsi que l'ensemble du répertoire lui-même! Cela va entraîner une surestimation et un double compte (ou pire, si vous avez imbriqués .bak répertoires).
InformationsquelleAutor MaddHacker
3

Exécuter ce dans un Bourne Shell pour déclarer une fonction qui calcule la somme des tailles de tous les fichiers correspondant à regex modèle dans le répertoire courant:
```
sizeofregex() { IFS=$'\n'; for x in $(find . -regex "$1" 2> /dev/null); do du -sk "$x" | cut -f1; done | awk '{s+=$1} END {print s}' | sed 's/^$/0/'; unset IFS; }
```
(Sinon, vous pouvez le mettre dans un script.)

Utilisation:
```
cd /where/to/look
sizeofregex 'myregex'
```
Le résultat sera un nombre (en Ko), y compris 0 (si il n'existe pas de fichiers correspondant à regex).

Si vous ne voulez pas de regarder dans d'autres systèmes de fichiers (dites que vous voulez un look pour tous les .so fichiers sous /, qui est un montage de /dev/sda1, mais pas sous /home, qui est un montage de /dev/sdb1, ajouter un -xdev paramètre find dans la fonction ci-dessus.
- Vous ne devriez pas effectuer une itération sur de trouver la sortie à l'aide d'une boucle for. Ce sera briser si un fichier comporte des espaces. Utiliser find -exec. Aussi, la coupe et la sed ne serait pas nécessaire pour le format de sortie. awk peut tout faire.
- Je suis désolé, j'ai oublié quelque chose, je vais le mettre à jour. Fait.
- Encore assez hackish même avec IFS ensemble. Quel est le problème avec l'aide de find-exec?
- J'ai toujours utilisé des IFS=$'\n' pour des listes de lecture, donc, je suis juste habitué 😛 Mais dites vous que awk peut tout faire - je viens de gratter des awk surface, donc si vous pouviez poster un moyen de le faire avec awk, et c'est moins hacky, je vais l'accepter 🙂 je voulais juste quelque chose qui a travaillé et m'a fallu un peu de temps pour rattraper cette fonction, j'ai donc pensé que je devais le partager. Il fonctionne de façon acceptable assez rapide pour moi en fait, mais si il ya une meilleure façon, je suis tout à fait pour. Si Ce n'était pas pour un script, ~1 min. disque dur pourrait être en effet trop lent.
- Ce que vous faites ici est une mauvaise chose, parce que vous êtes en oubliant que les noms de fichiers sous UNIX peut contenir des retours à la ligne. La seule refusé de caractère est '\0'. Lecture recommandée : mywiki.wooledge.org/ParsingLs (il s'agit de ls, mais ne vous laissez pas berner par elle : vous êtes dans le même piège)
- du -sk build/ bin/ | awk '{s+=$1} END { if (s ~ /[0-9]+/) { print s; } else print "0"; }'. awk peut normalement faire le travail de coupe, mais votre cas de coupe n'est pas nécessaire de toute façon.
- Eh bien, je ne savais plus sur Unix' indigne de soutien des retours à la ligne dans les noms de fichiers (ce qui est vraiment dommage), mais seulement les terroristes de mettre des retours à la ligne dans leur nom de fichier (sans tenir compte du fait que je suis moi-même de la visite d'une partition Windows, et tout en NTFS permettrait une telle chose par lui-même, Windows ne sera pas.). Sinon, +1 pour le heads-up et un joli extrait de code, mais c'est juste l'obtention de la somme d'un couple de dossiers de tailles. Si vous connaissez une manière qui prend la regex idée en compte, et l'afficher comme une réponse, je vais l'accepter 🙂
- Par la manière, je pense que la version de busybox sh's en lecture n'accepte pas NUL délimiteurs. man read me donne ceci. 🙁 Encore, je pourrais obtenir le standard des paquets GNU.
InformationsquelleAutor Camilo Martin
3

Les solutions précédentes ne fonctionnent pas correctement pour moi (j'ai eu des ennuis de tuyauterie du), mais la suite a très bien fonctionné:
```
find path/to/directory -iregex ".*\.bak$" -exec du -csh '{}' + | tail -1
```
La iregex option est une expression régulière insensible à la casse. Utilisation regex si vous voulez qu'il soit sensible à la casse.

Si vous n'êtes pas à l'aise avec les expressions régulières, vous pouvez utiliser le iname ou name drapeaux (le premier étant pas sensible à la casse):
```
find path/to/directory -iname "*.bak" -exec du -csh '{}' + | tail -1
```
Dans le cas où vous voulez que la taille de chaque match (plutôt que de simplement le total combiné), il suffit de laisser les canalisations de la queue de commande:
```
find path/to/directory -iname "*.bak" -exec du -csh '{}' +
```
Ces approches éviter le sous-répertoire problème dans @MaddHackers réponse.

Espère que cela aide les autres dans la même situation (dans mon cas, trouver la taille de toutes les DLL dans un .NET solution).
- Il convient de noter que + signifie find vais essayer d'appeler le du commande aussi peu que possible, en ajoutant le plus de coups possible pour un seul du appel, cependant, en raison des limitations du système (par ex. max. pas de. de permis d'arguments), il peut ne pas être possible d'ajouter tous les coups à un seul du appel, puis il se divise, à travers de nombreux appels, ce qui va causer un résultat incorrect.
- Oh, et vous avez oublié de citer *.bak. Dans votre exemple, le shell de la développer, mais vous voulez find pour la développer, de sorte que vous devez utiliser "*.bak". Je vais corriger pour vous.
InformationsquelleAutor ben.snape
1

Si vous êtes OK avec glob-modèles et vous êtes seulement intéressés dans le répertoire courant:
```
stat -c "%s" *.bak | awk '{sum += $1} END {print sum}'
```
ou
```
sum=0
while read size; do (( sum += size )); done < <(stat -c "%s" *.bak)
echo $sum
```
La %s directive stat donne octets pas de kilo-octets.

Si vous voulez descendre dans les sous-répertoires, avec bash, version 4, vous pouvez shopt -s globstar et utiliser le modèle **/*.bak
- +1 - version 4 est la "récente" de la version qui est nécessaire.
- Donc, avec Bash 4, **/*.bak moyens .bak fichiers sur n'importe quel sous-répertoire? c'est à dire, pas un seul répertoire ci-dessous?
- correct.
- Dommage, ça ne fonctionne pas en Bash 4.2 pour moi. Voir cette image. Il va seulement un dossier ci-dessous, comme si **/*.ext était */*.ext.
- avez-vous shopt -s globstar? Essayez echo $BASH_VERSION pour voir quelle est la version actuelle de votre shell. Cela fonctionne pour moi: mkdir -p a/b/c/d; touch a/b/c/d/file.txt; ls **/*txt
- donne-moi 4.2.0(2)-release. Après avoir fait shopt -s globstar comme vous l'avez mentionné, il travaille dans de petites structures de dossier, mais si je l'ai essayer sur /, l'utilisation du PROCESSEUR passe de 100%, et après une couple de minutes bash est tué. Je ne sais pas pourquoi, peut-être que c'est parce que c'est une VM sur 256 mo de RAM (bien, sur cette lumière distro il peut naviguer sur le web et avec qui), mais encore, semble trop peu fiable.
- ce n'est probablement pas aussi efficacement mis en œuvre comme find, mais êtes-vous vraiment de l'exploration de votre totalité du système de fichiers pour les fichiers?
- Pas ce système de fichiers est /, mais d'un autre, alors oui, j'en ai besoin pour ne pas mourir ou de fuite de mémoire si elle est utilisée dans la racine d'une partition. Comme une note de côté, j'ai toujours trouvé find TELLEMENT supérieur à Windows (non indexées) fonction de recherche... je ne comprends pas pourquoi Linux scanne un lecteur NTFS plus rapide que Windows. Et avec regexes, n'en est pas moins!
InformationsquelleAutor glenn jackman
1

La accepté de répondre suggère d'utiliser des
```
find . -regex '.*\.bak' -print0 | du --files0-from=- -ch | tail -1
```
mais cela ne fonctionne pas sur mon système du ne sais pas --files-0-from option sur mon système. Seulement GNU du sait que l'option, ce n'est ni une partie de la Norme POSIX (de sorte que vous ne trouverez pas dans FreeBSD ou macOS), ni que vous trouverez sur BusyBox basée sur les systèmes Linux (par exemple, la plupart des systèmes Linux embarqué) ou tout autre système Linux qui n'utilise pas la GNU du version.

Puis, il y a une réponse, ce qui suggère d'utiliser:
```
find path/to/directory -iregex .*\.bak$ -exec du -csh '{}' + | tail -1
```
Cette solution permettra de travailler aussi longtemps qu'il n'y a pas trop de fichiers trouvés, comme + signifie que find vais essayer d'appel du avec le plus de coups possible en un seul appel, cependant, il pourrait y avoir un nombre maximal d'arguments (N) un système prend en charge et s'il y a plus de hits que cette valeur, find appellera du plusieurs fois, le fractionnement de la frappe en groupes plus petit que ou égal à N éléments et en ce cas, le résultat sera mauvais et de ne montrer de la taille de la dernière du appel.

Enfin il n'y est une réponse à l'aide de stat et awk, ce qui est une bonne façon de le faire, mais elle s'appuie sur la coquille d'expansion d'une façon que seul Bash 4.x ou versions ultérieures prennent en charge. Il ne fonctionnera pas avec les versions plus anciennes et si cela fonctionne avec d'autres shells est imprévisible.

Une POSIX sont conformes solution (qui fonctionne sur Linux, macOS et toutes les variantes BSD), qui ne souffre d'aucune limitation et qui va sûrement travailler avec tous les shell serait:
```
find . -regex '.*\.bak' -exec stat -f "%z" {} \; | awk '{s += $1} END {print s}'
```
- C'est une excellente écriture-up, +1 - la constatation au sujet de l'argument de comptage limitation est particulièrement important car il peut donner de mauvais résultats et lecteur de quelqu'un fou jusqu'à ce qu'il figure it out.
InformationsquelleAutor Mecki

Vous devez vous connecter pour publier un commentaire.