Bonjour,
J’ai un script qui stock l’état des permissions d’un répertoire dans un fichier. Pour comparer l’état courant avec l’état sauvegardé je procède ainsi :
function check() {
diff -aBy <(cat $1) <(store $2) | tr "\000" " " |egrep '\s\||>|<\s'
}$1 est mon fichier dans lequel sont stockés les permissions$2 est le répertoire concerné
Le fichier est généré ainsi (c’est la fonction 'store' utilisée ci-dessus) :
function store() {
find "$1" -printf "%u\000%g\000%m\000%h/%f\n"
}(ici $1 est le répertoire concerné)
J’obtiens ce genre d’output :
stef stef 640 ./README.md | stef staff 600 ./README.md
stef stef 750 ./.git | stef stef 710 ./.git
C’est super, c’est exactement ce que je veux, un moyen d’avoir rapidement une vue sur d’éventuelles modifications des droits ou sur l’ajout de nouveaux fichiers dans une arborescence.
Quelque temps plus tard je me suis dit : « Hé patate ! Tu ne sais pas si l’ordre (des fichiers en sortie de la commande find) sera toujours le même, tu devrais trier ! »
Quand je commence à m’appeler patate, je fais pas le malin et je m’obéis… donc je fais ça :
diff -aBy <(sort $1) <(store $2 | sort) | tr "\000" " " |egrep '\s\||>|<\s'et là patatra je n’ai plus le même résultat :
> stef staff 600 ./README.md
stef stef 750 ./.git | stef stef 710 ./.git
il m’en manque un bout (et parfois j’ai un décalage d’une ligne).
J’ai le même comportement si j’effectue le sort à l’intérieur de la fonction 'store'.
Je ne comprends pas pourquoi.
Comment puis-je m’assurer de comparer deux sorties de find (entre une exécution de store et l’exécution précédente stockée dans un fichier) qui soient toujours dans le même ordre ? (Est-ce que nativement find crache les fichiers toujours dans le même ordre ?)
Est-ce que ce serait l’utilisation du caractère nul qui me joue des tours ici ? D’après ce que je lis, il n’est pas possible de stocker une chaîne contenant ce caractère dans une variable mais tubes et redirections ne devraient pas poser de problème.
# c'est possible
Posté par NeoX . Évalué à 2.
pourquoi ne pas alors stocker simplement tes resultats en CSV
%u;%g;%filele sort devrait alors fonctionner,
tu pourrais aussi ouvrir le fichier dans un tableur, etc
[^] # Re: c'est possible
Posté par Marotte ⛧ . Évalué à 2.
L’utilisation du caractère nul plutôt qu’un point-virgule c’est parce que c’est le seul caractère que je suis assuré de ne pas rencontrer dans le chemin d’un fichier… alors que le point virgule :
Si j’ai un fichier avec ce genre de nom, pouf le script (il prendrait 'tl' comme nom de fichier)…
Il y aurait aussi la solution de ne spliter qu’un nombre restreint de colonnes (les trois premières) mais ça devient plus compliqué avec awk…
Donc j’aimerais d’abord être sûr que c’est à cause du caractère nul comme séparateur que j’ai ce comportement. D’après la lecture du manuel ça ne devrait pas poser de problème.
# find... | sort ?
Posté par frayd . Évalué à 2.
Et en faisant un sort au moment du find ?
Je ne me suis pas remis exactement dans tes conditions,
mais ça semble marcher :
[^] # Re: find... | sort ?
Posté par Marotte ⛧ . Évalué à 3.
Ah oui mais tu triches ! Tu ajoutes une espace comme séparateur…
Comme j’ai écrit, j’ai bien la même chose si je fais le sort au moment du find.
Cela dit merci quand même pour ton commentaire, j’essaierai en faisant
sort -t"\000" -k4[^] # Re: find... | sort ?
Posté par frayd . Évalué à 1.
Arf…
Désolé, j'ai cru que l'absence d'espaces dans ton exemple était une erreur de typo…
# sdiff ?!
Posté par Flyounet (site web personnel) . Évalué à 1.
sdiffn'est pas suffisant pour ce que tu veux faire ?[^] # Re: sdiff ?!
Posté par Marotte ⛧ . Évalué à 2.
Je n’ai pas eu le temps de me re-pencher sur ce projet mais sdiff est probablement ce que je cherche. Merci pour ton test !
Ce qui voudrait dire que sdiff n’est pas équivalent à diff -y…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.