Bonjour
Dans la commande suivante :
je ne saisis pas le rôle du point.
Code : Sélectionner tout - Visualiser dans une fenêtre à part find ~/. -print
Merci d'avance de toute indication.
Bonjour
Dans la commande suivante :
je ne saisis pas le rôle du point.
Code : Sélectionner tout - Visualiser dans une fenêtre à part find ~/. -print
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 : 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 $
Merci.
Quel rôle pourrait jouer ce point sinon dans des situations de ce genre ?
par exemple les fichier cachés serait find ~/.*là le point devient pertinent parce qu'il devient 1 caractère de chaine
Bonsoir,
Si vous tapezbash prend la commande find sans argument (par défaut répertoire courant) = find . -print,
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 find --help find [PATH]...
le . signifiant 'répertoire courant'
comme .. signifie 'répertoire parent'
Loi de Murphy:
La Théorie c'est quand ça ne marche pas mais que l'on sait pourquoi.
La Pratique c'est quand ça marche mais qu'on ne sait pas pourquoi.
Quand la théorie rejoint la pratique ça ne marche pas et on ne sait pas pourquoi.
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
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 find ~
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
ɹǝsn *sıɹɐlos*
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
pour chercher le fichier toto dans le répertoire courant (celui ou tu es positionné).
Code : Sélectionner tout - Visualiser dans une fenêtre à part find . -name "toto"
ou
pour chercher le fichier toto dans le répertoire parent (celui ou tu es positionné).
Code : Sélectionner tout - Visualiser dans une fenêtre à part find .. -name "toto"
Dans un autre cas de figure, . signifie shell courant
signifie d'exécuter mon_script dans le shell courant.
Code : Sélectionner tout - Visualiser dans une fenêtre à part . mon_script.sh
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é.
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
Cette réponse vous apporte quelque chose ? Cliquez sur en bas à droite du message.
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 ?
- donner le nom complet => /home/popol (ok mais à force ça va vite devenir chiant)
- 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")
- utiliser la commande pwd ou la variable $PWD (à la limite, s'il n'y a rien de plus simple...)
- 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)...
Mon Tutoriel sur la programmation «Python»
Mon Tutoriel sur la programmation «Shell»
Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
Et on poste ses codes entre balises [code] et [/code]
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
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.
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)
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...
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)...
Mon Tutoriel sur la programmation «Python»
Mon Tutoriel sur la programmation «Shell»
Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
Et on poste ses codes entre balises [code] et [/code]
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
ɹǝsn *sıɹɐlos*
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 ) 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
Quel plaisantin
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...)
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 )...
9800 puis, bonheur suprème, un jour on a pu les passer en 19600...
Mon Tutoriel sur la programmation «Python»
Mon Tutoriel sur la programmation «Shell»
Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
Et on poste ses codes entre balises [code] et [/code]
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 ...
Cette réponse vous apporte quelque chose ? Cliquez sur en bas à droite du message.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager