Pourquoi vaut-il mieux être root pour se lancer dans la recherche d’un fichier de configuration du système ?
Le système signale comme il se devrait qu’on ne peut pas lancer la recherche dans tel répertoire à cause des droits d’accès.
find /usr/bin -size +1M -exec ls -lh {} + \;
find lance un nouveau processus ls pour chaque résultat.
Mais en ajoutant un signe plus après les accolades, find ne lance de nouveau processus que lorsque le nombre de noms de fichiers a dépassé le nombre limite d’arguments de la ligne de commande.
cat /etc/passwd | grep bash
C’est vraiment montrer le mauvais exemple ; fournir plutôt la bonne explication.
grep "PS1" /etc/*
Le motif de noms de fichiers ne correspond pas absolument : la recherche n’est pas récursive, ….
/usr/bin est accessible en lecture à tout le monde.
On s’en fiche des processus lancés par -exec. C’est un cours d’introduction au shell, pas un exposé sur l’optimisation à outrance des commandes du shell.
L’exemple avec le “useless use of cat” est avant tout pédagogique. D’ailleurs il aurait suffi de lire la phrase juste après pour s’en rendre compte. C’est expliqué. Suffit de lire l’article.
Ben non, la recherche n’est pas récursive. Rien ne le dit dans le texte.
Mes remarques peuvent paraître pointilleuses mais c’est important pour la compréhension.
Tous les fichiers de configuration de mon système dans le répertoire /etc sont protégés en écriture pour un utilisateur courant.
find /etc -type f -writable
La commande cat combinée avec grep est fautive sans que l’on comprenne vraiment pourquoi. On pourrait penser que c’est plutôt équivalent à cat /etc/passwd ; grep bash /etc/passwd. L’utilisateur souhaite afficher le contenu du fichier, s’aperçoit que cat n’est pas adapté et réduit donc à l’essentiel ce qui est affiché grâce à grep. Néanmoins, il faut savoir que des commandes fonctionnent directement avec des fichiers et dans des pipes. Cela est éventuellement plus difficile dans la manière d’exposer mais le propos n’est pas forcément plus compliqué (quoique plus fastidieux).
On comprend que grep "PS1" /etc/* est incorrect puisque le motif du nom de fichier donne accès à des fichiers quelconques (caractère de substitution étoile) dans un répertoire rempli de fichiers. Peu importe que la recherche soit poursuivie dans les sous-répertoires mais cela paraît plus logique et surtout correct.
Le système signale comme il se devrait qu’on ne peut pas lancer la recherche dans tel répertoire à cause des droits d’accès.
findlance un nouveau processuslspour chaque résultat.Mais en ajoutant un signe plus après les accolades,
findne lance de nouveau processus que lorsque le nombre de noms de fichiers a dépassé le nombre limite d’arguments de la ligne de commande.C’est vraiment montrer le mauvais exemple ; fournir plutôt la bonne explication.
Le motif de noms de fichiers ne correspond pas absolument : la recherche n’est pas récursive, ….
/usr/bin est accessible en lecture à tout le monde.
On s’en fiche des processus lancés par -exec. C’est un cours d’introduction au shell, pas un exposé sur l’optimisation à outrance des commandes du shell.
L’exemple avec le “useless use of cat” est avant tout pédagogique. D’ailleurs il aurait suffi de lire la phrase juste après pour s’en rendre compte. C’est expliqué. Suffit de lire l’article.
Ben non, la recherche n’est pas récursive. Rien ne le dit dans le texte.
Mes remarques peuvent paraître pointilleuses mais c’est important pour la compréhension.
Tous les fichiers de configuration de mon système dans le répertoire
/etcsont protégés en écriture pour un utilisateur courant.La commande
catcombinée avecgrepest fautive sans que l’on comprenne vraiment pourquoi. On pourrait penser que c’est plutôt équivalent àcat /etc/passwd ; grep bash /etc/passwd. L’utilisateur souhaite afficher le contenu du fichier, s’aperçoit quecatn’est pas adapté et réduit donc à l’essentiel ce qui est affiché grâce àgrep. Néanmoins, il faut savoir que des commandes fonctionnent directement avec des fichiers et dans des pipes. Cela est éventuellement plus difficile dans la manière d’exposer mais le propos n’est pas forcément plus compliqué (quoique plus fastidieux).On comprend que
grep "PS1" /etc/*est incorrect puisque le motif du nom de fichier donne accès à des fichiers quelconques (caractère de substitution étoile) dans un répertoire rempli de fichiers. Peu importe que la recherche soit poursuivie dans les sous-répertoires mais cela paraît plus logique et surtout correct.Mec.