[Résolu] Trouver les plus gros répertoires sans fichier flag dedans

Bybeu · Le 12/07/2017, à 00:24

Bonjour
Je me suis mis à trier mes photos en commençant par les plus gros répertoires.
J'ai adopté une arborescence ...Photos/AAAA/AAAAMM [JJ[-JJ]] Blabla

Quand j'ai fini de traiter un répertoire, dedans je

touch 0k

Pour repérer les plus gros répertoire j'utilise

Photos$ du -t-5G|sort -nr|head -50

pour éviter l'affichage des plus gros répertoires AAAA tous vides de fichiers normaux et des plus gros AAAAMM déjà nettoyés, ou mieux (depuis tout à l'heure )

Photos$ du -t-5G ????/??????\ *|sort -nr|head -40

Mais voilà, maintenant que pas mal de répertoires sont nettoyés, leur ordre d'apparition dans la liste n'est plus représentatif de leur statut nettoyé ou pas, donc je m'y perds.
Comment est-ce que je pourrais modifier ma one-liner, pour faire en sorte que ça n'affiche que les répertoires AAAAMM (profondeur cumulée comme maintenant) qui ne contiennent pas le fichier 0k ?

Merci

Dernière modification par Bybeu (Le 17/07/2017, à 10:31)

DonutMan75 · Le 12/07/2017, à 08:40

Salut Bybeu,
une première piste (qui ne fonctionne pas pour l'instant) en passant par la commande find :

$ find . -type d -size +5G -path "????/??????\ *" -exec  ( [ ! -f {}/ok ] && echo "{}" ) \;
bash: erreur de syntaxe près du symbole inattendu « ( »

Bon j'ai une petite erreur et je ne sais pas d'où elle vient... J'ai pas mon guide de référence bash sous la main, mais si quelqu'un a une idée ?

Explications succincte des options :

- type d : on cherche un répertoire...

-size +5G : dont la taille dépasse les 5 Go

-path "????/??????\ *" : (à vérifier, l'option path n'est peut-être pas la plus adaptée) on ne garde que les répertoires dont le chemin suit ce shell pattern (les '\' ne sont par exemple pas interprétés) --> Si y'a que des répertoires comme ça dans ./Photos/ on peut peut être remplacer ça par -maxdepth 2 ?

-exec ( [ ! -f {}/ok ] && echo "{}" ) \;
Lorsqu'on trouve un tel répertoire, on teste s'il ne contient pas le fichier ok avec [ ! -f {}/ok ]
Si c'est le cas, on l'affiche avec echo "{}"

En espérant que ça aide un peu ^^

Si on reste avec ta logique de passer par du, je verrais par exemple un :

$ du -t-5G ????/??????\ *|sort -nr|head -40 | xargs mon_script

Avec mon_script un truc du style (pas testé !) :

#! /bin/sh
 [ ! -f $1/ok ] && du echo "$1"

Mais il faudrait modifier la sortie du du initial pour ne pas se coltiner l'affichage des tailles en première colonne.... Ou alors modifier mon_script pour qu'il ne garde que la deuxième colonne (via awk par exemple...)

Bon courage pour la suite !

A bientôt,

Donut

Bybeu · Le 12/07/2017, à 09:50

Merci gars
J'ai creusé un peu tes idées

Photos$ du ????/??????\ *|sort -nr|head -20|cut -f1 --complement
2016/201608 Kenmare
...
2014/201408 Nasbinals en Aubrac
2014/201406 04 Les Bretons
2015/201505 Le Penne-d'Agenais
...
2014/201406 04 Les Bretons/film
...
2013/201304 Asque
...
2013/201304 Asque/Pascal
Photos$ du ????/??????\ *|sort -nr|head -20|cut -f1 --complement|xargs [ ! -f ${1}/0k ] && du echo ${1}
xargs: guillemets simple non appairés ; par défaut les guillemets sont particuliers à xargs à moins d'utiliser l'option -0
[: « ] » manquant

Dernière modification par Bybeu (Le 12/07/2017, à 09:59)

DonutMan75 · Le 12/07/2017, à 10:44

Hello,
super justement en écrivant ce message je me demandais comment répéter l'argument avec xargs. C'est ${1}, c'est bon à savoir ^^
Déjà, il faudrait que tu protèges tes variables, c'est d'autant plus critique qu'il y a des espaces dans tes noms de répertoires :

$ du ????/??????\ *|sort -nr|head -20|cut -f1 --complement|xargs [ ! -f "${1}"/0k ] && du echo "${1}"
[: missing ]

Ensuite, je dirais qu'il faudrait faire une commande atomique pour indiquer que le &&... fait partie de xargs :

$ du ????/??????\ *|sort -nr|head -20|cut -f1 --complement|xargs ([ ! -f "${1}"/0k ] && du echo "${1}")
-bash: syntax error near unexpected token `['

Mais rien de tout ça ne fait marcher ma commande...
Pour les tests de mon côté, j'ai juste fait ça :

$ mkdir test
$ cd ./test
$ mkdir a b c
$ touch ./b/ok

Et j'ai remplacé tout le début de la commande (jusqu'au xargs donc) par un simple ls...

Quelqu'un a une idée ?

Donut

DonutMan75 · Le 12/07/2017, à 10:57

Ah tiens en fait $1 ne marche pas avec xargs.
Il faut regarder du côté de l'option -I

man xargs a écrit :

-I replace-str
Replace occurrences of replace-str in the initial-arguments with names read from standard input. Also, unquoted blanks do not terminate
input items; instead the separator is the newline character. Implies -x and -L 1.

Je cherche, je cherche...

Donut

Bybeu · Le 12/07/2017, à 11:09

J'ai essayé avec -I{} sans succès et aussi -0 et -n1

Dernière modification par Bybeu (Le 12/07/2017, à 11:09)

DonutMan75 · Le 12/07/2017, à 11:19

Ayé j'ai trouvé !!!
Depuis tout à l'heure mon ls introduisait de la coloration syntaxique qui foutait ensuite le boxon ! C'est résolu en utilisant \ls plutôt que ls

$ \ls -1 | grep -v '\.' | xargs -I {} sh -c '[ ! -f "./{}/ok" ] && echo "Repertoire {} non traite"'

Je n'ai pas réussi à grouper les deux commandes (test et affichage) dans un seul xargs, du coup j'ai invoqué sh avec ma commande combinée....

De ton côté, il reste à remplacer "\ls -1 | grep -v '\.' " par ta commande initiale et le echo final par ce que tu souhaites.

Ceci dit, je ne comprends pas pourquoi précédemment :

il semble impossible d'utiliser de structure de test [ ... ] dans un xargs
il semble impossible de grouper deux commandes via ( cmd1 && cmd2 ) dans un xargs
il semble impossible de grouper deux commandes via ( cmd1 && cmd2 ) suite à un -exec de find

Peut-être est-ce du à des règles internes de xargs / de find ? Si y'a un pro de ces commandes pour éclaircir ces deux points, je suis preneur

Par ailleurs, le man de xargs est assez explicite concernant les répertoires avec espace :

man xargs a écrit :

Because Unix filenames can contain blanks and newlines, this default behaviour is often problematic; filenames containing blanks and/or newlines are incor-
rectly processed by xargs. In these situations it is better to use the -0 option, which prevents such problems. When using this option you will need to en-
sure that the program which produces the input for xargs also uses a null character as a separator. If that program is GNU find for example, the -print0 op-
tion does this for you.

Si ma commande marche avec tes répertoires, c'est cool. Sinon, regarde la piste de l'option -0. Il faudra peut-être basculer sur la solution avec find comme l'indique le man (avec l'option -print0).
Enfin, si rien de tout ça ne fonctionne, est-il envisageable que tu renommes tout tes répertoires en remplaçant les espaces par des underscores '_' ?

A bientôt,

Donut

Dernière modification par DonutMan75 (Le 12/07/2017, à 11:43)

Bybeu · Le 12/07/2017, à 13:45

Merci gars, ça commence à causer, t'es un coriace toi

du ????/??????\ *|sort -nr|head -10|cut -f1 --complement | xargs -I {} sh -c '[ ! -f "./{}/0k" ]  && echo {}'
2013/201305 Portugal
2014/201406 04 Les Bretons

Mais

du ????/??????\ *|sort -nr|head -15|cut -f1 --complement
2016/201608 Kenmare
2016/201608 Ibarra
2013/201307 Sierra de Guara
2015/201505 Praha
2014/201408 Irlande
2013/201305 Portugal
2015/201508 Bardenas
2011/201108 Scotland
2014/201408 Nasbinals en Aubrac
2014/201406 04 Les Bretons
2015/201505 Le Penne-d'Agenais
2014/201411 02 Seville
2014/201405 Gensac
2012/201205 Roma
2014/201406 04 Les Bretons/film

du ????/??????\ *|sort -nr|head -15|cut -f1 --complement | xargs -I {} sh -c '[ ! -f "./{}/0k" ]  && echo {}'
2013/201305 Portugal
xargs: guillemets simple non appairés ; par défaut les guillemets sont particuliers à xargs à moins d'utiliser l'option -0
2014/201406 04 Les Bretons

J'ai des ' dans certains noms. J'ai essayé avec

du -0....|xargs -0 -I{}...

mais c'est pire :

sh: 1: Syntax error: "(" unexpected
sh: 1: Syntax error: "(" unexpected
sh: 1: [: 1600: unexpected operator
sh: 1: [: 10280: unexpected operator
sh: 1: [: 600: unexpected operator
sh: 1: [: 2404: unexpected operator
sh: 1: Syntax error: "(" unexpected
sh: 1: [: 3776: unexpected operator
sh: 1: [: 1732: unexpected operator
sh: 1: Syntax error: "(" unexpected
....

Ça vient de sort qui n'a pas l'air d'aimer des entrées avec des null au lieu des newline

DonutMan75 · Le 12/07/2017, à 14:01

Hello,
Personnellement j'évite dans la mesure du possible de mettre des caractères non standard dans mes noms de fichiers...
Il y a cette discussion ici qui semble être similaire à ton problème : https://stackoverflow.com/questions/143 … heir-names
Peut-être essayer de partir sur la solution via find avec l'option -print0 ?
Une dernière solution serait de ne voyager que dans des endroits qui s'écrivent uniquement avec les 26 lettres de l'alphabet

Bon courage quoiqu'il en soit

Donut

Bybeu · Le 12/07/2017, à 17:01

C'est quand-même du|sort|head|cut qui fait le plus gros du boulot on dirait, et joliment.
Ça serait pas possible d'envoyer ça dans un tableau et faire un

 for i in tab;echo tab[i]; i=i+1; done

?

Merci quand-même

Bybeu · Le 12/07/2017, à 18:19

C'est laid mais ça marche:

./big gros
3154880	2013/201305 Portugal
2244940	2014/201406 04 Les Bretons
2143088	2015/201505 Le Penne-d'Agenais
1878284	2014/201411 02 Seville
1797432	2012/201205 Roma
1647188	2014/201406 04 Les Bretons/film
1512140	2015/201504 Amsterdam
1453780	2011/201106 London city
1335684	2013/201311 St Avit
1295588	2013/201304 Asque
1295344	2015/201508 Ploneour-Lanwern

cat big
#!/bin/bash
du ????/??????\ *|sort -nr|head -20|cut -f1 --complement > gros
while read -r line || [[ -n "$line" ]]; do
if [ ! -f "${line}"/0k ]; then  
    du -s "$line"
fi
done < "$1"

Je vais essayer de fignoler pour qu'il ne me sorte que le plus gros non traité sans avoir à changer le head -N

Hizoka · Le 12/07/2017, à 18:22

Bybeu, c'est plus propre comme boucle

for ((i=0; i <${#tab}; i++));do echo ${tab[${i}]}; done

J'ai pas tout lu mais un truc du genre :

while read line
do
    taille="${line%%[[:space:]]*}"
    dossier="${line#*/}/"
    [[ ! -f "${dossier}/Ok" ]] && echo "${taille} => ${dossier}"
done < <(du -t-5G ????/??????\ * | sort -nr) | head -n 20

ça ne fonctionne pas ?

Dernière modification par Hizoka (Le 12/07/2017, à 18:40)

inbox · Le 12/07/2017, à 19:05

Salut,

Essaye d'utiliser ncdu (disponible dans les dépôts). Dans son man est expliqué comment filtrer les résultats en tenant compte de la taille, par exemple. Il est possible d'exclure des fichiers avec un masque.

Enfin, il y a des touches de fonctions prédéfinies (voir le man "keys").

A+

[EDIT] Un article en français pour plus d'explications.
Un sujet de Moko sur ncdu.

Dernière modification par inbox (Le 12/07/2017, à 19:53)

Bybeu · Le 12/07/2017, à 19:41

Merci les gars, vous êtes super.
En attendant, j'ai réussi à faire marcher mon truc comme ça :

#!/bin/bash
du ????/??????\ *|sort -nr|cut -f1 --complement > gros
rm gras >/dev/null 2>&1
while IFS='' read -r line || [[ -n "$line" ]]; do
if [ ! -f "${line}"/0k ]; then
echo $line >> gras
fi
done < "$1"
gras=`head -1 gras`
IFS=$'\n'
du -s ${gras}

Ça sent pas la classe hein ?
Je vais étudier vos propositions.

Merci encore

Dernière modification par Bybeu (Le 12/07/2017, à 20:49)

Watael · Le 12/07/2017, à 20:29

pas tester :

taille= # il faut renseigner la taille minimale (en octets) des dossiers que tu souhaites traiter.
for d in ????/??????\ */
do
   read s n < <(du -s "$d")
   if test $s -ge $taille && test ! -f "${d}0k"
   then
      echo "dossier à traiter: $d"
      #effectuer le traitement ici
   fi
done

si j'ai bien compris.

Bybeu · Le 12/07/2017, à 21:41

Salut Watel
J'ai essayé ta proposition. La taille n'est pas un critère pour moi, sauf que je voudrait les plus gras en premier, ou mieux seulement le plus gras.
Ta soluce est bien plus jolie je trouve, car pas de fichier intermédiaire écrit sur le disque. Mais on tourne en rond : tant que la sortie sur std se fait depuis l'intérieur de la boucle, pas moyen d'avoir ce tri préalable.
J'ai essayé aussi de rajouter dans la parenthèse read, |sort -rn|head -1 sans succès. Je vais enlever la boucle pour voir...

Merci

Hizoka · Le 12/07/2017, à 21:41

arf... carrément pratique le coup du read !

toujours sympa de te lire watael

Bybeu · Le 12/07/2017, à 22:08

#!/bin/bash
d="????/?????? */"
   read s n < <(du -s ${d}|sort -rn|head -1)
   if test ! -f "${d}0k"
   then
      echo "dossier à traiter: $d"
      #effectuer le traitement ici
        #30l de café
        #30 cartouches de cloppes
        #30h de négo avec Bonnemine pour décider ce qu'on supprime, ce que je retouche, synchro syncthing etc...
fi

./tst
dossier à traiter: ????/?????? */

On dirait que j'ai pas pigé la magie du read
PS: pour le read avec taille, du sort en kilo-octets

Nouvel essai:

#!/bin/bash
d="????/?????? */"
IFS=

   read s n < <(du -s ${d}|sort -rn|head -1)
   if test ! -f "${n}0k"
   then
      echo "dossier à traiter: $s $n"
fi

KO : la sortie est présentable mais le répertoire imprimé contient un fichier 0k (le plus gros de tous, mais déjà traité :? :? :?)

Dernière modification par Bybeu (Le 12/07/2017, à 22:16)

Bybeu · Le 12/07/2017, à 22:25

J'ai trouvé Je suis le roi des glands : si j'avais imprimé la liste des répertoires sur quelques feuilles A4, j'aurais pas perdu une journée à batailler connement. Un stylo, barrer les réps déjà traités, et voilou. Faut vraiment pas me foutre un clavier entre les pattes dis-donc.

Bye les gars. J'espère que ça vous aura profité au moins.
Merci encore

Hizoka · Le 13/07/2017, à 08:45

si c'est bon, ajoute un [Resolu] dans ton titre.

Bybeu · Le 13/07/2017, à 10:26

Il faut encore que je teste avec tes idées Hizoka

Hizoka · Le 13/07/2017, à 12:21

Bybeu => Watael te proposait une boucle, ce que tu n'as pas repris dans ton exemple.

Pas testé :

# Variables
NombreLigne=20 # nombre de ligne à afficher
TailleMax=5 # Taille maximale recherchée en G

# Boucle sur les dossiers renvoyé par du et classé par taille et ne gardera que les 20 premiers echo
while read RetourDU
do
    # Récupération de la taille du dossier
    TailleDossier="${RetourDU%%[[:space:]]*}"

    # Récupération de l'adresse du dossier
    AdresseDossier="${RetourDU#*/}/"

    # Ne renvoie le texte que s'il n'y a pas de fichier Ok dans le dossier
    [[ ! -f "${AdresseDossier}/Ok" ]] && echo "Il faut traiter le dossier ${AdresseDossier} qui fait ${TailleDossier}"
done < <(du -t-${TailleMax}G ????/??????\ * | sort -nr) | head -n ${NombreLigne}

et je reviens sur ton :

for i in tab;echo tab[i]; i=i+1; done

qui se dit en fait :

for x in "${tab[@]}"; do echo $x; done

Dernière modification par Hizoka (Le 13/07/2017, à 18:05)

Bybeu · Le 13/07/2017, à 22:21

Hizoka, j'avais testé son script avant, mais il ne donnait pas le résultat escompté (pas de tri +gras en tête)... j'étais KO et plus assez de neurone pour avoir des idées d'adaptation, à par faire péter la boucle (message #16).
Et ce soir j'avais un bug [résolu-à-la-pince-étau] sur le dossier conducteur de la 206 qui tenait plus en place
Je testerai ton boulot qui a l'air vraiment sympa et au point. Je crois rien qu'à le voir que tu as gagné la bonne binouze bien fraîche de la tombola.
Merci gars

Hizoka · Le 14/07/2017, à 12:40

Quelques corrections et ce que ça donne chez moi (en remplaçant ??????\ * par *):

# Variables
NombreLigne=5 # nombre de ligne à afficher
TailleMax=5 # Taille maximale recherchée en G

# Boucle sur les dossiers renvoyé par du et classé par taille et ne gardera que les 20 premiers echo
while read RetourDU
do
    # Récupération de la taille du dossier
    TailleDossier="${RetourDU%%[[:space:]]*}"

    # Récupération de l'adresse du dossier
    AdresseDossier="/${RetourDU#*/}"

    # Ne renvoie le texte que s'il n'y a pas de fichier Ok dans le dossier
    [[ ! -f "${AdresseDossier}/Ok" ]] && echo "${TailleDossier} : ${AdresseDossier}"
done < <(du -t-${TailleMax}G "${PWD}"/????/??????\ * | sort -nr) | head -n ${NombreLigne}

=> 5139004 : /home/hizoka/Multimedia/Images/Photos/2014/04
=> 4543576 : /home/hizoka/Multimedia/Images/Photos/2010/08
=> 4415312 : /home/hizoka/Multimedia/Images/Photos/2016/08
=> 3568112 : /home/hizoka/Multimedia/Images/Photos/2010/10
=> 2665808 : /home/hizoka/Multimedia/Images/Photos/2011/05

touch "/home/hizoka/Multimedia/Images/Photos/2014/04/Ok"
touch "/home/hizoka/Multimedia/Images/Photos/2016/08/Ok"

# Boucle sur les dossiers renvoyé par du et classé par taille et ne gardera que les 20 premiers echo
while read RetourDU
do
    # Récupération de la taille du dossier
    TailleDossier="${RetourDU%%[[:space:]]*}"

    # Récupération de l'adresse du dossier
    AdresseDossier="/${RetourDU#*/}"

    # Ne renvoie le texte que s'il n'y a pas de fichier Ok dans le dossier
    [[ ! -f "${AdresseDossier}/Ok" ]] && echo "${TailleDossier} : ${AdresseDossier}"
done < <(du -t-${TailleMax}G "${PWD}"/????/??????\ * | sort -nr) | head -n ${NombreLigne}

=> 4543576 : /home/hizoka/Multimedia/Images/Photos/2010/08
=> 3568112 : /home/hizoka/Multimedia/Images/Photos/2010/10
=> 2665808 : /home/hizoka/Multimedia/Images/Photos/2011/05
=> 2237784 : /home/hizoka/Multimedia/Images/Photos/2015/12
=> 2144196 : /home/hizoka/Multimedia/Images/Photos/2014/08

Bybeu · Le 14/07/2017, à 21:34

La classe, et bien expliqué en plus. D'où vient cette limite des 20 premiers echo ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 12/07/2017, à 00:24

[Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#2 Le 12/07/2017, à 08:40

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#3 Le 12/07/2017, à 09:50

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#4 Le 12/07/2017, à 10:44

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#5 Le 12/07/2017, à 10:57

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#6 Le 12/07/2017, à 11:09

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#7 Le 12/07/2017, à 11:19

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#8 Le 12/07/2017, à 13:45

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#9 Le 12/07/2017, à 14:01

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#10 Le 12/07/2017, à 17:01

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#11 Le 12/07/2017, à 18:19

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#12 Le 12/07/2017, à 18:22

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#13 Le 12/07/2017, à 19:05

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#14 Le 12/07/2017, à 19:41

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#15 Le 12/07/2017, à 20:29

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#16 Le 12/07/2017, à 21:41

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#17 Le 12/07/2017, à 21:41

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#18 Le 12/07/2017, à 22:08

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#19 Le 12/07/2017, à 22:25

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#20 Le 13/07/2017, à 08:45

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#21 Le 13/07/2017, à 10:26

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#22 Le 13/07/2017, à 12:21

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#23 Le 13/07/2017, à 22:21

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#24 Le 14/07/2017, à 12:40

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

#25 Le 14/07/2017, à 21:34

Re : [Résolu] Trouver les plus gros répertoires sans fichier flag dedans

Pied de page des forums