Discussion :

[nthl.roche]

Bonjour

Dans la commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

find ~/. -print

je ne saisis pas le rôle du point.

Merci d'avance de toute indication.

[frp31]

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


methode du vendredi pour vérifier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
$

[nthl.roche]

Merci.

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

[frp31]

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

[BlaireauOne]

Bonsoir,

Si vous tapez

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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'

[jlliagre]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Sve@r]

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)...

[jlliagre]

<hors-sujet>

• 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>

[Sve@r]

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 bash :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

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)...