Commande "find" partiellement incomprise

Bonjour à tous,

Je suis amené à faire un exercice dont voici l'intitulé :

Use find to identify any file (not directory) modified in the last day, NOT owned by the root user and execute ls -l on them.

En creusant j'ai trouvé la commande suivante qui permet de compléter l'exercice correctement :

Code:

---

find / -mtime -1 -type f -uid +0 -exec ls -l {} \; 2>/dev/null

---

Concernant les options employées, je n'ai pas de problème de compréhension, toutefois ce que je ne comprends pas ce sont les éléments qui succèdent l’exécution de la commande ls -l

A savoir toute cette partie là : {} \; 2>/dev/null

J'ai tenté d'orienter ma recherche sur les expression régulières, mais il semblerait que je fasse fausse route.
Et la forme de la commande ne m'aide pas vraiment pour faire une recherche Google pertinente car je ne sais pas vraiment quels mots clefs employer.. :?

De ce que j'ai cru comprendre, 2>/dev/null redirige le flux stderr vers /dev/null mais je n'arrive pas à comprendre pourquoi (est-ce pour ne pas afficher d'erreur ?).

Je vous remercie d'avance pour vos lumières, car là je sèche un peu ! : )

Bonjour

find est une commande assez puissante car on peut lui indiquer, pour chaque fichier trouvé, de le faire traiter par une autre commande.
Parlons maintenant de cette autre commande car c'est elle le pivot de la compréhension. Imagine que tu veuilles effacer de façon standard le fichier "toto", tu taperas naturellement rm -f toto. Imagine que tu veuilles copier toto dans /tmp, tu taperas cp toto /tmp.
Comme tu le vois, tu as là deux syntaxes pas tout à fait équivalentes. Pour la première "rm" tu passes une option "-f" en premier paramètre, et le nom du fichier est passé en seconde position. Pour la seconde "cp", tu lui donnes le nom du fichier en premier paramètre, et tu donnes la destination "/tmp" en second.
Ainsi toutes les commandes ne se valent pas dans leurs façon de considérer leurs arguments (et si tu connais la commande "tar" tu comprendras d'autant mieux ce que je veux dire)

Maintenant, comment va faire "find" pour appeler ta commande tout en sachant comment positionner correctement le fichier qu'il trouve pour que la commande le comprenne correctement ? Grace à la syntaxe {}. Ces accolades symbolisent le fichier trouvé par find lorsqu'il doit appeler ladite commande et la lui passer.
Ainsi imagine que je veuille supprimer tous les fichiers "toto", mon find sera écrit de cette façon: find / -name "toto" -type f -exec rm -f {} \;. Si maintenant je veux tous les copier dans "/tmp" (ok c'est con car le dernier écrasera les autres mais c'est pour l'exemple), mon find sera écrit find / -name "toto" -type f -exec cp {} /tmp \;.

Et le point-virgule final est dans la même optique, pour indiquer à find que la commande se termine à telle position et que ce qui suit (ici 2>/dev/null) ne fait pas partie de la commande à invoquer mais continue le find. Et comme un point-virgule est un élément particulier du shell, il faut le protéger par un backslashe pour que find le récupère (sinon c'est le shell qui le récupère avant et find ne le reçoit pas).

Et ce "2>/dev/null" permet de ne pas avoir de remontée de message d'erreur lorsque find se trouve dans l'impossibilité de descendre dans un répertoire (pas les droits suffisants par exemple)

Il existe une autre syntaxe presque similaire: find / -name "toto" -type f -exec rm -f {} +. Ce "+" signifie "tous les fichiers trouvés d'un coup. Là où la première syntaxe avec le point-virgule appellerait 50 fois "rm" s'il y avait 50 fichiers trouvés, cette syntaxe ne l'appelle qu'une fois mais lui passe tous les fichiers trouvés en une grosse liste de paramètre (comme si tu tapais rm -f /x/toto /y/toto /z/toto pour effacer manuellement les 3 fichiers). Ce qui suppose alors évidemment que ladite commande n'attend rien d'autre que les fichiers à traiter dans cette liste d'arguments (impossible par exemple d'utiliser cette syntaxe pour copier dans /tmp car le dernier argument de "cp" n'est pas le fichier à copier mais sa destination).

Donc ici find / -mtime -1 -type f -uid +0 -exec ls -l {} \; 2>/dev/null se lira

• recherche à partir de la racine "/"
• tout élément modifié il y a moins de 1 jour
• de type f (fichier classique)
• ayant un uid > 0 (donc pas uid root)
• chaque fichier trouvé sera traité par la commande ls -l fichier_trouvé
• tout en renvoyant les messages d'erreurs éventuels dans néant /dev/null

PS: toutes les contraintes de recherche étant inclusives => il faut toutes les containtes validées pour que ça matche

[chipoterie]La vraie réponse à la question serait plus:

Code:

---

find / -mtime -1 -type f -not -user root -exec ls -l {} \; 2>/dev/null

---

[/chipoterie]

Bonjour Sve@r,

Je te remercie beaucoup d'avoir pris de ton temps pour formuler cette réponse très précise, c'est beaucoup plus clair à présent ! :D


Pour ma culture générale, saurais-tu comment nommer les composants d'une commande, tels que "{}" ";" voire même "|" ?


J'ai rencontré le même problème la première fois que je suis tombé sur une expression régulière.
Ne sachant pas nommer le concept (regex), je ne savais pas comment formuler mes recherches en ligne pour trouver de la documentation les concernant.

Citation:

---

Envoyé par disedorgue

[chipoterie]La vraie réponse à la question serait plus:

Code:

---

find / -mtime -1 -type f -not -user root -exec ls -l {} \; 2>/dev/null

---

[/chipoterie]

---

C'est souvent intéressant les chipoteries, mine de rien.

Cela car l'UID de root peut être différent de "0" ?
Je n'ai jamais rencontré le cas, mais cela m'intéresse de connaître le raisonnement derrière.

D'un point de vue système, on regarde l'uid et le "0" est le super utilisateur mais en aucun cas "root" (qui n'est qu'un nom dans /etc/passwd).

Mais passons, vois la question autrement et que l'on te demande de faire le find sur les fichiers de toto, tu penses qu'il aura toujours le même uid ?

Citation:

---

Envoyé par disedorgue

D'un point de vue système, on regarde l'uid et le "0" est le super utilisateur mais en aucun cas "root" (qui n'est qu'un nom dans /etc/passwd).

Mais passons, vois la question autrement et que l'on te demande de faire le find sur les fichiers de toto, tu penses qu'il aura toujours le même uid ?

---

Non, effectivement c'est juste, dans ce cas de figure j'aurais eu tendance à utiliser -user toto.
Je te remercie pour la précision.

Citation:

---

Envoyé par disedorgue

[chipoterie]La vraie réponse à la question serait plus:

Code:

---

find / -mtime -1 -type f -not -user root -exec ls -l {} \; 2>/dev/null

---

[/chipoterie]

---

Ah oui en effet, c'est plus parlant du point de vue humain (et la commande comprend la même chose)

Citation:

---

Envoyé par novae84

Cela car l'UID de root peut être différent de "0" ?

---

Absolument pas. C'est "0" le référent, pas le nom "root". Un fichier possède un uid, si ce uid est 0 alors il appartient à root (même si le user littéral "root" est remplacé par autre chose dans les OS sécurisés). Le terme "root" exprime une notion tout autant qu'un user mais celui qui doit être "root" doit avoir un uid à 0, pas à autre chose.
Et quand l'OS vérifie les droits, il commence par regarder si le uid qui accède à ce fichier est 0 et dans ce cas il arrête la vérif car il a tous les droits.

Citation:

---

Envoyé par novae84

Pour ma culture générale, saurais-tu comment nommer les composants d'une commande, tels que "{}" ";" voire même "|" ?

---

"|" c'est un pipe, traduction américaine d'un tube de communication entre deux process (ls -l | sort | tr [':lower:]' '[:upper:]'). "{}" ça j'en sais absolument rien. Je ne suis même pas certain que ça ait un nom. Le man de find en parle sans donner de terme. On le retrouve aussi dans la commande "xargs" avec le même rôle (ie symboliser le fichier traité) là encore sans donner de nom. Mais ce n'est pas une regex. Dans les regex, le symbole "{}" représente la répétition (ex "a{1,}" signifiant "a répété de 1 à n fois")

Citation:

---

Envoyé par disedorgue

Mais passons, vois la question autrement et que l'on te demande de faire le find sur les fichiers de toto, tu penses qu'il aura toujours le même uid ?

---

[chipoterie]Ben en fait je pense que oui, pour plusieurs raisons

• c'est mieux pour la cohérence du système, ou du travail de ses users, qu'un user ne change pas de uid tous les 4 matins :aie: (et à fortiori dans le cas d'un réseau de machines pour groupe de travail, vaut mieux que le user toto ait le même uid sur toutes les machines :mur:)
• si tu demandes à chercher les fichiers de toto, et que toto a changé de uid, comment comprendre ta demande ? Chercher les fichiers de l'ancien uid ou du nouveau ? Ou des deux ? Et quoi faire si un nouvel user est arrivé entre temps en récupérant l'ancien uid de toto ? :mur: :mur:
• si le besoin de changement de uid est réellement nécessaire (ok ça peut arriver) et que l'admin fait correctement son boulot, après avoir changé le user toto, il fera un find pour chercher tous les fichiers ayant l'ancien uid et pour les changer sur le nouveau (en faisant gaffe aussi aux liens symboliques car quand find rencontre un lien symbolique, sans précision particulière il va regarder le fichier lié et non le lien => on peut donc, si on ne fait pas gaffe, laisser les liens symboliques à l'ancien uid :mur: :mur: :mur:

[/chipoterie] :P

Citation:

---

Envoyé par novae84

Non, effectivement c'est juste, dans ce cas de figure j'aurais eu tendance à utiliser -user toto.

---

Une option sympa c'est "-nouser" permettant de retrouver les fichiers n'ayant plus de propriétaire (quand on supprime un user du système par exemple). Il y a son homologue pour les groupes avec "-nogroup".

Merci à toi pour ces précisions. : )

Concernant le nommage des caractères spéciaux comme |, {}, etc.. je pense (sans certitude) que le terme que je recherchais est tout simplement "opérateurs".
Mais j'ai un peu du mal à être formel à 100%, car je n'ai pas encore trouvé de liste ou doc. vraiment exhaustive de tous les caractères utilisables.

edit : Mhh.. après réflexion, il ne servent pas tous à effectuer une opération, donc je doute quelque peu de ma déduction.. Peut-être que "caractères spéciaux" -tout bêtement- est plus approprié.

Citation:

---

Envoyé par novae84

Mais j'ai un peu du mal à être formel à 100%, car je n'ai pas encore trouvé de liste ou doc. vraiment exhaustive de tous les caractères utilisables.

---

Parce que certains caractères sont spécifiques au shell (pipe, dollar, point-virgule) tandis que d'autres sont spécifiques à une commande particulière, symbolique définie donc dans la commande par ses programmeurs. Donc déjà tu peux très bien avoir le même caractère pour deux commandes différentes avec deux significations différentes (exemple accolades n'ayant pas la même signification pour find et pour awk). Voire même qu'on retrouvera aussi le même symbole en shell tout en ayant une autre signification (les accolades en shell servent à manipuler/gérer le contenu d'une variable avant de retourner le résultat => echo ${HOME//\//:})

Citation:

---

Envoyé par novae84

Peut-être que "caractères spéciaux" -tout bêtement- est plus approprié.

---

Non, eux ils ont déjà une définition: ce sont les caractères permettant de nommer partiellement un fichier => ls a??x*.c => lister tous les fichiers ayant un nom commençant par "a", ayant ensuite deux caractères quelconques mais présents puis un "x" puis ensuite toute chaine y compris une chaine vide et se terminant par ".c"

Je comprends, c'est limpide. Merci beaucoup pour ton aide !

Citation:

---

Envoyé par Sve@r

"{}" ça j'en sais absolument rien. Je ne suis même pas certain que ça ait un nom. Le man de find en parle sans donner de terme. On le retrouve aussi dans la commande "xargs" avec le même rôle (ie symboliser le fichier traité) là encore sans donner de nom.

Mais ce n'est pas une regex. Dans les regex, le symbole "{}" représente la répétition (ex "a{1,}" signifiant "a répété de 1 à n fois")

---

C'est vrai, le man find parle, sans la dénommer, de la string ``{}'', qui est remplacée par un (lorsque suivi de \;) ou plusieurs (lorsque suivi de \+) des pathnames trouvés par find.

En tout cas, la string ``{}'' ne concerne que le cas où elle suit le paramètre -exec du find.

Pour moi, c'est la représentation de l'argument variable utilisé par l'utilitaire invoqué par le -exec du find... si vous voyez ce que je veux dire... 8O

Ne dit-on par le RAVUPLUIPLEF habituellement ? ::dehors::

Citation:

---

Envoyé par jack-ft

...(lorsque suivi de \+)

---

Pas besoin de backslash devant le "+", ce n'est pas un caractère spécial, le shell ne l'interprètera donc pas et find le recevra tel quel.
Il faut bien comprendre que quand on écrit find ... -exec ... \;, le programme "find" lui il reçoit find ... -exec ... ; car c'est d'un point-virgule qu'il a besoin pour se repérer, pas d'un "backslash point-virgule". Le backslash sert juste à protéger le point-virgule, caractère spécial, pour pas qu'il soit bouffé par le shell lors de la prise en compte de la commande. On peut donc utiliser n'importe quelle technique pour protéger ce point-virgule afin qu'il soit transmis au find. Exemple: find / -type f -exec ls -l {} ';'.
De même c'est aussi pour ça que quand on veut chercher un fichier en utilisant des wildcards (exemple l'étoile) qu'on doit protéger cette étoile du shell

• find / -name "*.c"
• find / -name '*.c'
• find / -name \*.c

Pour le "+" ça marche avec le backslash car quand un backslash ne sert à rien il est simplement shunté, mais ça marche donc aussi sans 8-)

Citation:

---

Envoyé par jack-ft

En tout cas, la string ``{}'' ne concerne que le cas où elle suit le paramètre -exec du find.

---

Je t'avouerai que je ne me suis jamais amusé à tenter de mette des accolades sans exec dans un find juste pour voir si ça le fait réagir :mrgreen:

Citation:

---

Envoyé par Sve@r

"{}" ça j'en sais absolument rien. Je ne suis même pas certain que ça ait un nom. Le man de find en parle sans donner de terme. On le retrouve aussi dans la commande "xargs" avec le même rôle (ie symboliser le fichier traité) là encore sans donner de nom.

---

J'ai l'impression que l'usage de "{}" dans xargs a été instauré par ressemblance avec find, car on peut mettre n'importe quelle autre chaine:

Code:

---

1 2 3 4 5 6 7

\ls -t | xargs -I{} echo "{} -> {}" | head -2 # donne la même chose que: \ls -t | xargs -Ifoo echo "foo -> foo" | head -2 # ou \ls -t | xargs -Ifile echo "file -> file" | head -2 # ou, même: \ls -t | xargs -Iecho echo "echo -> echo" | head -2

---

L'intérêt d'utiliser "{}" réside également dans le fait que cette chaine a peu de chances d'apparaître par accident (sauf si on se fait un malin plaisir d'imbriquer un find à l'intérieur du xargs (mais faudrait vraiment être vicieux!)).

Coucou !!

Je suis confronté à une nouvelle interrogation, sur un exercice quasi similaire.
Je préfère poster ici plutôt que d'ouvrir un nouveau topic afin de ne pas spammer le forum avec mes questionnements existentiels.
N'hésitez pas à me dire si ce n'est pas approprié.:oops:

En fait, l'intitulé de l'exercice est le suivant :

Find files that have changed on your machine within the past 7 days by running a specific command in the background.

Je suis donc assez rapidement parti sur cette commande :

find / -mtime -7 -type f > FilesModif.txt; 2>/dev/null &
Après exécution, mon fichier "FilesModif.txt" semble bien contenir tous les fichiers modifiés sur le système.

Mais par contre, ce que je ne comprends pas, c'est pourquoi mon terminal est "occupé" avec l'affichage des erreurs.

Comme cela :
Pièce jointe 621416

De prime abord, j'aurais cru que l'affichage des erreurs serait doublement "shunté", à la fois par le bout de commande 2>/dev/null qui envoie STDERR dans le Mordor, et par l'esperluette & qui exécute la commande en arrière plan.

Du coup je me demande, pourquoi est-ce que les erreurs apparaissent ? :weird:

Citation:

---

Envoyé par novae84

Du coup je me demande, pourquoi est-ce que les erreurs apparaissent ? :weird:

---

Le point-virgule. Il termine le find et la suite (2>...) n'est pas prise en compte dans la commande.
C'est donc pour ça que si on veut passer un point-virgule au "-exec" on doit le protéger, afin qu'il ne soit pas pris en compte par le shell quand il est lu.
N'oublie jamais qu'entre ton clavier et la commande invoquée, il y a le shell qui analyse et interprète le texte tapé.

Citation:

---

Envoyé par novae84

serait doublement "shunté", à la fois par le bout de commande 2>/dev/null qui envoie STDERR dans le Mordor, et par l'esperluette &

---

pas compris ce que l'esperluette devait shunter...

Citation:

---

Après exécution, mon fichier "FilesModif.txt" semble bien contenir tous les fichiers modifiés sur le système.

---

:mouarf: "semble" ! mais justement non !
Si on a des erreurs c'est que nous n'avons pas tous les fichiers. Donc dans cette forme la commande ne répond pas exactement à la demande.
note: Avec linux inclure des répertoires comme /usr/ et /tmp/ me parait sujet à réflexion/discussion

Citation:

---

Envoyé par novae84

et par l'esperluette & qui exécute la commande en arrière plan.

Citation:

---

Envoyé par papajoker

pas compris ce que l'esperluette devait shunter...

---

---

D'accord avec papajoker (j'avais pas noté cette remarque). L'esperluette met la commande en arrière plan mais ne shunte absolument rien. Si la commande affiche des trucs, même en arrière plan les trucs seront quand-même affichés à l'écran.

Citation:

---

Envoyé par Sve@r

D'accord avec papajoker (j'avais pas noté cette remarque). L'esperluette met la commande en arrière plan mais ne shunte absolument rien. Si la commande affiche des trucs, même en arrière plan les trucs seront quand-même affichés à l'écran.
---
Le point-virgule. Il termine le find et la suite (2>...) n'est pas prise en compte dans la commande.

---

Oui effectivement, c'est une mauvaise formulation de ma part, désolé.
Ce que je voulais dire, c'est que je pensais que la mise en arrière plan de la commande, aurait fait que les erreurs soient traitées comme le reste de la commande et ne soient pas affichées dans le terminal.
(ce qui aurait été sale tout de même, je n'ai pas vraiment d’intérêt à faire cela je pense :roll:.)
Mais je comprends mieux avec ta précision concernant le ;.

Citation:

---

Envoyé par papajoker

pas compris ce que l'esperluette devait shunter...
:mouarf: "semble" ! mais justement non !
Si on a des erreurs c'est que nous n'avons pas tous les fichiers. Donc dans cette forme la commande ne répond pas exactement à la demande.
note: Avec linux inclure des répertoires comme /usr/ et /tmp/ me parait sujet à réflexion/discussion

---

Effectivement .. !
Concernant la pertinence d'inclure ces répertoires, je suppose que c'est un peu la joie des exercices théoriques. :lol:

J'ai essayé de refaire la commande, mais sur une VM avec moins de processus en arrière plan, en tant que root et sans rediriger STDERR.

Code:

---

1 2 3 4 5 6

root@vm# find / -mtime -7 -type f > FilesModif.txt   find: '/proc/2931/task/2931/fdinfo/5': No such file or directory find: '/proc/2931/fdinfo/6': No such file or directory find: '/run/user/130/gvfs': Permission denied

---

J'ai bien moins d'erreurs.
Mais je ne m'explique pas pourquoi "Permission denied" (je suis root, comment le système ose-t-il s'adresser à moi ainsi ?!:mouarf:)
Je suppose que c'est dû au fait que le fichier soit un processus en cours d'utilisation (?)

Quant à "No such file or directory" je ne comprends pas du tout pourquoi le système me remonte cette information.

Citation:

---

Envoyé par novae84

Je suppose que c'est dû au fait que le fichier soit un processus en cours d'utilisation (?)

---

Je suppose plutot que les process sont morts lors de ta commande find.
Pour le dernier, c'est normal avec fuse, uniquement l'utilisateur 130 à accès

Citation:

---

Envoyé par papajoker

Je suppose plutot que les process sont morts lors de ta commande find.
Pour le dernier, c'est normal avec fuse, uniquement l'utilisateur 130 à accès

---

C'est à dire qu'ils était actifs quand j'ai lancé la commande, mais se sont terminés avant l’affichage du résultat, c'est bien cela ?
Ou bien est-ce la commande find qui a influé d'une manière ou d'une autre sur leur statut ?

Citation:

---

Envoyé par novae84

Ce que je voulais dire, c'est que je pensais que la mise en arrière plan de la commande, aurait fait que les erreurs soient traitées comme le reste de la commande et ne soient pas affichées dans le terminal.

---

Ben non. La mise en arrière plan d'une commande c'est juste le shell qui lance la commande et qui te rend la main sans attendre que la commande se termine. Cela ne change rien à l'affichage de ladite commande. Tu peux taper ls -l /etc ou ls -l /etc & tu verras la même chose au résultat.

Citation:

---

Envoyé par novae84

Mais je comprends mieux avec ta précision concernant le ;.

---

La vraie question c'est surtout qu'est-ce que tu avais en tête en le mettant...

Citation:

---

Envoyé par novae84

Mais je ne m'explique pas pourquoi "Permission denied" (je suis root, comment le système ose-t-il s'adresser à moi ainsi ?!:mouarf:)

---

/proc et /run sont de pseudo-fs. Déjà ils ont leur propre filesystem (tape df -v /proc /run) et donc n'obéissent pas tout à fait aux mêmes règles. Tu peux les exclure en rajoutant l'option "-xdev" au find mais cela exclut en fait tout autre filesystem quel qu'il soit (si /home est lui-aussi à part, lui-aussi est exclu).
Donc la meilleure solution c'est encore de rediriger stderr. Tu sais que find ne pourra pas tout prendre mais tu sais aussi que ce qu'il ne prendra pas tu n'en n'as pas besoin alors finalement ça s'équilibre.

Citation:

---

Envoyé par Sve@r

La mise en arrière plan d'une commande c'est juste le shell qui lance la commande et qui te rend la main sans attendre que la commande se termine. Cela ne change rien à l'affichage de ladite commande.

---

Oui, cela parait logique après quelques tests sur d'autres commandes, je comprends mieux l’intérêt.

Citation:

---

Envoyé par Sve@r

La vraie question c'est surtout qu'est-ce que tu avais en tête en le mettant...

---

Bonne question...
C'est un mauvais réflexe de ma part, car je l'avais utilisé dans la précédente commande (celle ou j'utilisais un -exec).
Mais pour celle-ci, cela n'a pas de sens.

Citation:

---

Envoyé par Sve@r

/proc et /run sont de pseudo-fs. Déjà ils ont leur propre filesystem (tape df -v /proc /run) et donc n'obéissent pas tout à fait aux mêmes règles. Tu peux les exclure en rajoutant l'option "-xdev" au find mais cela exclut en fait tout autre filesystem quel qu'il soit (si /home est lui-aussi à part, lui-aussi est exclu).

---

Merci j'y vois plus clair du coup avec cette info !

Citation:

---

Envoyé par Sve@r

Donc la meilleure solution c'est encore de rediriger stderr. Tu sais que find ne pourra pas tout prendre mais tu sais aussi que ce qu'il ne prendra pas tu n'en n'as pas besoin alors finalement ça s'équilibre.

---

Du coup en allant au plus simple, j'ai fait comme ça :

Code:

---

1 2 3

└─$ sudo find / -mtime -7 -type f > FilesModif.txt 2>/dev/null & [1] 11490

---

Ça me parait pas mal ainsi ! :)

Attention, ici c'est toi qui as ajouté une difficulté avec l'enregistrement dans un fichier (et donc tes redirections), cela n'était pas demandé.
Perso, avec une redirection dans un fichier, j'aimerais n'avoir que std1 dans le fichier mais avoir stderr à l'écran.

Pour info, il nous arrive parfois d'utiliser aussi tee pour des redirections fichiers et écran

Citation:

---

Envoyé par papajoker

Attention, ici c'est toi qui as ajouté une difficulté avec l'enregistrement dans un fichier (et donc tes redirections), cela n'était pas demandé.
Perso, avec une redirection dans un fichier, j'aimerais n'avoir que std1 dans le fichier mais avoir stderr à l'écran.

---

Je voulais voir si vous suiviez... :aie:
Plus sérieusement, merci!

J'avais ajouté cette redirection de STDOUT vers un fichier en solution de contournement, car je suis connecté en SSH et Ctrl+PgeUp ne "remonte" pas jusqu'en haut de ma liste de fichiers modifiés.
Il faut que je règle cela.

Du coup j'ai édité ainsi :
sudo find / -mtime -7 -type f & .

Citation:

---

Envoyé par papajoker

Pour info, il nous arrive parfois d'utiliser aussi tee pour des redirections fichiers et écran

---

Qu'est-ce que tu veux dire par redirection "écran" ?

J'ai regardé un peu la doc de tee vu que je ne connais pas du tout.
Par rapport à l'utilisation de >, de ce que j'ai compris c'est qu'il permet de rediriger vers de multiples fichiers.
Mais je pense que je n'ai pas compris toute la subtilité de la chose pour le coup.

Citation:

---

Envoyé par novae84

Qu'est-ce que tu veux dire par redirection "écran" ?

---

Le tee (T) est un outil qui duplique la sortie d'une commande. La copie 1 va vers un fichier de ton choix et la sortie 2 part sur l'écran comme s'il n'y avait pas eu de redirection => ls -l |tee fic.

Citation:

---

Envoyé par novae84

Par rapport à l'utilisation de >, de ce que j'ai compris c'est qu'il permet de rediriger vers de multiples fichiers.

---

Oui aussi => ls -l |tee fic1 |tee fic2 => la sortie écran du premier "tee" va dans le second qui le re-duplique encore. Ou bien ls -l |tee fic1 >fic2 => la sortie écran du tee va dans fic2.

Comment ai-je pu me passer de cela tout ce temps ..
C'est génial !

bien sûr, ls est un exemple bateau de commandes dont on souhaite traiter la sortie; pour obtenir des informations sur les fichiers, ou leur liste, on s'y prendra autrement.
mais c'est un autre sujet...
:)

2 notes :

• Si l'équivalent de > fichier.txt est | tee fichier.txt, alors l'équivalent de >> fichier.txt est | tee -a fichier.txt.
• Si on veut faire un traitement pour le fichier et un traitement pour l'écran, avec bash, on utilisera la substitution de processus en sortie >( )! Par opposition à la substitution de processus en entrée <( ).
  
  Code:

  ---

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

  $ loremipsum.bash Molestiae ipsam sed sit ea quae. Et maxime possimus est quae. A explicabo itaque nulla et. Et aut quos ad. Saepe temporibus expedita molestiae facilis explicabo magnam quisquam voluptatum. Deserunt aut voluptates et reiciendis earum est inventore qui. Blanditiis omnis ea placeat aut. Laborum qui earum maxime sint accusantium. Impedit tempora qui quod libero debitis delectus eius. Nisi iusto quam inventore fuga. Et placeat eligendi laborum rem id natus. Voluptatem quo qui provident et tempore. Expedita sint iusto et itaque quia harum accusamus. Est molestiae cupiditate ullam est accusamus. Unde quia ut assumenda animi. Voluptas magnam dolor ab et nam qui omnis et. Voluptatem amet ut quis dolores dolorum nam sint fugiat. Sint non magnam rerum. Enim aut delectus voluptatibus quia maiores aliquid autem. Eveniet id molestiae odit incidunt repellendus. Culpa error ducimus quod velit voluptatem nam amet. Id reiciendis illo sit. Est dolorem minus quia rerum molestias. Natus consectetur accusantium fuga id est accusantium. Cupiditate culpa corporis illo unde est voluptatem omnis. Corrupti nostrum accusantium error numquam aut. Earum quam impedit molestiae doloremque ea. Occaecati quibusdam quos eaque qui. Debitis sequi sunt ea. Reprehenderit nam dolor asperiores eos doloribus accusantium. Doloremque vel vel impedit tempore voluptas. Voluptatem distinctio porro est occaecati. Sit nostrum qui quisquam. Nisi est ut assumenda sit. Et cumque earum sed et eveniet voluptas enim ipsum. Ut esse nam fugit sit sint et. Quos sed tempore rerum adipisci fuga. Sit totam et recusandae dolorem cupiditate ut aliquid sunt. Et velit maxime delectus. Omnis et enim accusantium quaerat qui sapiente quam sunt. Sit consequatur et saepe ad magni maxime vitae laudantium. Laboriosam facere aut eum non. Rerum officia itaque quia. Consectetur sapiente ipsa maxime sequi excepturi tempora quia. Officiis esse sequi est reprehenderit ipsa. Fuga vel recusandae suscipit voluptatibus. Modi odio dolores voluptatem rerum ad commodi exercitationem et. Voluptatem rerum nihil eum earum. $ loremipsum.bash | tee >(sed 's@ @\n@g' - > log.txt) | sed 's@$@\n@' | head Ducimus ut laboriosam quas ullam. Dolorum sunt molestias saepe et et minima. Omnis distinctio sunt et et distinctio ipsa ut.   Quaerat dolor magnam deleniti voluptatem est. Cupiditate eum cum sunt voluptas asperiores saepe quis. Laudantium aut itaque laboriosam dignissimos ab occaecati quo recusandae. Quis aut aut accusantium est commodi pariatur. Quis aperiam aut ex quod. Et vitae illo quos est rerum.   Qui excepturi rerum dolorum laboriosam itaque. Sint iste nulla ex sapiente. Iste eligendi perferendis sunt est.   Quo quidem quas laborum est atque fuga deserunt dolores. Enim eaque voluptatem sit dicta omnis. Aut exercitationem rerum esse. Voluptate mollitia officiis autem. Delectus qui corrupti minus eum dolore.   Ut tempora facere qui quia dolorum ratione. Qui tempora accusantium et sit consequatur assumenda eaque. Illo quia aut distinctio veniam eum deserunt.   $ head log.txt Ducimus ut laboriosam quas ullam. Dolorum sunt molestias saepe et

  ---

  J'espère que cet exemple est éloquent. :ccool:

merci Flodelarab :D

Code:

---

ls -l / | tee >(sed 's/root/patron/g' - > /tmp/log.txt) | grep 'drwxr-xr'; echo -e "\ncontenu du fichier traité avec sed et avant grep:\n $(</tmp/log.txt)"

---