Bonjour à tous,  
 
Dans la série des quesitons à la c**, je voudrais le FIND....
 
Piont de départ : un petit script qui permet de faire une recherche sur plusieurs comptes USER. Je passe une variable correspondant à la saisie utilisateur au find qui va me chercher ça.
La commande find en détail :  
 

 
note : On se moque du ${i} qui ne sert qu'à balayer tous les comptes USERS de cette forme.
 
Mon souci : quand l'utilisateur saisie un truc du genre *fichier*txt qui va dans la variable ${fic}, ça me renvoit bien tout les ficheirs correspondant au filtre, mais biensûr en tenant compte de la casse ! donc aucun fichier du style "*fichier*TXT". Or je ne veux pas demander à l'utilisateur de bricoler son paramètre. Lui il tape *fichier*txt et je veux tout récupérer.
 
J'ai donc pensé à l'option 'iname' au lieu de 'name' mais là, surprise, les expressions régulières ne passent plus : je n'ai plus aucun résultat, simplement en remplaçant name par iname ...        
 
Quelqu'un saurait-il m'expliquer le souci ?
 
Merci d'avance pour vos lumières.

enlève pit-être le

2>

pour voir s'il te dit quelque chose (pit-être qu'il ne connait pas iname) ?

... ben .... ben mince....
 
V'là t'y pas que le find diffère selon les distributions de Ninix ... ( payantes en plus !)  C'est ....
 
C'est moche en fait ....
 
Bon ben, tant pis pour moi alors :-(
 
Merci quand même art_dupond

POSIX ne définit que l'existence obligatoire de certains outils, et la standardisation de certaines options. Tous les "bonus" propres à certaines distributions ne sont pas forcément disponibles sur d'autres.

Ben à ce moment là je trouve très regrettable qu'un utilitaire reconnu super puissant pour les recherches sous Unix n'ait pas comme option standard de switcher en mode case senstive ou non... Encore une logique logique !
 
Mais bon, j'imagine que mon mode de pensée n'est rien vis à vis des grands pontes POSIXiens ^^ (ou qu'il est trop tard pour ces détails ?)
 
Bref ! on s'égare, merci quand même pour la précision.

tu peux sans doute contourner le problème (de manière un peu crade), en filtrant grace à un grep plutot que grace au "-name" de find...

Ben justement, de manière un peu crade. J'ai peur que ce soit trop gourmand:  bricoler un truc avec find . -print | grep -i .... va dans un premier temps me lister tous les fichiers de la machine avant d'appliquer le grep et ça, c'est pas bon ça ! ça va pas plaire à la machine de test qui est déjà raz la tronche, alors ne parlons pas des machines de production.
 
Pas grave pas grave, l'utilisateur n'aura qu'à savoir ce qu'il veut et puis c'est tout ^^

c'est quelle distribution ? tu peux pas installer un autre find ?

euh... 'machines tests' 'machine de production' 'client' ....
 
disons que je ne fais pas ce que je veux mais plutôt ce que je peux ^^

 
J'avais le même soucis sur AIX 5.3, avec le case sensitive pour l'option -name du find.
 
Pas besoin de bricoler avec un pipe, tu peux appliquer des fonctions directement dans l'exécution du find, c'est bcp plus rapide que de traiter tout le résultat via un pipe
 
Par exemple :
find /tst${i}/K2 -type f | grep -i "${fic}"
 
devient
 
find /tst${i}/K2 -type f -exec grep -i "${fic}" {} \;

Oui, mais tu le dis : c'est équivalent, dans les deux cas tu perds l'intérêt du find, puisqu'il va de toute façon appliquer un traitement en second temps sur tous les fichiers qu'il a récupéré dans un premier temps. Il doit effectivement y avoir un petit gain en utilisant -exec mais bon, j'en suis pas sûr ?
 
Je pense que justement, l'intérêt serait bien de filtrer dès la première opération de recherche ? Surtout pour des trucs aussi triviaux que la casse des lettres. Si encore t'avais un truc tordu je dis pas qu'il faille utiliser un traitement supplémentaire ! Mais là bon.....

je suis pas sur gain de passer le grep en -exec, il va lancer la commande autant de fois qu'il y a de fichiers, non?

 
Oui, mais pour l'avoir mis en place sur un système de Production avec des dizaines de milliers de fichiers, le -exec a tjs été plus rapide qu'un pipe suivi d'un grep.
 
Après, l'implémentation du -iname en case non sensitive est bien plus performante, mais je suis en souche AIX spécifique chez mon client (niveau 3 de sécurité) qui interdit l'utilisation d'un autre find (ou tout autre binaire système sorti de la souche), donc on fait avec les moyens du bord

Ok ok, Leif me confirme donc ce que je pensais.
 
Bon ben ça fera une très bonne rustine vu les contraintes client derrière ^^
 
Merci à tous pour vos conseils et retours d'expérience !

 
j'aurais pensé l'inverse, mais plus par impression que par expérience. Je le note donc.  

Pas de soucis, le forum sert à partager ses expériences
 
J'essayerais demain de faire une petite comparaison chiffrée avec une recherche massive, je vous en ferais part

Ouhlala, grosse grosse erreur, mea culpa, je me suis mélangé les pinceaux.  
 
Le grep dans le -exec va lire le contenu des fichiers au fûr et à mesure, bonjour les perfs
 
Si on ne dispose pas de l'option -iname, il y a plusieurs solutions, je ne vais citer que les deux qui me semblent les plus performantes :
Exemple : on recherche tous les fichiers suffixés par .gz ou .GZ
 
1) on connait à l'avance toutes les occurences de la casse, dans ce cas il faut utiliser l'opérateur "OR"(-o) du find :

 
2) on ne connait pas toutes les occurences de la recherche, et au lieu de faire une boucle après le find, on peut utiliser la fonction xargs en traitant le résultat sous forme de liste, puis on pipe avec le grep sans la casse :
find . -type f -follow | xargs -I file echo file | grep -i ".gz$"
 
EDIT suite à l'intervention parfaitement recevable de pataluc      
2) on ne connait pas toutes les occurences de la recherche, on grep après le find

 
 
Voilà, désolé pour la confuse d'hier

Hop, une petite mesure effectuée sur une baie de 40To pour la recherche de tous les fichiers avec le suffixe .gz ou .GZ :
 

 
On peut remarquer que l'utilisation du find avec l'opérateur OR est évidemment bien plus rapide si on connait à l'avance toutes les occurrences de la casse.
 
 
Note pour ceux que çà intéressent :
Les options du find supportent les opérateurs logiques -o = OR , -a = AND, ! = NOT
Par exemple :
si on souhaite récupérer les fichiers plus vieux que 3 jours dont :
- le suffixe est ".gz" mais que le nom ne commence pas par "test_"
- ou tous les fichiers suffixés par ".out"
voici la commande :
 

je vois pas pourquoi tu mets un xargs par contre??
 

ca marcherait pareil...

 
Pas faux
 
La fatigue surement
 
EDIT : j'édite mes posts pour éviter les commandes inutiles
EDIT² : les durées d'exécution ne changent pas par contre (ce qui est logique)

Donc  en fait, si je suis bien toutes vos analyses, on reste sur la même conclusion :
 
find + grep si j'ai pas d'option iname ^^
 
Nan parce que je me disais qu'il fallait recentrer le débat là, sinon Leif va nous faire une rupture de durite cérébrale        
 
En tout cas merci pour vos interventions, on en apprend tous les jours (surtout avec des preuves chiffrées : merci à Leif pour s'être pris le choux et nous donner des preuves aussi précises       !)

 
Non, non, mais tout va bien      
 
Si tu as peu de valeurs de casse différentes (genre : gz, GZ, Gz et gZ), utilise le séparateur "OU" du find, qui est bien plus performant.
 
Bon, si t'as ointes mille valeurs de casse différentes, le "|grep -i" résoudra ton problème en te faisant perdre ton temps efficacement

mwé, donc solution du grep.
 
après, de toi à moi, le client il a rien précisé sur le temps que ça devait ou non prendre ^^
 
C'est pour un truc en One shot donc ça prendra le temps qu'il faut : on n'est pas à 30 min près !
 
See you soon !