Commande find .

Version imprimable

08/08/2014, 16h52
nthl.roche

Commande find .

Bonjour

Dans la commande suivante :

Code:

find ~/. -print

je ne saisis pas le rôle du point.

Merci d'avance de toute indication.

dans ce cas précis je pense qu'il ne sert à rien du tout

methode du vendredi pour vérifier :

Code:

1
2
3
4
5
6
$ df -h . | tail -1 
/dev/wd0k     75.4G   29.5G   42.0G    41%    /home
$
$ if [ `expr $(( $(find ~/. | wc -l) - $(find ~/ |wc -l) ))` -eq 0 ] ; then echo pas de differences ; else echo ca change quelquechose ; fi 
pas de differences
$

08/08/2014, 19h01
nthl.roche

Merci.

Quel rôle pourrait jouer ce point sinon dans des situations de ce genre ?
08/08/2014, 19h28
frp31

par exemple les fichier cachés serait find ~/.*là le point devient pertinent parce qu'il devient 1 caractère de chaine
09/08/2014, 23h43
BlaireauOne

Répertoire courant = . - Répertoire parent = ..
Bonsoir,

Si vous tapez
Code:

1 2 3 find --help find [PATH]...
bash prend la commande find sans argument (par défaut répertoire courant) = find . -print,
le . signifiant 'répertoire courant'

comme .. signifie 'répertoire parent'

Comme déjà sous entendu par les réponses de frp31, le "-print" ne sert à rien non plus dans ce cas précis, "-print" étant l'action par défaut de find, la commande initiale peut donc être simplifiée en

Code:

find ~

En revanche, supprimer le "." modifie en le simplifiant le format de sortie car dans le premier cas, le répertoire "." est ajouté aux résultats:
Code:

1 2 3 4 5 6 7 8 9 10 $ find ~/. | head -4 /home/guest/. /home/guest/./.sh_history /home/guest/./Pictures /home/guest/./Documents $ find ~ | head -4 /home/guest /home/guest/.sh_history /home/guest/Pictures /home/guest/Documents

21/08/2014, 15h08
mongolic

. = répertoire courant

quand tu fais un ls -artl, tu as deux entrées qui apparaissent toujours : . et ..
. est le répertoire courant
.. est le répertoire parent

~/. est donc équivalent à ~

Tu peux faire

Code:

find . -name "toto"

pour chercher le fichier toto dans le répertoire courant (celui ou tu es positionné).
ou

Code:

find .. -name "toto"

pour chercher le fichier toto dans le répertoire parent (celui ou tu es positionné).

Dans un autre cas de figure, . signifie shell courant

Code:

. mon_script.sh

signifie d'exécuter mon_script dans le shell courant.

enfin, en début de nom de fichier. signifie que le fichier est caché , par exemple le fichier .profile. Il faut utiliser obligatoirement l'option - a de la commande ls pour afficher un fichier caché.
21/08/2014, 16h19
Flodelarab

Bonjour,

Hum. "-a" fonctionne avec "ls", pas avec find, pour lequel "-a" signifie "and", opération logique "et" entre les conditions sur les fichiers.

De plus, si tu es en train de conseiller d'utiliser "ls" dans un script, je connais un mec qui guette avec sa massue, prêt à sortir et à punir l'outrecuidant qui oserait faire cela ;) :lol:
27/08/2014, 09h48
Sve@r
Citation:

Envoyé par nthl.roche

Quel rôle pourrait jouer ce point sinon dans des situations de ce genre ?

Bonjour

Point (utilisé comme nom de fichier et non comme appel de script pour lequel je pense qu'il est plus parlant d'utiliser la commande source) sert à nommer ton dossier courant chaque fois qu'un nom de dossier est nécessaire dans une commande et que justement tu veux lui indiquer "dossier courant" comme nom de dossier à ce moment là. En effet, imagine que tu te trouves dans /home/popol et que tu veuilles nommer ce dossier pour les besoins d'une action. Quelles solutions as-tu ?
1. donner le nom complet => /home/popol (ok mais à force ça va vite devenir chiant)
2. remonter d'un niveau pour avoir accès à "popol" depuis le niveau du dessus => ../popol (ok mais déjà tu utilises le raccourci ".." signifiant "au-dessus")
3. utiliser la commande pwd ou la variable $PWD (à la limite, s'il n'y a rien de plus simple...)
4. donner tout simplement le raccourci "." ce qui est (à mon avis) le plus simple
Le meilleur exemple que je connaisse est la copie de n fichiers d'un coup (dans ce cas le dernier nom de la liste des fichiers doit-être impérativement le nom du dossier de destination) dans le dossier courant. Il te faut alors un nom pour ce dossier courant et c'est alors "point" => cp /etc/passwd /etc/group /etc/inittab ..

Un autre exemple tout aussi parlant est l'appel d'un script situé dans le dossier courant et que ce dossier ne se trouve pas dans le PATH (la variable qui indique les différents emplacements possibles des exécutables). Dans ce cas, il est nécesaire de donner le nom du dossier contenant le script et si ce dossier se trouve être le dossier courant, alors le plus simple est de le nommer "point" => ./monscript.sh (à ne pas confondre avec . monscript.sh pour lequel je préfère utiliser source monscript.sh)...
27/08/2014, 22h08
jlliagre
<hors-sujet>
Citation:
Envoyé par Sve@r

donner le nom complet => /home/popol (ok mais à force ça va vite devenir chiant)
...
donner tout simplement le raccourci "." ce qui est (à mon avis) le plus simple
...
à ne pas confondre avec . monscript.sh pour lequel je préfère utiliser source monscript.sh
N'y-a-t'il pas une petite contradiction a préférer . dans un cas et source dans l'autre ;-)

Je continue à penser que source est une régression et diminue la lisibilité des scripts par rapport au . original.

</hors-sujet>

Citation:

Envoyé par jlliagre

N'y-a-t'il pas une petite contradiction a préférer . dans un cas et source dans l'autre ;-)

Non, pas pour moi. Déjà justement tu parle d'un cas et de l'autre donc ce sont bien deux cas différents qui méritent d'avoir pour chacun des token différents.
Dans le premierc cas (nom de dossier), le point est (pour moi) super pratique à utiliser. Mais son utilisation est quasiment en ligne de commandes (en effet, il est rare que mes scripts aient besoin de travailler sur un dossier, et encore plus rare que le dossier en question soit justement celui dans lequel je me trouve quand je lance le script).
Donc c'est souvent du ./monScript.sh, ou bien du cp fic1 fic2 fic2 . pour lesquels je me verrais mal faire $PWD/monScript.sh ou bien du cp fic1 fic2 fic2 $(pwd). Et puis c'est bien aussi dans la continuité de "..".

En revanche, dans le second cas, l'instruction "point" qu'on verra, elle, plutôt dans les scripts (même s'il m'est déjà arrivé de faire . .profile) devienda (pour moi) source de malaise. Déjà il peut y avoir parfois quiproquo
Code:

1 2 3 4 #!/bin/sh . /fonctions.sh # Je charge le script "/fonctions.sh" (oui je suis un porc qui travaille à la racine) dans mon script courant ./racine.sh # J'appelle le script "racine.sh" qui se trouve dans mon dossier courant ... (suite du script)
Bon c'est un exemple extrémiste et volontairement renforcé par une situation peu crédible (il faut vraiment le vouloir de mettre un fichier "fonctions.sh" à la racine) mais pas impossible. Bref puisque "point" est déjà ancré comme "nom du dossier courant" autant utiliser autre chose comme instruction.

Ceci dit, comme je l'ai mentionné, quand je suis en ligne de commande et que je veux recharger le .profile, je taperai plus volontier . .profile que source .profile. Donc j'affinerai en fait mon discours en disant que je préfère utiliser source uniquement quand je suis dans un script...

Citation:

Envoyé par jlliagre

Je continue à penser que source est une régression et diminue la lisibilité des scripts par rapport au . original.

Pourtant c'est un mot entier, plus ou moins parlant (selon chacun) mais qui a au-moins le mérite de devenir alors une instruction (écrite avec des lettres) au même titre que shift, set ou autres read. Voire même donner naissance à une phraséologie qui l'intègrerait dans le langage courant. J'ai d'ailleurs déjà vu sur ce forum des intervenants parler de "sourcer" un script.
On peut pousuivre aussi un débat analogue entre test ... et [ ... ] (perso je préfère test)...

28/08/2014, 01h05
jlliagre

Citation:

Envoyé par Sve@r

On peut pousuivre aussi un débat analogue entre test ... et [ ... ] (perso je préfère test)...

Ouch, tu préfères test !!! Tu es donc irrécupérable ...

J'abandonne avant que tu proposes begin et end pour { et }, plus, minus, multiply, divide pour + , -, *, /, not pour ! et homedir pour ~ ... ;)

On voit que tu n'a pas commencé à travailler avec des terminaux connectés à des modems 300 Bauds :aie:
28/08/2014, 09h03
Sve@r

Citation:

Envoyé par jlliagre

Ouch, tu préfères test !!! Tu es donc irrécupérable ...

Mais ai-je besoin d'être récupéré ?
En fait c'est pour donner une certaine unité (car à l'instar des grands physiciens, je recherche la théorie de l'unification :D) dans l'alternative if qui devient alors de façon générale if commande qu'on pourra appliquer alors à if ls, if grep, if read et éventuellement if test (et idem pour while et until). Quand on enseigne le shell à des étudiants en informatique, c'est plus facile de leur apprendre ainsi...
Ensuite, bien entendu, je leur explique aussi le raccourci de test et ensuite... ben chacun est libre:yaisse3:

Citation:

Envoyé par jlliagre

J'abandonne avant que tu proposes begin et end pour { et }, plus, minus, multiply, divide pour + , -, *, /, not pour ! et homedir pour ~ ... ;)

Quel plaisantin :mouarf3:
C'est pas moi qui ai proposé source et là tu n'as cité que des séparateurs, des opérateurs et un raccourci de contenu (mais pour celui-ci, dans les scripts je préfère en effet utiliser $HOME ;)) et non des instructions. En fait il me semble que . était la seule instruction qui n'était pas représentée par un mot (instruction un petit peu complexe je veux dire parce que sinon tu vas trouver à me chambrer avec affect 5 to a pour remplacer a=5...:kill:)

Mais plus sérieusement, c'est aussi parce qu'un script est 100 fois plus souvent lu qu'écrit que j'aime bien y mettre des instruction explicites (surtout si le relecteur de demain c'est toujours moi :lol:)...

Citation:

Envoyé par jlliagre

On voit que tu n'a pas commencé à travailler avec des terminaux connectés à des modems 300 Bauds :aie:

9800 puis, bonheur suprème, un jour on a pu les passer en 19600...
28/08/2014, 14h19
Flodelarab

Il faut préférer test à [ ] ! Ce n'est pas le même cas que begin ... end où des mots remplacent des éléments de ponctuation. [ ] est un raccourci pour une vraie fonction. Ce n'est pas de la ponctuation.

Du coup, Les internautes oublient que l'ont peut faire if grep ou if mon_script car ils confondent if ( ) syntaxe obligatoire en java ou c++... avec if [ ], syntaxe optionnelle, raccourci de test.

En plus, je trouve cela drôle de fustiger un retour à BEGIN END pour un script bash qui fait des blocs if fi, do done ...