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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
YBM
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 :
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.
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 :
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.
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 :
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
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
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.
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
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*
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*
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
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
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.
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
YBM , dans le message <47f179a7$0$28777$, a écrit :
'bsh: notes* : no match' ou au moins un warning.
s/bsh/zsh/
YBM , dans le message <47f179a7$0$28777$426a74cc@news.free.fr>, a
écrit :
