Je cherche un fichier précis sur tout le DD interne par la commande
shell via le terminal :
find / '*conflit*' | less
Surprise : le terminal ne trouvant pas ce fichier, me sort tous les >
800.000 fichiers du DD au lieu de sortir une liste vide. Ce qui prend un
temps interminable.
Est-ce un comportement normal ?
Comment y remédier ?
Tkx
Le 16/11/2015 20:33, Jean-Pierre Kuypers a écrit :
Note : Je ne vois pas très bien en quoi fr.comp.os.mac-os.x est con- cerné.
C'est vrai que le shell de commande n'a vraiment rien à voir avec l'OS... Surtout sur un Unix. On en lit des bonnes, parfois !
J'aurais interrogé sur fr.comp.sys.mac.programmation, plus repère des Macintochiens Unix-chiens...
Je ne vois pas le rapport entre l'utilisation d'un shell en interactif, et la programmation.
A la limite le groupe générique fr.comp.os.unix serait adapté, ou fr.comp.os.bsd vu que find, le shell, etc, tout ça vient directement de freeBSD, ou pourquoi pas fr.comp.os.linux.configuration que ce genre de question a le plus de chance de trouver une réponse rapide.
-- "Je suis de formation théologique très rationnelle" Richard Hachel
Le 16/11/2015 20:33, Jean-Pierre Kuypers a écrit :
Note : Je ne vois pas très bien en quoi fr.comp.os.mac-os.x est con-
cerné.
C'est vrai que le shell de commande n'a vraiment rien à voir avec
l'OS... Surtout sur un Unix. On en lit des bonnes, parfois !
J'aurais interrogé sur fr.comp.sys.mac.programmation, plus
repère des Macintochiens Unix-chiens...
Je ne vois pas le rapport entre l'utilisation d'un shell en interactif,
et la programmation.
A la limite le groupe générique fr.comp.os.unix serait adapté, ou
fr.comp.os.bsd vu que find, le shell, etc, tout ça vient directement de
freeBSD, ou pourquoi pas fr.comp.os.linux.configuration que ce genre de
question a le plus de chance de trouver une réponse rapide.
--
"Je suis de formation théologique très rationnelle"
Richard Hachel
Le 16/11/2015 20:33, Jean-Pierre Kuypers a écrit :
Note : Je ne vois pas très bien en quoi fr.comp.os.mac-os.x est con- cerné.
C'est vrai que le shell de commande n'a vraiment rien à voir avec l'OS... Surtout sur un Unix. On en lit des bonnes, parfois !
J'aurais interrogé sur fr.comp.sys.mac.programmation, plus repère des Macintochiens Unix-chiens...
Je ne vois pas le rapport entre l'utilisation d'un shell en interactif, et la programmation.
A la limite le groupe générique fr.comp.os.unix serait adapté, ou fr.comp.os.bsd vu que find, le shell, etc, tout ça vient directement de freeBSD, ou pourquoi pas fr.comp.os.linux.configuration que ce genre de question a le plus de chance de trouver une réponse rapide.
-- "Je suis de formation théologique très rationnelle" Richard Hachel
pehache
Le 16/11/2015 20:59, Bernd a écrit :
pehache wrote:
Ajouter "sudo" avant la commande pour qu'elle s'exécute avec les privilèges admin (root).
sudo find / -iname '*conflit*' | less
Je l'avais fait aussi en constatant que pleins d'accès retaient interdits mais ça ne change rien. Il y en a (à vue de nez) peut-être apparemment moins mais il en reste une palanquée.
Ah bon ? Pour voir j'en ai lancé un il y a 10mn, il tourne encore mais pour l'instant il n'a produit que 2 lignes de ce genre : =================================================== TOTO2:~ ******$ sudo find / -name prout Password: find: /dev/fd/3: Not a directory find: /dev/fd/4: Not a directory
=================================================== -- "Je suis de formation théologique très rationnelle" Richard Hachel
Le 16/11/2015 20:59, Bernd a écrit :
pehache <pehache.7@gmail.com> wrote:
Ajouter "sudo" avant la commande pour qu'elle s'exécute avec les
privilèges admin (root).
sudo find / -iname '*conflit*' | less
Je l'avais fait aussi en constatant que pleins d'accès retaient
interdits mais ça ne change rien. Il y en a (à vue de nez) peut-être
apparemment moins mais il en reste une palanquée.
Ah bon ? Pour voir j'en ai lancé un il y a 10mn, il tourne encore mais
pour l'instant il n'a produit que 2 lignes de ce genre :
=================================================== TOTO2:~ ******$ sudo find / -name prout
Password:
find: /dev/fd/3: Not a directory
find: /dev/fd/4: Not a directory
===================================================
--
"Je suis de formation théologique très rationnelle"
Richard Hachel
Ajouter "sudo" avant la commande pour qu'elle s'exécute avec les privilèges admin (root).
sudo find / -iname '*conflit*' | less
Je l'avais fait aussi en constatant que pleins d'accès retaient interdits mais ça ne change rien. Il y en a (à vue de nez) peut-être apparemment moins mais il en reste une palanquée.
Ah bon ? Pour voir j'en ai lancé un il y a 10mn, il tourne encore mais pour l'instant il n'a produit que 2 lignes de ce genre : =================================================== TOTO2:~ ******$ sudo find / -name prout Password: find: /dev/fd/3: Not a directory find: /dev/fd/4: Not a directory
=================================================== -- "Je suis de formation théologique très rationnelle" Richard Hachel
josephb
Bernd wrote:
Le man find est tellement abscons et surtout dépurvu d'au moins un exemple qu'il me sort par les yeux ;) J'ai essayé et la réponse est Nein!
essaye plutôt celui-là, un peu plus "humain" et avec quelques exemples à la fin <http://ss64.com/osx/find.html> ou même cestui : <https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/find.1.html> -- J. B.
Bernd <romer@bernd.invalid> wrote:
Le man find est tellement abscons et surtout dépurvu d'au moins un
exemple qu'il me sort par les yeux ;)
J'ai essayé et la réponse est Nein!
essaye plutôt celui-là, un peu plus "humain" et avec quelques exemples à
la fin
<http://ss64.com/osx/find.html>
ou même cestui :
<https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/find.1.html>
--
J. B.
Le man find est tellement abscons et surtout dépurvu d'au moins un exemple qu'il me sort par les yeux ;) J'ai essayé et la réponse est Nein!
essaye plutôt celui-là, un peu plus "humain" et avec quelques exemples à la fin <http://ss64.com/osx/find.html> ou même cestui : <https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/find.1.html> -- J. B.
romer
pehache wrote:
Le 16/11/2015 20:59, Bernd a écrit : > pehache wrote: > >> Ajouter "sudo" avant la commande pour qu'elle s'exécute avec les >> privilèges admin (root). >> >> sudo find / -iname '*conflit*' | less > > Je l'avais fait aussi en constatant que pleins d'accès retaient > interdits mais ça ne change rien. Il y en a (à vue de nez) peut-être > apparemment moins mais il en reste une palanquée. >
Ah bon ? Pour voir j'en ai lancé un il y a 10mn, il tourne encore mais pour l'instant il n'a produit que 2 lignes de ce genre : =================================================== > TOTO2:~ ******$ sudo find / -name prout Password: find: /dev/fd/3: Not a directory find: /dev/fd/4: Not a directory
Il est pensable que rien ne sorte quand le fichier ou le dossier n'existe pas. Mais si les éléments existent, la commande ne peut pas les traiter si l'accès est protégé.
-- A+ -- Romer
pehache <pehache.7@gmail.com> wrote:
Le 16/11/2015 20:59, Bernd a écrit :
> pehache <pehache.7@gmail.com> wrote:
>
>> Ajouter "sudo" avant la commande pour qu'elle s'exécute avec les
>> privilèges admin (root).
>>
>> sudo find / -iname '*conflit*' | less
>
> Je l'avais fait aussi en constatant que pleins d'accès retaient
> interdits mais ça ne change rien. Il y en a (à vue de nez) peut-être
> apparemment moins mais il en reste une palanquée.
>
Ah bon ? Pour voir j'en ai lancé un il y a 10mn, il tourne encore mais
pour l'instant il n'a produit que 2 lignes de ce genre :
=================================================== > TOTO2:~ ******$ sudo find / -name prout
Password:
find: /dev/fd/3: Not a directory
find: /dev/fd/4: Not a directory
Il est pensable que rien ne sorte quand le fichier ou le dossier
n'existe pas. Mais si les éléments existent, la commande ne peut pas les
traiter si l'accès est protégé.
Le 16/11/2015 20:59, Bernd a écrit : > pehache wrote: > >> Ajouter "sudo" avant la commande pour qu'elle s'exécute avec les >> privilèges admin (root). >> >> sudo find / -iname '*conflit*' | less > > Je l'avais fait aussi en constatant que pleins d'accès retaient > interdits mais ça ne change rien. Il y en a (à vue de nez) peut-être > apparemment moins mais il en reste une palanquée. >
Ah bon ? Pour voir j'en ai lancé un il y a 10mn, il tourne encore mais pour l'instant il n'a produit que 2 lignes de ce genre : =================================================== > TOTO2:~ ******$ sudo find / -name prout Password: find: /dev/fd/3: Not a directory find: /dev/fd/4: Not a directory
Il est pensable que rien ne sorte quand le fichier ou le dossier n'existe pas. Mais si les éléments existent, la commande ne peut pas les traiter si l'accès est protégé.
-- A+ -- Romer
pehache
Le 18/11/2015 19:24, Bernd a écrit :
pehache wrote:
Le 16/11/2015 20:59, Bernd a écrit :
pehache wrote:
Ajouter "sudo" avant la commande pour qu'elle s'exécute avec les privilèges admin (root).
sudo find / -iname '*conflit*' | less
Je l'avais fait aussi en constatant que pleins d'accès retaient interdits mais ça ne change rien. Il y en a (à vue de nez) peut-être apparemment moins mais il en reste une palanquée.
Ah bon ? Pour voir j'en ai lancé un il y a 10mn, il tourne encore mais pour l'instant il n'a produit que 2 lignes de ce genre : =================================================== >> TOTO2:~ ******$ sudo find / -name prout Password: find: /dev/fd/3: Not a directory find: /dev/fd/4: Not a directory
Il est pensable que rien ne sorte quand le fichier ou le dossier n'existe pas. Mais si les éléments existent, la commande ne peut pas les traiter si l'accès est protégé.
C'est à dire que normalement l'utilisateur "root" a accès à tous les fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun "persmission denied"
-- "Je suis de formation théologique très rationnelle" Richard Hachel
Le 18/11/2015 19:24, Bernd a écrit :
pehache <pehache.7@gmail.com> wrote:
Le 16/11/2015 20:59, Bernd a écrit :
pehache <pehache.7@gmail.com> wrote:
Ajouter "sudo" avant la commande pour qu'elle s'exécute avec les
privilèges admin (root).
sudo find / -iname '*conflit*' | less
Je l'avais fait aussi en constatant que pleins d'accès retaient
interdits mais ça ne change rien. Il y en a (à vue de nez) peut-être
apparemment moins mais il en reste une palanquée.
Ah bon ? Pour voir j'en ai lancé un il y a 10mn, il tourne encore mais
pour l'instant il n'a produit que 2 lignes de ce genre :
=================================================== >> TOTO2:~ ******$ sudo find / -name prout
Password:
find: /dev/fd/3: Not a directory
find: /dev/fd/4: Not a directory
Il est pensable que rien ne sorte quand le fichier ou le dossier
n'existe pas. Mais si les éléments existent, la commande ne peut pas les
traiter si l'accès est protégé.
C'est à dire que normalement l'utilisateur "root" a accès à tous les
fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun
"persmission denied"
--
"Je suis de formation théologique très rationnelle"
Richard Hachel
Ajouter "sudo" avant la commande pour qu'elle s'exécute avec les privilèges admin (root).
sudo find / -iname '*conflit*' | less
Je l'avais fait aussi en constatant que pleins d'accès retaient interdits mais ça ne change rien. Il y en a (à vue de nez) peut-être apparemment moins mais il en reste une palanquée.
Ah bon ? Pour voir j'en ai lancé un il y a 10mn, il tourne encore mais pour l'instant il n'a produit que 2 lignes de ce genre : =================================================== >> TOTO2:~ ******$ sudo find / -name prout Password: find: /dev/fd/3: Not a directory find: /dev/fd/4: Not a directory
Il est pensable que rien ne sorte quand le fichier ou le dossier n'existe pas. Mais si les éléments existent, la commande ne peut pas les traiter si l'accès est protégé.
C'est à dire que normalement l'utilisateur "root" a accès à tous les fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun "persmission denied"
-- "Je suis de formation théologique très rationnelle" Richard Hachel
romer
pehache wrote:
C'est à dire que normalement l'utilisateur "root" a accès à tous les fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun "persmission denied"
C'est bien ce que j'essayais de faire dès le départ avant même de me tourner vers la liste mais il reste même avec sudo pas mal de "acces denied". Dommage - ça ne modifie pas les résultats mais ça les noie ds des pages d'avertissements. -- A+ -- Romer
pehache <pehache.7@gmail.com> wrote:
C'est à dire que normalement l'utilisateur "root" a accès à tous les
fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun
"persmission denied"
C'est bien ce que j'essayais de faire dès le départ avant même de me
tourner vers la liste mais il reste même avec sudo pas mal de "acces
denied".
Dommage - ça ne modifie pas les résultats mais ça les noie ds des pages
d'avertissements.
--
A+
--
Romer
C'est à dire que normalement l'utilisateur "root" a accès à tous les fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun "persmission denied"
C'est bien ce que j'essayais de faire dès le départ avant même de me tourner vers la liste mais il reste même avec sudo pas mal de "acces denied". Dommage - ça ne modifie pas les résultats mais ça les noie ds des pages d'avertissements. -- A+ -- Romer
Paul Gaborit
À (at) Wed, 18 Nov 2015 21:32:50 +0100, pehache écrivait (wrote):
C'est à dire que normalement l'utilisateur "root" a accès à tous les fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun "persmission denied"
Ce n'est pas toujours le cas : FreeBSD intègre des mécanismes qui peuvent bloquer les accès à certains fichiers même avec en étant 'root'.
Et, si j'ai bien compris, El Capitan utilise maintenant ce mécanisme (ou un autre à la sauce Apple) pour protéger une partie du système.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 18 Nov 2015 21:32:50 +0100,
pehache <pehache.7@gmail.com> écrivait (wrote):
C'est à dire que normalement l'utilisateur "root" a accès à tous les
fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun
"persmission denied"
Ce n'est pas toujours le cas : FreeBSD intègre des mécanismes qui
peuvent bloquer les accès à certains fichiers même avec en étant
'root'.
Et, si j'ai bien compris, El Capitan utilise maintenant ce
mécanisme (ou un autre à la sauce Apple) pour protéger une partie du
système.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 18 Nov 2015 21:32:50 +0100, pehache écrivait (wrote):
C'est à dire que normalement l'utilisateur "root" a accès à tous les fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun "persmission denied"
Ce n'est pas toujours le cas : FreeBSD intègre des mécanismes qui peuvent bloquer les accès à certains fichiers même avec en étant 'root'.
Et, si j'ai bien compris, El Capitan utilise maintenant ce mécanisme (ou un autre à la sauce Apple) pour protéger une partie du système.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
pehache
Le 19/11/2015 00:19, Paul Gaborit a écrit :
À (at) Wed, 18 Nov 2015 21:32:50 +0100, pehache écrivait (wrote):
C'est à dire que normalement l'utilisateur "root" a accès à tous les fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun "persmission denied"
Ce n'est pas toujours le cas : FreeBSD intègre des mécanismes qui peuvent bloquer les accès à certains fichiers même avec en étant 'root'.
Et, si j'ai bien compris, El Capitan utilise maintenant ce mécanisme (ou un autre à la sauce Apple) pour protéger une partie du système.
En tous cas je n'ai aucun message "access denied" si je lance sudo find /
(je suis bien sous 10.11)
-- "Je suis de formation théologique très rationnelle" Richard Hachel
Le 19/11/2015 00:19, Paul Gaborit a écrit :
À (at) Wed, 18 Nov 2015 21:32:50 +0100,
pehache <pehache.7@gmail.com> écrivait (wrote):
C'est à dire que normalement l'utilisateur "root" a accès à tous les
fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun
"persmission denied"
Ce n'est pas toujours le cas : FreeBSD intègre des mécanismes qui
peuvent bloquer les accès à certains fichiers même avec en étant
'root'.
Et, si j'ai bien compris, El Capitan utilise maintenant ce
mécanisme (ou un autre à la sauce Apple) pour protéger une partie du
système.
En tous cas je n'ai aucun message "access denied" si je lance
sudo find /
(je suis bien sous 10.11)
--
"Je suis de formation théologique très rationnelle"
Richard Hachel
À (at) Wed, 18 Nov 2015 21:32:50 +0100, pehache écrivait (wrote):
C'est à dire que normalement l'utilisateur "root" a accès à tous les fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun "persmission denied"
Ce n'est pas toujours le cas : FreeBSD intègre des mécanismes qui peuvent bloquer les accès à certains fichiers même avec en étant 'root'.
Et, si j'ai bien compris, El Capitan utilise maintenant ce mécanisme (ou un autre à la sauce Apple) pour protéger une partie du système.
En tous cas je n'ai aucun message "access denied" si je lance sudo find /
(je suis bien sous 10.11)
-- "Je suis de formation théologique très rationnelle" Richard Hachel
Paul Gaborit
À (at) Thu, 19 Nov 2015 01:12:05 +0100, pehache écrivait (wrote):
Le 19/11/2015 00:19, Paul Gaborit a écrit :
À (at) Wed, 18 Nov 2015 21:32:50 +0100, pehache écrivait (wrote):
C'est à dire que normalement l'utilisateur "root" a accès à tous les fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun "persmission denied"
Ce n'est pas toujours le cas : FreeBSD intègre des mécanismes qui peuvent bloquer les accès à certains fichiers même avec en étant 'root'.
Et, si j'ai bien compris, El Capitan utilise maintenant ce mécanisme (ou un autre à la sauce Apple) pour protéger une partie du système.
En tous cas je n'ai aucun message "access denied" si je lance sudo find /
(je suis bien sous 10.11)
Peut-être avez-vous désactivé certains mécanismes de sécurité...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 19 Nov 2015 01:12:05 +0100,
pehache <pehache.7@gmail.com> écrivait (wrote):
Le 19/11/2015 00:19, Paul Gaborit a écrit :
À (at) Wed, 18 Nov 2015 21:32:50 +0100,
pehache <pehache.7@gmail.com> écrivait (wrote):
C'est à dire que normalement l'utilisateur "root" a accès à tous les
fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun
"persmission denied"
Ce n'est pas toujours le cas : FreeBSD intègre des mécanismes qui
peuvent bloquer les accès à certains fichiers même avec en étant
'root'.
Et, si j'ai bien compris, El Capitan utilise maintenant ce
mécanisme (ou un autre à la sauce Apple) pour protéger une partie du
système.
En tous cas je n'ai aucun message "access denied" si je lance
sudo find /
(je suis bien sous 10.11)
Peut-être avez-vous désactivé certains mécanismes de sécurité...
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 19 Nov 2015 01:12:05 +0100, pehache écrivait (wrote):
Le 19/11/2015 00:19, Paul Gaborit a écrit :
À (at) Wed, 18 Nov 2015 21:32:50 +0100, pehache écrivait (wrote):
C'est à dire que normalement l'utilisateur "root" a accès à tous les fichiers/dossiers, donc le lancement avec sudo ne devrait produire aucun "persmission denied"
Ce n'est pas toujours le cas : FreeBSD intègre des mécanismes qui peuvent bloquer les accès à certains fichiers même avec en étant 'root'.
Et, si j'ai bien compris, El Capitan utilise maintenant ce mécanisme (ou un autre à la sauce Apple) pour protéger une partie du système.
En tous cas je n'ai aucun message "access denied" si je lance sudo find /
(je suis bien sous 10.11)
Peut-être avez-vous désactivé certains mécanismes de sécurité...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
cgallais
> > Non, je n'ai rien fait de ce genre depuis l'upgrade 10.9 --> 10.11
il s'agit de System Integrity Protection (SIP), qui semble avoir été rajouté depuis en effet, il aurait dû si c'est activé (car il est possible de désactiver), interdit à root l'accès à certains répertoires.
Pour desactiver completement SIP, je vous conseille cet page :
>
> Non, je n'ai rien fait de ce genre depuis l'upgrade 10.9 --> 10.11
il s'agit de System Integrity Protection (SIP), qui semble avoir été rajouté
depuis en effet, il aurait dû si c'est activé (car il est possible de
désactiver), interdit à root l'accès à certains répertoires.
Pour desactiver completement SIP, je vous conseille cet page :
> > Non, je n'ai rien fait de ce genre depuis l'upgrade 10.9 --> 10.11
il s'agit de System Integrity Protection (SIP), qui semble avoir été rajouté depuis en effet, il aurait dû si c'est activé (car il est possible de désactiver), interdit à root l'accès à certains répertoires.
Pour desactiver completement SIP, je vous conseille cet page :
