Question (de débutant) sur une commande unix

Le
Francois
Bonjour à tous,

pardon pour cette question de débutant, je ne comprends ceci fait en
ligne de commandes. Je suppose que je suis dans un répertoire quelconque
de mon home.

-
xxx$ find . -type f -name notes*
./Releve_BacS/notes/notes.ods
./Releve_BacS/notes/notes.tex
./Releve_BacS/notes/notes.csv
-

Le système d'exploitation a trouvé 3 fichiers avec un nom de la forme
notes*. Ils sont inclus dans ./Releve_BacS/notes/.Jusque là tout va bien.

Je vais dans le répertoire ./Releve_BacS/ et je lance la même recherche
de cet endroit.

-
xxx$ cd Releve_BacS/
xxx/Releve_BacS$ find . -type f -name notes*
xxx/Releve_BacS$ [pas de fichiers trouvés]
-

Lors de cette deuxième recherche, pas de fichiers avec un nom de la
forme notes*, alors que je m'attendais à une réponse comme :

-
./notes/notes.ods
./notes/notes.tex
./notes/notes.csv
-

Pourrais-je avoir une explication ?

Merci d'avance.


François
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
YBM
Le #5950761
xxx$ find . -type f -name notes*
./Releve_BacS/notes/notes.ods
./Releve_BacS/notes/notes.tex
./Releve_BacS/notes/notes.csv

xxx$ cd Releve_BacS/
xxx/Releve_BacS$ find . -type f -name notes*
xxx/Releve_BacS$ [pas de fichiers trouvés]


normal : c'est le shell qui interprète notes* et, comme il y a
un répertoire dont le nom commence par notes dans le répertoire
courants, la commande exécutée est :

find . -type f -name notes

(facile à voir : mets un echo devant)

pour ne pas avoir ce problème il faut TOUJOURS protéger
les arguments de find contenant des jokers :

find . -type f -name 'notes*'

c'est une différence importante entre les shells unix et les shells
dos/windows : sous UNIX ce sont les shells qui interprètent les jokers
et transmettent des chemins d'accès à des fichiers correspondants,
la commande ne sait pas que tu as utilisé un joker ou donné
explicitement une liste de chemins. Sous DOS/Windows c'est la commande
qui traite (ou non ...) les jokers.

une manière de le voir est de faire 'echo *' (ou l'équivalent) sur les
deux systèmes :

c:whatever> echo *.*
*.*
$ echo *
bidule.txt machin.c README

Le principal avantage est que toute commande qui est en mesure
d'accepter une suite de chemins est automatiquement exploitable
avec des jokers, et que cette interprétation des jokers étant
faite en un endroit unique, elle donne toujours le même résultat.

Le seul inconvénient sont qu'il faut faire gaffe avec des
commandes dont les arguments peuvent contenir des jokers à
interpréter par la commande elle-même.

Francois
Le #5950751
normal : c'est le shell qui interprète notes* et, comme il y a
un répertoire dont le nom commence par notes dans le répertoire
courants, la commande exécutée est :

find . -type f -name notes

(facile à voir : mets un echo devant)


C'est effectivement ce que tu dis qu'il se passe, mais je ne comprends
pas pourquoi, sous prétexte qu'il y a un répertoire notes dans le
répertoire courant, le * disparaît ?


pour ne pas avoir ce problème il faut TOUJOURS protéger
les arguments de find contenant des jokers :

find . -type f -name 'notes*'


J'en prends bonne note, merci.


c'est une différence importante entre les shells unix et les shells
dos/windows : sous UNIX ce sont les shells qui interprètent les jokers
et transmettent des chemins d'accès à des fichiers correspondants,
la commande ne sait pas que tu as utilisé un joker ou donné
explicitement une liste de chemins. Sous DOS/Windows c'est la commande
qui traite (ou non ...) les jokers.


Je comprends pas trop.


Merci pour la réponse. Je vais essayer de creuser la question.


François

YBM
Le #5950741
normal : c'est le shell qui interprète notes* et, comme il y a
un répertoire dont le nom commence par notes dans le répertoire
courants, la commande exécutée est :

find . -type f -name notes

(facile à voir : mets un echo devant)


C'est effectivement ce que tu dis qu'il se passe, mais je ne comprends
pas pourquoi, sous prétexte qu'il y a un répertoire notes dans le
répertoire courant, le * disparaît ?


C'est l'inverse qu'il faut comprendre : c'est parce que dans le
répertoire courant précédent il n'y a AUCUN fichier dont le nom
commence par "notes" que l'* ne "disparaît" pas : faute de mieux
le shell transmet l'argument tel que à la commande. À mon avis
il ferait mieux de refuser en sortant une erreur du genre
'bsh: notes* : no match' ou au moins un warning.

Dans le second répertoire, il existe un répertoire nommé "notes",
donc le shell remplace "notes*" par la liste à un élément "notes"
imagine que tu fasses la même chose dans le répertoire où sont
situés les fichiers eux-même, le shell aurait exécuté :

find . -type f -name notes.ods notes.tex notes.csv

ce qui aurait conduit, je pense, à une erreur de syntaxe pour
find.

Je comprends pas trop.


un exemple : sous unix un éditeur est capable de considérer aussi
bien un que plusieurs fichiers, appelons le vi, tandis que sous
dos un hypothétique edit.com est pareil.

Aucun des deux n'a été prévu pour prendre en compte des jokers
comme * ou ? dans leurs arguments.

Sous UNIX : vi *txt marche (puisque le *txt est traité par le shell)
Sous DOS : edit *.txt ne marche pas

Donc sous UNIX tout programme a automatiquement (merci le shell)
des fonctionnalités plus riches.

De plus cela permet de vérifier le dit "principe de moindre surprise" :
si tu as l'habitude que dir *.txt marche, tu vas t'attendre à ce que
bidule *.txt marche aussi... et bien sous DOS/Windows ça va dépendre
du bidule.exe en question : parfois oui, parfois non.

Ça a quand même un autre (petit) inconvénient, une commande comme

mv /tmp/docs/* .
où on oublierait le point final, pourrait, si par malchance, le
dernier fichier de /tmp/docs était un répertoire ne pas faire
ce que l'on veut du tout... tandis que sous DOS/Win :
move c:temp*.*
copie bien les fichiers dans le répertoire courant.

de même une bonne blague comme un oubli dans tar a des
conséquences irritantes :
tar cf notes*
au lieu de :
tar cf notes.tar.gz notes*


Francois
Le #5950731
C'est l'inverse qu'il faut comprendre : c'est parce que dans le
répertoire courant précédent il n'y a AUCUN fichier dont le nom
commence par "notes" que l'* ne "disparaît" pas : faute de mieux
le shell transmet l'argument tel que à la commande. À mon avis
il ferait mieux de refuser en sortant une erreur du genre
'bsh: notes* : no match' ou au moins un warning.


Ok, merci beaucoup. Je crois que c'est clair. :-)


François

Nicolas George
Le #5950311
YBM , dans le message écrit :
'bsh: notes* : no match' ou au moins un warning.


s/bsh/zsh/

Publicité
Poster une réponse
Anonyme