Améliorer la présentation de la sortie de "find"

Support Debian
#6

Ta terminologie est très vague.
exemple: ‹ ./.cache › est un répertoire, certes caché, mais un répertoire.
.viminfo est un fichier caché, et tu ne dis pas que ça ne ‹ fonctionne pas › ou ‹ mal ›.

Tu dois donc clarifier si tu souhaites afficher/compter les fichiers/répertoires ‹ cachés ›
―――――――――――――
Tu peux réessayer ça:

lsfd() { i=0 ; j=0
  while read L ;do basename $L;((i++));done < <(find -maxdepth 1 -type f |sort)
  printf  "● Nombre de fichiers: $i\n\n"
  while read L ;do printf "$L ";((j++));done < <(/usr/bin/ls -d */)
  printf  "\n● Nombre de répertoires: $j\n"
}
#7

je voudrais juste retrouver les deux listes que j’ai données dans mon 1er message mais sans les ( ./ ) dans la liste des fichiers . Je vais essayer de combiner la 1ère partie de ta commande avec la 2ème partie de la mienne . Ça devrait le faire je pense .

Ça a marché . Avec un alias ça devrait être facilement exploitable .

Merci pour le coup de main .

Il me reste à essayer de comprendre ta commande .

suite :

Tu peux réessayer ça:

effectivement ça marche bien . Ma solution qui combine les deux parties de commande a pour elle de mettre de la couleur pour les répertoires . Donc je vais voir ce que je retiens .

Merci bien .

suite:

Ta terminologie est très vague.

effectivement et je viens d’en prendre conscience en utilisant ls -A au lieu dels car je n’avais pas vraiment réalisé que , par exemple, .thunderbird était un répertoire , je l’avais toujours considéré comme un dossier . Idem pour les autres , inconsciemment d’ailleurs , sans y avoir réfléchi . Et " find -type d " que tu utilises finit de m’en convaincre . De toute façon j’aurais buté sur ce problème dans un 2ème temps car il me fallait bien tenir compte des ces « dossiers » cachés . Même si théoriquement je vois bien la différence entre un "répertoire"et un « dossier » , pratiquement et à l’évidence ça me pose un problème car même debian les considère comme des dossiers ( cf « propriétés » ) . Mais comme aucune option pour ls ou find n’a l’air d’exister pour les dossiers , j’allais buter sur ce point précis … ?

#8

Remarque: attention à la commande ls qui peut-être soit la commande ls, ou un alias.
C’est la raison de l’usage du /usr/bin/ls au lieu de ls du bloc ci-dessus pour garantir un résultat attendu.
Voir type ls

Une fois satisfait, tu copies/colles le bloc fonction dans ton fichier ‹ .bashrc › , et tu auras la fonction ‹ lsfd › disponible à chaque session.

#9

La coloration de ls ne te suffit pas pour ça ? Combiné à ls --group-directories-first peut-être ?

#10

cette commande me donne presque ce que je désire à des fins de comparaison rapide entre mon portable et un ssd externe qui me sert de debian nomade et de sauvegarde . Mais elle sera facile à personnaliser … à condition que j’arrive à séparer physiquepent les 2 groupes . Merci .

Affichées côte à côte sur un même écran d’ordinateur si les listes sont séparées je vois tout de suite les différences éventuelles et pas seulement pour ce répertoire personnel .

#11

Bonjour

Il manquait une paire de guillemets,
ce qui donnerait :

lsfd() { i=0 ; j=0
  while read L ;do basename "$L";((i++));done < <(find -maxdepth 1 -type f |sort)
  printf  "● Nombre de fichiers: $i\n\n"
  while read L ;do printf "$L ";((j++));done < <(/usr/bin/ls -d */)
  printf  "\n● Nombre de répertoires: $j\n"
}

Il faudra trouver un autre nom que lsfd

#12

diff -r ou rsync --dry-run peut aussi t’aider à trouver des différences entre deux arborescences.

#13

Je n’avais pas pensé à cette solution qui implique que je branche mon ssd nomade sur mon portable . Sinon avant je passais par le protocole ssh après avoir mis debian à jour , toujours avec ssh .

Donc je viens de tester cette commande diff -r que je ne connaissais pas avec cette option ( -r ): ça marche très bien .

Merci .

#14

j’ai adapté ta fonction pour séparer les répertoires cachés du reste afin d’obtenir une meilleure lisibilité :

lsfd() { i=0 ; j=0 ; k=0 ; 
while read L ;do basename $L;((i++));done < <(find -maxdepth 1 -type f |sort);   printf  "● Nombre de fichiers: $i\n\n"; 
while read L ;do printf "$L ";((j++));done < <(/usr/bin/ls -d */);   printf  "\n● Nombre de répertoires: $j\n" 
while read L ;do basename $L;((k++));done < <(find -maxdepth 1 -type d -name '.*' | sort); echo "● Nombre de répertoires cachés: $k" ;  }

j’espère que ça n’est pas trop bancal ; en tout cas ça fonctionne et j’ai scindé en 3 parties distinctes la sortie de find en me débarrassant des préfixes (?) ou peut-être du « chemin » (?) ( ./ ) .

Donc ta fonction utilisée en complément de diff -r , selon la configuration matérielle utilisée , va me simplifier les comparaisons de listes .

question pratique subsidiaire : je viens de corriger une faute ( ajout d’un simple « r » ) et cela a provoqué une remontée de cette file . Peut-on éviter cette remontée si on la juge inutile ?

#15

Et pourquoi pas 4 pendant qu’on y est: fichiers/répertoires cachés ou non.
Une variante pour investigation:

lsrep() { i=0 ; j=0 ; k=0 ; l=0 ; echo > ${T:=/tmp/lsrep}
  while read L ; do
   [[ -f $L && ! $L =~ ^\. ]] && echo "1$L" >> $T && ((i++))
   [[ -f $L && $L =~ ^\. ]]   && echo "2$L" >> $T && ((j++))
   [[ -d $L && ! $L =~ ^\. ]] && echo "3$L" >> $T && ((k++)) 
   [[ -d $L && $L =~ ^\. ]]   && echo "4$L" >> $T && ((l++))
  done < <(ls -A1)
  ((i > 0)) && sed -n '/^1/{s/.//;p}'  $T && printf "\e[32m● Nombre de fichiers: $i\e[m\n\n"
  ((j > 0)) && sed -n '/^2/{s/.//;p}'  $T && printf "\e[32m● Nombre de fichiers cachés: $j\e[m\n\n"
  ((k > 0)) && sed -n '/^3/{s/./ /;p}' $T |tr -d '\n' && printf "\n\e[34m● Nombre de répertoires: $k\e[m\n\n"
  ((l > 0)) && sed -n '/^4/{s/.//;p}'  $T && printf "\e[34m● Nombre de répertoires cachés: $l\e[m\n"
  printf "―――――――――――\nEn Synthèse: F= $i ~ Fc= $j | D= $k ~ Dc= $l\n"
}

Edit: exclusion des liens symboliques.

#16

heureusement que tu le précises car j’aurais pu chercher longtemps ce que faisait cette fonction .

Je pense que je vais en rester à 3 niveaux en cherchant plutôt à améliorer la lisibilité de la sortie tout en pouvant facilement modifier la présentation : l’usage le dira .

J’essaie ceci sur un niveau ( le 2 ) . C’est certainement du bricolage mais même si ça ne doit pas être techniquement très au point , ça fonctionne plutôt bien . J’ai aussi tenu compte de la remarque de @MicP pour choisir un nom :

comp() { i=0 ; j=0 ; k=0 ;
 while read L ;do basename $L;((i++));done < <(find -maxdepth 1 -type f |sort);   printf  "\n● Nombre de fichiers: $i\n\n";
 while read L ;do printf "";((j++));done < <(/usr/bin/ls -d */) ;( ls -d */) | pr -2t -w110 ;   printf  "\n● Nombre de répertoires: $j\n\n"
 while read L ;do basename $L;((k++));done < <(find -maxdepth 1 -type d -name '.*' | sort); printf "\n● Nombre de répertoires cachés: $k\n" ;  }

note 1 : à terme je vais chercher à automatiser cette recherche lorsque mon ssd est branché sur une autre machine , sinon diff -r convient très bien , avec quelque chose du genre :
ssh …ssd… find > fichier …"cat fichier … " | diff etc … En attendant je reste avec ma méthode qui marche plutôt bien et qui me permet de tester . Mais je n’aime pas trop la présentation de la sortie de diff .

note 2 : si je supprime la première redirection de " < <(find … je ne vois aucun changement dans la sortie . Quel est son rôle ?

#17

Bonjour

Pour voir ce que ça donne, créé un fichier ou et un répertoire nommé, par exemple :

"Capture d'ecran_2021-03-13_07-51-47.png"

dans le répertoire qui va être listé par ta fonction comp et lance la fonction.

#18

bonjour ,

en utilisant mon répertoire Images je vois déjà que même avec ( < < ) les espaces vides et la présence de ( de ) dans les noms de fichier posent problème :

mm@Xfce:~/Images$ comp
Capture = arrêt à l'espace vide
remède =  _

basename: opérande supplémentaire « de »
Saisissez « basename --help » pour plus d'informations.  ==>  Capture d’écran de 2021-10-14 14-03-34.png
remède = _

maintenant je vais voir pour l’effet de l’absence de la redirection n°1

note : ces noms sont un peu anciens car j’ai pris l’habitude de ne plus laisser d’espace vide

#19

pour ce qui est de l’effet de l’absence de ( < ) je ne vois pas :

mm@Xfce:~/Images/cap$ comp  ( un seul < en <(find...)
Capture  = arrêt à l'espace vide

● Nombre de fichiers: 1

/usr/bin/ls: impossible d'accéder à '*/': Aucun fichier ou dossier de ce type
ls: impossible d'accéder à '*/': Aucun fichier ou dossier de ce type

● Nombre de répertoires: 0

.

● Nombre de répertoires cachés: 1

mm@Xfce:~/Images/cap$ comp   ( avec les deux < )
Capture  = idem ci-dessus

● Nombre de fichiers: 1

/usr/bin/ls: impossible d'accéder à '*/': Aucun fichier ou dossier de ce type
ls: impossible d'accéder à '*/': Aucun fichier ou dossier de ce type

● Nombre de répertoires: 0

.

● Nombre de répertoires cachés: 1
#20

Voir mon message #11

#21

Au temps pour moi : j’avais bien lu ce message et je n’ai pas pris la peine d’essayer de trouver où était l’erreur . Aucune excuse .

Une fois corrigée les espaces vides et la présence de ( de ) ne provoquent plus de dysfonctionnement.

Qunat à la différence de comportement avec < ou < < je n’en vois aucune si ce n’est que lors de l’enreistrement source .bashrc bash me signale :

erreur de syntaxe près du symbole inattendu « <(find -maxdepth 1 -type f |sort) » .

Je reprendrai ça plus tard car je dois répéter la même erreur sans m’en rendre compte : laissons décanter .

#22

Je pense qu’effectivement tu as besoin de plus de temps pour mieux cerner ton besoin.
Quelques points à toutes fins utiles:

:black_small_square: Ouvrir un sujet pour améliorer la sortie d’un ‹ find -maxdepth 1 ›, c’est-à-dire le répertoire courant, et trouver qu’un ‹ diff -r ›, c’est-à-dire récursif, n’est pas mal non plus, c’est pas facile à suivre pour ne pas dire contradictoire.

:black_small_square: Que signifie pour toi comparer deux répertoires ? est-ce juste comparer la liste de fichiers ? ou aussi te soucier de la date et du contenu des fichiers ?
Deux fichiers de même nom avec la même arborescence sur deux supports peuvent avoir des dates et un contenu totalement différents.
Juste lister et comparer ne te donne qu’un vague aperçu de l’éventuelle synchronicité de deux disques, puisque c’est finalement ce que tu veux faire, si je comprends bien, donc rien à voir avec un ‹ find -maxdepth 1 ›.

:black_small_square: Aussi pas compris les histoires de ‹ guillemets manquants ›.
Si je les vois, c’est qu’ils sont bien là, ils n’ont pas bougé depuis le début.
Si personne n’a rien tripoté par derrière sans mon accord, aucune raison de disparaître.
En faisant un copier/coller d’une fonction, aucune raison que des guillemets disparaissent non plus.
Il y a 3 types de guillements en bash qui ont une fonction précise et pas juste à fin décorative.

echo 'SHELL' 	-> SHELL
echo "SHELL" 	-> SHELL (aucune différence entre " et ' dans ce cas)
echo `SHELL`	-> bash: SHELL : commande introuvable
echo "$SHELL"	-> /bin/bash
echo '$SHELL' 	-> $SHELL

:black_small_square: Les redirections en bash5: certes pas évident et pas trivial, je te l’accorde, mais je ne suis pas l’auteur de bash, et ne fais que suivre la documentation sur les redirections de fonctions ! Tu ne peux pas changer une syntaxe bash pour la mettre à ton goût, et t’étonner que le résultat change.

Quant à la différence de comportement avec < ou < < , je n’en vois aucune si ce n’est que lors de l’enregistrement source .bashrc bash me signale : erreur de syntaxe

Voir et ne pas voir, c’est tout l’art du « En même temps », savoir caser dans la même phrase tout et son contraire, en espérant que personne ne s’en rendre compte. C’est même un métier, tout un apprentissage.
Bonne réflexion.

#23

j’ai écrit une ânerie car , comme je le soupçonnais , ja faisais une erreur systématique dans mes comparaisons . En fait sans la 1ère redirection ça ne fonctionne pas . Mais j’aimerais bien savoir pourquoi elle est indispensable car la sortie de la substitution de processus pointe , me semble-t-il, vers stdin de la 1ère commande basename , si j’ai bien compris la fonction . Mais comme elle passe d’abord par un fichier temporaire à ce que j’ai pu lire … C’est loin d’être clair pour moi .

  • finalement le cours de l’IUT-Rodez que j’ai repris , justement à la fonction while , m’a fourni la réponse p 78 .
  • pour un éventuel lecteur aussi peu avancé que moi je rajoute ceci que je trouve assez clair :

<(...) alone is not a redirection; it’s a process substitution, that exposes the output of a command as if it were a file. the < between done and the process substitution is the redirection operator: it causes the while loop to use the process substitution as its standard input.
Everything inside the while loop inherits the loop’s standard input as its own, which is why each read command reads from the process substitution as well.

autrement dit : c’est comme ça que fonctionne une boucle while = c’est prévu pour .

Quant à la comparaison de répertoires c’est pour vérifier que lorsque je réalise des tranferts entre mon portable (la référence ) et mon ssd nomade et de sauvegarde je n’ai rien oublié en route . Tout sur l’informatique c’est pratique mais mieux vaut s’assurer qu’en cas de pépin on a bien tout sauvegardé correctement . C’est ce que j’essaie de faire à ma façon , artisanale certes , mais rien n’est immuable . Et lorsque je maîtriserai un peu mieux ssh j’essaierai de rendre ces contrôles automatiques avec l’aide de diff qui , si je lui donne les bonnes infos , n’oubliera rien lui . Pour ça diff -r , que je ne connaissais pas , m’a l’air au top . Chaque chose en son temps .

#24

Donc, si finalement, ton besoin est de synchroniser des disques, rsync le fait parfaitement, mais les réglages sont chatouilleux, très chatouilleux, tu es prévénu, la commande est complexe avec une très longue liste d’options.
A connaître, l’option --dry-run, pour tester sans effectuer aucun transfert.
Utiliser un interface graphique sur rsync serait sûrement plus simple pour toi que de tripatouiller du bash, au moins pour démarrer et apprivoiser la bête.
Un outil super léger sur rsync: grsync.
A toi de voir.

1 J'aime
#25

inutile d’aller plus loin ; au moins pour le moment . Je vais encore rester dans l’artisanat . C’est peut-être archaïque mais au moins je sais ce que je fais .

mais merci pour l’info , peut-être que dans une autre vie …