Bonjour,
Je voudrai compter des fichiers mp3 qui sont dans une arborescence de
répertoires :
[normal@localhost voice]$ ls -l
total 40
drwxr-xr-x 2 normal normal 4096 nov 10 08:12 16279_bien_commun
drwxr-xr-x 2 normal normal 4096 nov 15 10:14 2000_ans-histoire
drwxr-xr-x 2 normal normal 4096 nov 15 10:12 aspects_pensee_contemporaine
drwxr-xr-x 2 normal normal 4096 nov 15 10:13 enjeux_internationaux
drwxr-xr-x 2 normal normal 4096 nov 1 13:48 islam
drwxr-xr-x 2 normal normal 4096 nov 15 10:14 jacquard
drwxr-xr-x 2 normal normal 4096 nov 15 10:12 lundis_histoire
drwxr-xr-x 2 normal normal 4096 nov 10 08:09 science_conscience
drwxr-xr-x 2 normal normal 4096 nov 10 08:13 vendredis_de_la_philosophie
drwxr-xr-x 2 normal normal 4096 nov 15 10:12 vivants_et_les_dieux
À la racine de l'arborescence, je tape :
[normal@localhost voice]$ ls -R *mp* | wc -l
2
En fouillant un peu, je constate que le motif *mp* n'est pas recherché
dans mp3 mais dans le nom d'un seul répertoire (conteMPoraine) par ls :
[normal@localhost voice]$ ls -R *mp*
aspects_pensee_contemporaine:
10344-11.11.2007-ITEMA_20096350-0.mp3
wc -l fait son boulot en comptant 2 lignes qui sortent de ls.
D'où, ma question : quels argument et motif passer à ls avec wc -l pour
ne compter que les fichiers qui ont le motif souhaité, en l'occurrence mp3.
Je vous remercie,
Dominique
Le Fri, 16 Nov 2007 14:26:27 +0100, Fabien LE LEZ a écrit :
Je dirais plutôt : avec un shell Unix, il faut faire gaffe à ...
Franchement, le principe du remplacement automatique de "*" et "?" par le shell est passablement tordu. C'est puissant, certes, mais il faut beaucoup de temps pour s'y habituer. Surtout quand, comme moi, on a l'habitude du shell microsoftien.
[snap, exemple MS vs la plupart des shells unix]
ce qui donne un résultat bien différent -- et m'a beaucoup fait grincer des dents à mes débuts unixiens.
Les shells unixiens étaient là bien avant MS, c'est Mickey qui a simplifié le bouzingue en diminuant ses possibilités :-)
Une fois le coup pris c'est l'inverse, quand tu dois te coltiner la cli des Windows tu trouves qu'il manque plein de truc..
Et encore, dans les scripts amuse toi avec les ' et les ", ça laisse encore place à des surprises.
Le Fri, 16 Nov 2007 14:26:27 +0100, Fabien LE LEZ a écrit :
Je dirais plutôt : avec un shell Unix, il faut faire gaffe à ...
Franchement, le principe du remplacement automatique de "*" et "?" par
le shell est passablement tordu. C'est puissant, certes, mais il faut
beaucoup de temps pour s'y habituer. Surtout quand, comme moi, on a
l'habitude du shell microsoftien.
[snap, exemple MS vs la plupart des shells unix]
ce qui donne un résultat bien différent -- et m'a beaucoup fait
grincer des dents à mes débuts unixiens.
Les shells unixiens étaient là bien avant MS, c'est Mickey qui a
simplifié le bouzingue en diminuant ses possibilités :-)
Une fois le coup pris c'est l'inverse, quand tu dois te coltiner la cli
des Windows tu trouves qu'il manque plein de truc..
Et encore, dans les scripts amuse toi avec les ' et les ", ça laisse
encore place à des surprises.
Le Fri, 16 Nov 2007 14:26:27 +0100, Fabien LE LEZ a écrit :
Je dirais plutôt : avec un shell Unix, il faut faire gaffe à ...
Franchement, le principe du remplacement automatique de "*" et "?" par le shell est passablement tordu. C'est puissant, certes, mais il faut beaucoup de temps pour s'y habituer. Surtout quand, comme moi, on a l'habitude du shell microsoftien.
[snap, exemple MS vs la plupart des shells unix]
ce qui donne un résultat bien différent -- et m'a beaucoup fait grincer des dents à mes débuts unixiens.
Les shells unixiens étaient là bien avant MS, c'est Mickey qui a simplifié le bouzingue en diminuant ses possibilités :-)
Une fois le coup pris c'est l'inverse, quand tu dois te coltiner la cli des Windows tu trouves qu'il manque plein de truc..
Et encore, dans les scripts amuse toi avec les ' et les ", ça laisse encore place à des surprises.
Eric Razny
Le Thu, 15 Nov 2007 11:43:40 +0100, Fabien LE LEZ a écrit :
En l'occurence, si tu cherches le nombre de fichiers (fichiers réels uniquement) dont le nom contient "*mp*", tu écriras :
find -name "*mp*" -type f | wc -l
Ahem, attention à la notion de "fichier réel" sous linux (unix). On n'est plus tout à fait dans la philosophie "tout est fichier" (les interfaces ethernet en sont un exemple) mais pour un unixien un lien symbolique, un répertoire, un periph bloc etc sont des fichiers tout ce qu'il y a de plus réel :)
Eric
PS : si tu parles à un Windowsien il y a des chances qu'il cherche "*mp*" sans faire gaffe à la casse, il faut penser au -iname dans ce cas.
Le Thu, 15 Nov 2007 11:43:40 +0100, Fabien LE LEZ a écrit :
En l'occurence, si tu cherches le nombre de fichiers (fichiers réels
uniquement) dont le nom contient "*mp*", tu écriras :
find -name "*mp*" -type f | wc -l
Ahem, attention à la notion de "fichier réel" sous linux (unix). On
n'est plus tout à fait dans la philosophie "tout est fichier" (les
interfaces ethernet en sont un exemple) mais pour un unixien un lien
symbolique, un répertoire, un periph bloc etc sont des fichiers tout ce
qu'il y a de plus réel :)
Eric
PS : si tu parles à un Windowsien il y a des chances qu'il cherche "*mp*"
sans faire gaffe à la casse, il faut penser au -iname dans ce cas.
Le Thu, 15 Nov 2007 11:43:40 +0100, Fabien LE LEZ a écrit :
En l'occurence, si tu cherches le nombre de fichiers (fichiers réels uniquement) dont le nom contient "*mp*", tu écriras :
find -name "*mp*" -type f | wc -l
Ahem, attention à la notion de "fichier réel" sous linux (unix). On n'est plus tout à fait dans la philosophie "tout est fichier" (les interfaces ethernet en sont un exemple) mais pour un unixien un lien symbolique, un répertoire, un periph bloc etc sont des fichiers tout ce qu'il y a de plus réel :)
Eric
PS : si tu parles à un Windowsien il y a des chances qu'il cherche "*mp*" sans faire gaffe à la casse, il faut penser au -iname dans ce cas.
Fabien LE LEZ
On Mon, 19 Nov 2007 00:23:17 +0100, Eric Razny :
Les shells unixiens étaient là bien avant MS, c'est Mickey qui a simplifié le bouzingue en diminuant ses possibilités :-)
Si je ne m'abuse, le shell microsoftien n'est qu'une simple copie de celui de CP/M+. Pour une fois que c'est pas Bill l'auteur original d'une connerie, il ne faut pas hésiter à le signaler ;-)
M'enfin bon, je n'émettais pas un jugement de valeur, mais me contentais de dire qu'il faut faire vachement attention quand on change d'OS.
(En fait, ce qui me gêne le plus dans le système unixien, c'est qu'on tombe souvent sur le message "command-line too long".)
On Mon, 19 Nov 2007 00:23:17 +0100, Eric Razny <news_01@razny.net>:
Les shells unixiens étaient là bien avant MS, c'est Mickey qui a
simplifié le bouzingue en diminuant ses possibilités :-)
Si je ne m'abuse, le shell microsoftien n'est qu'une simple copie de
celui de CP/M+. Pour une fois que c'est pas Bill l'auteur original
d'une connerie, il ne faut pas hésiter à le signaler ;-)
M'enfin bon, je n'émettais pas un jugement de valeur, mais me
contentais de dire qu'il faut faire vachement attention quand on
change d'OS.
(En fait, ce qui me gêne le plus dans le système unixien, c'est qu'on
tombe souvent sur le message "command-line too long".)
Les shells unixiens étaient là bien avant MS, c'est Mickey qui a simplifié le bouzingue en diminuant ses possibilités :-)
Si je ne m'abuse, le shell microsoftien n'est qu'une simple copie de celui de CP/M+. Pour une fois que c'est pas Bill l'auteur original d'une connerie, il ne faut pas hésiter à le signaler ;-)
M'enfin bon, je n'émettais pas un jugement de valeur, mais me contentais de dire qu'il faut faire vachement attention quand on change d'OS.
(En fait, ce qui me gêne le plus dans le système unixien, c'est qu'on tombe souvent sur le message "command-line too long".)
