|
|
fr.comp.os.linux.debats
Discussion complète de l'article :
Question (de débutant)_sur_une_commande
|
Article :
152731
Date :
01-04-2008
From :
Francois
Sujet :
Question (de débutant)_sur_une_commande
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
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
152732
Date :
01-04-2008
From :
YBM
Sujet :
Re: Question (de débutant)_sur_une_comm
Francois a écrit :
> 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.
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
152734
Date :
01-04-2008
From :
Francois
Sujet :
Re: Question (de débutant)_sur_une_comm
YBM a écrit :
> 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
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
152735
Date :
01-04-2008
From :
YBM
Sujet :
Re: Question (de débutant)_sur_une_comm
Francois a écrit :
> YBM a écrit :
>> 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*
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
152736
Date :
01-04-2008
From :
Francois
Sujet :
Re: Question (de débutant)_sur_une_comm
YBM a écrit :
> 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
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
Article :
152784
Date :
02-04-2008
From :
Nicolas George
Sujet :
Re: Question_(de_débutant)_sur_une_commande_unix
YBM , dans le message <47f179a7$0$28777$426a74cc@news.free.fr>, a
écrit :
> 'bsh: notes* : no match' ou au moins un warning.
s/bsh/zsh/
Posez vos questions, réponses et remarques sur
les forums de FrameIP
|
|
|