Est-ce que la commande :
sudo find / -iname *zob*
permet de trouver tous les fichiers/dossiers visibles/cachés contenant
le mot "zob" en majuscules/minuscules sur tous les disques connectés et
actifs (disque interne, disques externes, clefs, etc) ?
Cenquiou d'avance.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
Le 20/10/17 à 20:16, Dieu Rê Pur / Pur Rê Méta-Maître et Dieu de l'Extrême a écrit :
Dieu Rê Pur / Pur Rê Méta-Maître et Dieu de l'Extrême wrote:
MV wrote:
Hello, Est-ce que la commande : sudo find / -iname *zob* permet de trouver tous les fichiers/dossiers visibles/cachés contenant le mot "zob" en majuscules/minuscules sur tous les disques connectés et actifs (disque interne, disques externes, clefs, etc) ? Cenquiou d'avance.
si tu cherche ton zop il est dans ton calbut...
pas zop, mais zob...
bite, et non zob -- J : Plus cher ou moins cher: je me casse de chez FT de toute facon. MZ: Attention, les pigeons voyageurs font des crottes... -+- in: Guide du Cabaliste Usenet - La Cabale voyage -+-
Le 20/10/17 à 20:16, Dieu Rê Pur / Pur Rê Méta-Maître et Dieu de
l'Extrême a écrit :
Dieu Rê Pur / Pur Rê Méta-Maître et Dieu de l'Extrême
<contact@meta-science.fr> wrote:
MV <mv@orange.invalid> wrote:
Hello,
Est-ce que la commande :
sudo find / -iname *zob*
permet de trouver tous les fichiers/dossiers visibles/cachés contenant
le mot "zob" en majuscules/minuscules sur tous les disques connectés et
actifs (disque interne, disques externes, clefs, etc) ?
Cenquiou d'avance.
si tu cherche ton zop il est dans ton calbut...
pas zop, mais zob...
bite, et non zob
--
J : Plus cher ou moins cher: je me casse de chez FT de toute facon.
MZ: Attention, les pigeons voyageurs font des crottes...
-+- in: Guide du Cabaliste Usenet - La Cabale voyage -+-
Le 20/10/17 à 20:16, Dieu Rê Pur / Pur Rê Méta-Maître et Dieu de l'Extrême a écrit :
Dieu Rê Pur / Pur Rê Méta-Maître et Dieu de l'Extrême wrote:
MV wrote:
Hello, Est-ce que la commande : sudo find / -iname *zob* permet de trouver tous les fichiers/dossiers visibles/cachés contenant le mot "zob" en majuscules/minuscules sur tous les disques connectés et actifs (disque interne, disques externes, clefs, etc) ? Cenquiou d'avance.
si tu cherche ton zop il est dans ton calbut...
pas zop, mais zob...
bite, et non zob -- J : Plus cher ou moins cher: je me casse de chez FT de toute facon. MZ: Attention, les pigeons voyageurs font des crottes... -+- in: Guide du Cabaliste Usenet - La Cabale voyage -+-
Thierry de Marseille
Le 21/10/17 à 01:34, pehache a écrit :
Je viens de tester, ça marche effectivement aussi sans les guillemets : j'en suis sur le cul, parce que ce n'est pas du tout le comportement auquel je suis habitué... Je suis à peu près sûr que sous la plupart des unix, dont Linux, il faut les guillemets. Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a parfois des (petites) différences entre les commandes entre les *BSD et les autres.
Linux n'est pas un Unix, tout le monde le sait -- % Oui. Peut importe l'académie. Ce qui compte dans fufe, c'est que le terme apparaisse dans le Petit Larousse (édition 1991) de Marc Bonnaud. -+- MS in: Guide du Cabaliste Usenet - L'académie Cabaliste -+-
Le 21/10/17 à 01:34, pehache a écrit :
Je viens de tester, ça marche effectivement aussi sans les guillemets :
j'en suis sur le cul, parce que ce n'est pas du tout le comportement
auquel je suis habitué... Je suis à peu près sûr que sous la plupart des
unix, dont Linux, il faut les guillemets.
Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a
parfois des (petites) différences entre les commandes entre les *BSD et
les autres.
Linux n'est pas un Unix, tout le monde le sait
--
%
Oui. Peut importe l'académie. Ce qui compte dans fufe, c'est
que le terme apparaisse dans le Petit Larousse (édition 1991)
de Marc Bonnaud.
-+- MS in: Guide du Cabaliste Usenet - L'académie Cabaliste -+-
Je viens de tester, ça marche effectivement aussi sans les guillemets : j'en suis sur le cul, parce que ce n'est pas du tout le comportement auquel je suis habitué... Je suis à peu près sûr que sous la plupart des unix, dont Linux, il faut les guillemets. Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a parfois des (petites) différences entre les commandes entre les *BSD et les autres.
Linux n'est pas un Unix, tout le monde le sait -- % Oui. Peut importe l'académie. Ce qui compte dans fufe, c'est que le terme apparaisse dans le Petit Larousse (édition 1991) de Marc Bonnaud. -+- MS in: Guide du Cabaliste Usenet - L'académie Cabaliste -+-
Thierry de Marseille
Le 21/10/17 à 11:56, Le Moustique a écrit :
Le 21/10/2017 à 09:52, Bernd a écrit :
Oui mais pas que. .zob ou .ZOB aussi
Ca reste des histoires de bits, quand même...
et d'interfesse -- grmmpfpspzf kdjfcnhjp boifuoi, qpdijniecn grrrrr!!! MOUUUUUAAAAAHHHHHHHH!!!!!!!!!!!!!!!!! A gna sage a Pingouin, a gna pas mailbomber le monsieur. -+- FJ in: Guide du Cabaliste Usenet - La Bancale en déroute -+-
Le 21/10/17 à 11:56, Le Moustique a écrit :
Le 21/10/2017 à 09:52, Bernd a écrit :
Oui mais pas que.
.zob ou .ZOB aussi
Ca reste des histoires de bits, quand même...
et d'interfesse
--
grmmpfpspzf kdjfcnhjp boifuoi, qpdijniecn grrrrr!!!
MOUUUUUAAAAAHHHHHHHH!!!!!!!!!!!!!!!!!
A gna sage a Pingouin, a gna pas mailbomber le monsieur.
-+- FJ in: Guide du Cabaliste Usenet - La Bancale en déroute -+-
et d'interfesse -- grmmpfpspzf kdjfcnhjp boifuoi, qpdijniecn grrrrr!!! MOUUUUUAAAAAHHHHHHHH!!!!!!!!!!!!!!!!! A gna sage a Pingouin, a gna pas mailbomber le monsieur. -+- FJ in: Guide du Cabaliste Usenet - La Bancale en déroute -+-
pehache
Le 26/10/2017 à 21:29, Thierry de Marseille a écrit :
Le 21/10/17 à 01:34, pehache a écrit :
Je viens de tester, ça marche effectivement aussi sans les guillemets : j'en suis sur le cul, parce que ce n'est pas du tout le comportement auquel je suis habitué... Je suis à peu près sûr que sous la plupart des unix, dont Linux, il faut les guillemets. Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a parfois des (petites) différences entre les commandes entre les *BSD et les autres.
Linux n'est pas un Unix,
J'ai écrit "unix" pas "Unix"
Le 26/10/2017 à 21:29, Thierry de Marseille a écrit :
Le 21/10/17 à 01:34, pehache a écrit :
Je viens de tester, ça marche effectivement aussi sans les guillemets :
j'en suis sur le cul, parce que ce n'est pas du tout le comportement
auquel je suis habitué... Je suis à peu près sûr que sous la plupart des
unix, dont Linux, il faut les guillemets.
Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a
parfois des (petites) différences entre les commandes entre les *BSD et
les autres.
Le 26/10/2017 à 21:29, Thierry de Marseille a écrit :
Le 21/10/17 à 01:34, pehache a écrit :
Je viens de tester, ça marche effectivement aussi sans les guillemets : j'en suis sur le cul, parce que ce n'est pas du tout le comportement auquel je suis habitué... Je suis à peu près sûr que sous la plupart des unix, dont Linux, il faut les guillemets. Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a parfois des (petites) différences entre les commandes entre les *BSD et les autres.
Linux n'est pas un Unix,
J'ai écrit "unix" pas "Unix"
Pascal J. Bourguignon
pehache writes:
Le 21/10/2017 à 00:04, MV a écrit :
pehache a attiré mon attention en écrivant :
Presque... Il faut mettre des guillemets autour de *zob* : sudo find / -iname "*zob*"
OK. J'explique pourquoi j'en ai eu besoin : j'ai (je ne sais pas du tout comment j'ai fait ça) installé cette saloperie de Mackeeper... La commande sudo find / -iname *mackeeper* (sans guillemets) m'a trouvé pas mal de fichiers (dont des fichiers dans un dossier invisible). Je regarderai demain avec les guillemets.
Je viens de tester, ça marche effectivement aussi sans les guillemets : j'en suis sur le cul, parce que ce n'est pas du tout le comportement auquel je suis habitué... Je suis à peu près sûr que sous la plupart des unix, dont Linux, il faut les guillemets.
Non, ça ne marche pas sans les quotes. La preuve: $ cd /tmp $ touch 'foozob' 'zobbar' $ find . -iname *zob* find: paths must precede expression: zobbar Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression] $ find . -iname '*zob*' ./foozob ./zobbar C'est mieux d'utiliser des simples quotes que des doubles quotes, pour pouvoir chercher des fichiers contenant certains caractères comme le dollar: $ touch '$afoo' $ find . -iname "$*foo" $ find . -iname '$*foo' ./$afoo
Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a parfois des (petites) différences entre les commandes entre les *BSD et les autres.
En l'occurence ce qui compte ici, c'est le shell, et sur MacOSX, par défaut, c'est bash 3.2 $ echo $BASH_VERSION 3.2.57(1)-release Alors il peut y avoir des différences à ce niveau entre MacOSX et Linux, mais seulement parce que Apple utiliser un ancien bash, tandis que les distributions Linux sont à jour avec un bash 4. Taper: man bash et bonne lecture! -- __Pascal J. Bourguignon http://www.informatimago.com
pehache <pehache.7@gmail.com> writes:
Le 21/10/2017 à 00:04, MV a écrit :
pehache <pehache.7@gmail.com> a attiré mon attention en écrivant :
Presque... Il faut mettre des guillemets autour de *zob* :
sudo find / -iname "*zob*"
OK.
J'explique pourquoi j'en ai eu besoin : j'ai (je ne sais pas du tout
comment j'ai fait ça) installé cette saloperie de Mackeeper...
La commande sudo find / -iname *mackeeper* (sans guillemets) m'a trouvé
pas mal de fichiers (dont des fichiers dans un dossier invisible).
Je regarderai demain avec les guillemets.
Je viens de tester, ça marche effectivement aussi sans les guillemets
: j'en suis sur le cul, parce que ce n'est pas du tout le comportement
auquel je suis habitué... Je suis à peu près sûr que sous la plupart
des unix, dont Linux, il faut les guillemets.
Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a
parfois des (petites) différences entre les commandes entre les *BSD
et les autres.
En l'occurence ce qui compte ici, c'est le shell, et sur MacOSX, par
défaut, c'est bash 3.2
$ echo $BASH_VERSION
3.2.57(1)-release
Alors il peut y avoir des différences à ce niveau entre MacOSX et Linux,
mais seulement parce que Apple utiliser un ancien bash, tandis que les
distributions Linux sont à jour avec un bash 4.
Taper: man bash
et bonne lecture!
--
__Pascal J. Bourguignon
http://www.informatimago.com
Presque... Il faut mettre des guillemets autour de *zob* : sudo find / -iname "*zob*"
OK. J'explique pourquoi j'en ai eu besoin : j'ai (je ne sais pas du tout comment j'ai fait ça) installé cette saloperie de Mackeeper... La commande sudo find / -iname *mackeeper* (sans guillemets) m'a trouvé pas mal de fichiers (dont des fichiers dans un dossier invisible). Je regarderai demain avec les guillemets.
Je viens de tester, ça marche effectivement aussi sans les guillemets : j'en suis sur le cul, parce que ce n'est pas du tout le comportement auquel je suis habitué... Je suis à peu près sûr que sous la plupart des unix, dont Linux, il faut les guillemets.
Non, ça ne marche pas sans les quotes. La preuve: $ cd /tmp $ touch 'foozob' 'zobbar' $ find . -iname *zob* find: paths must precede expression: zobbar Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression] $ find . -iname '*zob*' ./foozob ./zobbar C'est mieux d'utiliser des simples quotes que des doubles quotes, pour pouvoir chercher des fichiers contenant certains caractères comme le dollar: $ touch '$afoo' $ find . -iname "$*foo" $ find . -iname '$*foo' ./$afoo
Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a parfois des (petites) différences entre les commandes entre les *BSD et les autres.
En l'occurence ce qui compte ici, c'est le shell, et sur MacOSX, par défaut, c'est bash 3.2 $ echo $BASH_VERSION 3.2.57(1)-release Alors il peut y avoir des différences à ce niveau entre MacOSX et Linux, mais seulement parce que Apple utiliser un ancien bash, tandis que les distributions Linux sont à jour avec un bash 4. Taper: man bash et bonne lecture! -- __Pascal J. Bourguignon http://www.informatimago.com
pehache
Le 27/10/2017 à 00:20, Pascal J. Bourguignon a écrit :
pehache writes:
Le 21/10/2017 à 00:04, MV a écrit :
pehache a attiré mon attention en écrivant :
Presque... Il faut mettre des guillemets autour de *zob* : sudo find / -iname "*zob*"
OK. J'explique pourquoi j'en ai eu besoin : j'ai (je ne sais pas du tout comment j'ai fait ça) installé cette saloperie de Mackeeper... La commande sudo find / -iname *mackeeper* (sans guillemets) m'a trouvé pas mal de fichiers (dont des fichiers dans un dossier invisible). Je regarderai demain avec les guillemets.
Je viens de tester, ça marche effectivement aussi sans les guillemets : j'en suis sur le cul, parce que ce n'est pas du tout le comportement auquel je suis habitué... Je suis à peu près sûr que sous la plupart des unix, dont Linux, il faut les guillemets.
Non, ça ne marche pas sans les quotes. La preuve: $ cd /tmp $ touch 'foozob' 'zobbar' $ find . -iname *zob* find: paths must precede expression: zobbar Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression] $ find . -iname '*zob*' ./foozob ./zobbar
Si, chez moi ça marche sans les quotes, la preuve : ======================================== $ mkdir toto $ touch toto/titi $ find . -name "tit*" ./toto/titi $ find . -name tit* ./toto/titi ========================================
Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a parfois des (petites) différences entre les commandes entre les *BSD et les autres.
En l'occurence ce qui compte ici, c'est le shell, et sur MacOSX, par défaut, c'est bash 3.2 $ echo $BASH_VERSION 3.2.57(1)-release
Même version chez moi. Mais non ce n'est pas que le shell qui compte, d'autant que "find" est un utilitaire système indépendant du shell. Entre Linux et macOS le code source des utilitaires n'est pas le même et il peut y avoir des légères différences de comportement et de syntaxe. Différences qu'il y a toujours eu par exemple entre les unix de la branche BSD (dont est issu macOS) et ceux de la branche System V. Linux constitue à lui tout seul un autre branche. Chaque branche a son propre code source.
Le 27/10/2017 à 00:20, Pascal J. Bourguignon a écrit :
pehache <pehache.7@gmail.com> writes:
Le 21/10/2017 à 00:04, MV a écrit :
pehache <pehache.7@gmail.com> a attiré mon attention en écrivant :
Presque... Il faut mettre des guillemets autour de *zob* :
sudo find / -iname "*zob*"
OK.
J'explique pourquoi j'en ai eu besoin : j'ai (je ne sais pas du tout
comment j'ai fait ça) installé cette saloperie de Mackeeper...
La commande sudo find / -iname *mackeeper* (sans guillemets) m'a trouvé
pas mal de fichiers (dont des fichiers dans un dossier invisible).
Je regarderai demain avec les guillemets.
Je viens de tester, ça marche effectivement aussi sans les guillemets
: j'en suis sur le cul, parce que ce n'est pas du tout le comportement
auquel je suis habitué... Je suis à peu près sûr que sous la plupart
des unix, dont Linux, il faut les guillemets.
Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a
parfois des (petites) différences entre les commandes entre les *BSD
et les autres.
En l'occurence ce qui compte ici, c'est le shell, et sur MacOSX, par
défaut, c'est bash 3.2
$ echo $BASH_VERSION
3.2.57(1)-release
Même version chez moi.
Mais non ce n'est pas que le shell qui compte, d'autant que "find" est
un utilitaire système indépendant du shell. Entre Linux et macOS le code
source des utilitaires n'est pas le même et il peut y avoir des légères
différences de comportement et de syntaxe. Différences qu'il y a
toujours eu par exemple entre les unix de la branche BSD (dont est issu
macOS) et ceux de la branche System V. Linux constitue à lui tout seul
un autre branche. Chaque branche a son propre code source.
Le 27/10/2017 à 00:20, Pascal J. Bourguignon a écrit :
pehache writes:
Le 21/10/2017 à 00:04, MV a écrit :
pehache a attiré mon attention en écrivant :
Presque... Il faut mettre des guillemets autour de *zob* : sudo find / -iname "*zob*"
OK. J'explique pourquoi j'en ai eu besoin : j'ai (je ne sais pas du tout comment j'ai fait ça) installé cette saloperie de Mackeeper... La commande sudo find / -iname *mackeeper* (sans guillemets) m'a trouvé pas mal de fichiers (dont des fichiers dans un dossier invisible). Je regarderai demain avec les guillemets.
Je viens de tester, ça marche effectivement aussi sans les guillemets : j'en suis sur le cul, parce que ce n'est pas du tout le comportement auquel je suis habitué... Je suis à peu près sûr que sous la plupart des unix, dont Linux, il faut les guillemets.
Non, ça ne marche pas sans les quotes. La preuve: $ cd /tmp $ touch 'foozob' 'zobbar' $ find . -iname *zob* find: paths must precede expression: zobbar Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression] $ find . -iname '*zob*' ./foozob ./zobbar
Si, chez moi ça marche sans les quotes, la preuve : ======================================== $ mkdir toto $ touch toto/titi $ find . -name "tit*" ./toto/titi $ find . -name tit* ./toto/titi ========================================
Mais bon, les commandes unix d'OS X sont celles de freeBSD, et il y a parfois des (petites) différences entre les commandes entre les *BSD et les autres.
En l'occurence ce qui compte ici, c'est le shell, et sur MacOSX, par défaut, c'est bash 3.2 $ echo $BASH_VERSION 3.2.57(1)-release
Même version chez moi. Mais non ce n'est pas que le shell qui compte, d'autant que "find" est un utilitaire système indépendant du shell. Entre Linux et macOS le code source des utilitaires n'est pas le même et il peut y avoir des légères différences de comportement et de syntaxe. Différences qu'il y a toujours eu par exemple entre les unix de la branche BSD (dont est issu macOS) et ceux de la branche System V. Linux constitue à lui tout seul un autre branche. Chaque branche a son propre code source.
pehache
Le 27/10/2017 à 09:57, pehache a écrit :
Le 27/10/2017 à 00:20, Pascal J. Bourguignon a écrit :
pehache writes:
Le 21/10/2017 à 00:04, MV a écrit :
pehache a attiré mon attention en écrivant :
Presque... Il faut mettre des guillemets autour de *zob* : sudo find / -iname "*zob*"
OK. J'explique pourquoi j'en ai eu besoin : j'ai (je ne sais pas du tout comment j'ai fait ça) installé cette saloperie de Mackeeper... La commande sudo find / -iname *mackeeper* (sans guillemets) m'a trouvé pas mal de fichiers (dont des fichiers dans un dossier invisible). Je regarderai demain avec les guillemets.
Je viens de tester, ça marche effectivement aussi sans les guillemets : j'en suis sur le cul, parce que ce n'est pas du tout le comportement auquel je suis habitué... Je suis à peu près sûr que sous la plupart des unix, dont Linux, il faut les guillemets.
Non, ça ne marche pas sans les quotes. La preuve: $ cd /tmp $ touch 'foozob' 'zobbar' $ find . -iname *zob* find: paths must precede expression: zobbar Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression] $ find . -iname '*zob*' ./foozob ./zobbar
Si, chez moi ça marche sans les quotes, la preuve : ======================================== > $ mkdir toto $ touch toto/titi $ find . -name "tit*" ./toto/titi $ find . -name tit* ./toto/titi ========================================
J'ai compris ce qui se passait après avoir constaté exactement la même chose sur Linux, et ça n'a en fait ici rien à voir avec des différences de comportement entre unix différents. Dans mon exemple, le fichier à rechercher est dans un sous-dossier alors que dans le tien il est dans le dossier courant. Quand on écrit l'expression à rechercher sans les guillemets, le shell tente en premier lieu de faire une expansion dans le dossier courant : Dans ton cas, *zob* est expandu en foozob zoobar donc la commande qui est réellement exécutée par le shell est find . -iname foozob zobbar zobbar apparait comme un paramètre supplémentaire que find ne sait pas interpréter, d'où le message d'erreur. Dans mon cas, le shell ne trouve aucune correspondance dans le dossier courant pour expandre tit* du coup l'expression n'est pas modifiée et est passée telle quelle à find. La commande exécutée est alors bien find . -name tit* et c'est find qui va s'occuper d'expandre tit* dans tous les répertoires parcourus La conclusion : il n'est pas obligatoire de mettre l'expression à rechercher entre quotes, car en l'absence de correspondance dans le dossier courant le shell la passe telle quelle à find (alors que je pensais que l'absence de correspondance provoquerait une erreur de type "no match"). Mais c'est bien évidemment la pratique recommandée (et toujours utilisée en pratique) pour empêcher toute expansion par le shell. Car au mieux l'expansion par le shell produit une erreur, mais au pire elle altére la recherche sans qu'on s'en rende compte. Si dans ton exemple tu avais juste le fichier foozob mais pas zobbar, le shell aurait expandu *zob* en foozob et la commande réellement exécutée serait find . -iname foozob Donc find trouverait bien le foozob du dossier courant (sans erreur) mais ne rechercherait en fait que foozob partout, au lieu de tous les fichiers contenant zob. Un fichier zobbar dans un sous-dossier passerait entre les mailles du filet.
Le 27/10/2017 à 09:57, pehache a écrit :
Le 27/10/2017 à 00:20, Pascal J. Bourguignon a écrit :
pehache <pehache.7@gmail.com> writes:
Le 21/10/2017 à 00:04, MV a écrit :
pehache <pehache.7@gmail.com> a attiré mon attention en écrivant :
Presque... Il faut mettre des guillemets autour de *zob* :
sudo find / -iname "*zob*"
OK.
J'explique pourquoi j'en ai eu besoin : j'ai (je ne sais pas du tout
comment j'ai fait ça) installé cette saloperie de Mackeeper...
La commande sudo find / -iname *mackeeper* (sans guillemets) m'a
trouvé
pas mal de fichiers (dont des fichiers dans un dossier invisible).
Je regarderai demain avec les guillemets.
Je viens de tester, ça marche effectivement aussi sans les guillemets
: j'en suis sur le cul, parce que ce n'est pas du tout le comportement
auquel je suis habitué... Je suis à peu près sûr que sous la plupart
des unix, dont Linux, il faut les guillemets.
J'ai compris ce qui se passait après avoir constaté exactement la même
chose sur Linux, et ça n'a en fait ici rien à voir avec des différences
de comportement entre unix différents.
Dans mon exemple, le fichier à rechercher est dans un sous-dossier alors
que dans le tien il est dans le dossier courant. Quand on écrit
l'expression à rechercher sans les guillemets, le shell tente en premier
lieu de faire une expansion dans le dossier courant :
Dans ton cas,
*zob*
est expandu en
foozob zoobar
donc la commande qui est réellement exécutée par le shell est
find . -iname foozob zobbar
zobbar apparait comme un paramètre supplémentaire que find ne sait pas
interpréter, d'où le message d'erreur.
Dans mon cas, le shell ne trouve aucune correspondance dans le dossier
courant pour expandre
tit*
du coup l'expression n'est pas modifiée et est passée telle quelle à
find. La commande exécutée est alors bien
find . -name tit*
et c'est find qui va s'occuper d'expandre tit* dans tous les répertoires
parcourus
La conclusion : il n'est pas obligatoire de mettre l'expression à
rechercher entre quotes, car en l'absence de correspondance dans le dossier
courant le shell la passe telle quelle à find (alors que je pensais que
l'absence de correspondance provoquerait une erreur de type "no match").
Mais c'est bien évidemment la pratique recommandée (et toujours utilisée
en pratique) pour empêcher toute expansion par le shell. Car au mieux
l'expansion par le shell produit une erreur, mais au pire elle altére la
recherche sans qu'on s'en rende compte.
Si dans ton exemple tu avais juste le fichier foozob mais pas zobbar, le
shell aurait expandu
*zob*
en
foozob
et la commande réellement exécutée serait
find . -iname foozob
Donc find trouverait bien le foozob du dossier courant (sans erreur) mais
ne rechercherait en fait que foozob partout, au lieu de tous les fichiers
contenant zob. Un fichier zobbar dans un sous-dossier passerait entre les
mailles du filet.
Le 27/10/2017 à 00:20, Pascal J. Bourguignon a écrit :
pehache writes:
Le 21/10/2017 à 00:04, MV a écrit :
pehache a attiré mon attention en écrivant :
Presque... Il faut mettre des guillemets autour de *zob* : sudo find / -iname "*zob*"
OK. J'explique pourquoi j'en ai eu besoin : j'ai (je ne sais pas du tout comment j'ai fait ça) installé cette saloperie de Mackeeper... La commande sudo find / -iname *mackeeper* (sans guillemets) m'a trouvé pas mal de fichiers (dont des fichiers dans un dossier invisible). Je regarderai demain avec les guillemets.
Je viens de tester, ça marche effectivement aussi sans les guillemets : j'en suis sur le cul, parce que ce n'est pas du tout le comportement auquel je suis habitué... Je suis à peu près sûr que sous la plupart des unix, dont Linux, il faut les guillemets.
Non, ça ne marche pas sans les quotes. La preuve: $ cd /tmp $ touch 'foozob' 'zobbar' $ find . -iname *zob* find: paths must precede expression: zobbar Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression] $ find . -iname '*zob*' ./foozob ./zobbar
Si, chez moi ça marche sans les quotes, la preuve : ======================================== > $ mkdir toto $ touch toto/titi $ find . -name "tit*" ./toto/titi $ find . -name tit* ./toto/titi ========================================
J'ai compris ce qui se passait après avoir constaté exactement la même chose sur Linux, et ça n'a en fait ici rien à voir avec des différences de comportement entre unix différents. Dans mon exemple, le fichier à rechercher est dans un sous-dossier alors que dans le tien il est dans le dossier courant. Quand on écrit l'expression à rechercher sans les guillemets, le shell tente en premier lieu de faire une expansion dans le dossier courant : Dans ton cas, *zob* est expandu en foozob zoobar donc la commande qui est réellement exécutée par le shell est find . -iname foozob zobbar zobbar apparait comme un paramètre supplémentaire que find ne sait pas interpréter, d'où le message d'erreur. Dans mon cas, le shell ne trouve aucune correspondance dans le dossier courant pour expandre tit* du coup l'expression n'est pas modifiée et est passée telle quelle à find. La commande exécutée est alors bien find . -name tit* et c'est find qui va s'occuper d'expandre tit* dans tous les répertoires parcourus La conclusion : il n'est pas obligatoire de mettre l'expression à rechercher entre quotes, car en l'absence de correspondance dans le dossier courant le shell la passe telle quelle à find (alors que je pensais que l'absence de correspondance provoquerait une erreur de type "no match"). Mais c'est bien évidemment la pratique recommandée (et toujours utilisée en pratique) pour empêcher toute expansion par le shell. Car au mieux l'expansion par le shell produit une erreur, mais au pire elle altére la recherche sans qu'on s'en rende compte. Si dans ton exemple tu avais juste le fichier foozob mais pas zobbar, le shell aurait expandu *zob* en foozob et la commande réellement exécutée serait find . -iname foozob Donc find trouverait bien le foozob du dossier courant (sans erreur) mais ne rechercherait en fait que foozob partout, au lieu de tous les fichiers contenant zob. Un fichier zobbar dans un sous-dossier passerait entre les mailles du filet.
g4fleurot
pehache a écrit :
Quitte à utiliser une GUI, pourquoi ne pas utiliser directement la recherche spotlight dans le Finder ?
Je viens de faire une découverte dans mes bouquins. On peut exploiter spotlight dans le terminal avec la commande mdfind. Il n'y a pas de man, mais en entrant mdfind envoi dans le terminal, on obtient un mode d'emploi succint. -- Gérard FLEUROT plus un
pehache a écrit :
Quitte à utiliser une GUI, pourquoi ne pas utiliser directement la
recherche spotlight dans le Finder ?
Je viens de faire une découverte dans mes bouquins.
On peut exploiter spotlight dans le terminal avec la commande mdfind.
Il n'y a pas de man, mais en entrant mdfind envoi dans le terminal, on
obtient un mode d'emploi succint.
Quitte à utiliser une GUI, pourquoi ne pas utiliser directement la recherche spotlight dans le Finder ?
Je viens de faire une découverte dans mes bouquins. On peut exploiter spotlight dans le terminal avec la commande mdfind. Il n'y a pas de man, mais en entrant mdfind envoi dans le terminal, on obtient un mode d'emploi succint. -- Gérard FLEUROT plus un
gilbert.olivier
Fleuger wrote:
pehache a écrit :
Quitte à utiliser une GUI, pourquoi ne pas utiliser directement la recherche spotlight dans le Finder ?
Je viens de faire une découverte dans mes bouquins. On peut exploiter spotlight dans le terminal avec la commande mdfind. Il n'y a pas de man, mais en entrant mdfind envoi dans le terminal, on obtient un mode d'emploi succint.
Si si, man mdfind donne bien le descriptif de la commande chez moi (testé sur Mawericks). -- Gilbert
Fleuger <g4fleurot@free.fr> wrote:
pehache a écrit :
> Quitte à utiliser une GUI, pourquoi ne pas utiliser directement la
> recherche spotlight dans le Finder ?
Je viens de faire une découverte dans mes bouquins.
On peut exploiter spotlight dans le terminal avec la commande mdfind.
Il n'y a pas de man, mais en entrant mdfind envoi dans le terminal, on
obtient un mode d'emploi succint.
Si si, man mdfind donne bien le descriptif de la commande chez moi
(testé sur Mawericks).
Quitte à utiliser une GUI, pourquoi ne pas utiliser directement la recherche spotlight dans le Finder ?
Je viens de faire une découverte dans mes bouquins. On peut exploiter spotlight dans le terminal avec la commande mdfind. Il n'y a pas de man, mais en entrant mdfind envoi dans le terminal, on obtient un mode d'emploi succint.
Si si, man mdfind donne bien le descriptif de la commande chez moi (testé sur Mawericks). -- Gilbert
Pascal J. Bourguignon
pehache writes:
Non, ça ne marche pas sans les quotes. La preuve: $ cd /tmp $ touch 'foozob' 'zobbar' $ find . -iname *zob* find: paths must precede expression: zobbar Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression] $ find . -iname '*zob*' ./foozob ./zobbar
Si, chez moi ça marche sans les quotes, la preuve :
Non, ça ne marche pas. Ajoute un: touch ./titus ./tits # et tu verras!
======================================== > $ mkdir toto $ touch toto/titi $ find . -name "tit*" ./toto/titi $ find . -name tit* ./toto/titi ======================================== Mais non ce n'est pas que le shell qui compte, d'autant que "find" est un utilitaire système indépendant du shell.
Lis man bash! Les metacaractères sont interprétés par le shell, pas par les commandes! Ce n'est pas MS-DOS!!! -- __Pascal J. Bourguignon http://www.informatimago.com
Non, ça ne marche pas sans les quotes. La preuve: $ cd /tmp $ touch 'foozob' 'zobbar' $ find . -iname *zob* find: paths must precede expression: zobbar Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression] $ find . -iname '*zob*' ./foozob ./zobbar
Si, chez moi ça marche sans les quotes, la preuve :
Non, ça ne marche pas. Ajoute un: touch ./titus ./tits # et tu verras!
======================================== > $ mkdir toto $ touch toto/titi $ find . -name "tit*" ./toto/titi $ find . -name tit* ./toto/titi ======================================== Mais non ce n'est pas que le shell qui compte, d'autant que "find" est un utilitaire système indépendant du shell.
Lis man bash! Les metacaractères sont interprétés par le shell, pas par les commandes! Ce n'est pas MS-DOS!!! -- __Pascal J. Bourguignon http://www.informatimago.com
