Mots clés: Retrouver trouver retracer lister ls gros fichiers répertoires
Pour les répertoires:
du -Sk . | sort -nr | more
Pour les fichiers:
find . -printf "%k KB %h/%f\n" | sort +0nr | more
Mon petit problème est le suivant: où est-il dit que +0nr classe les fichiers
par ordre alphabétique après les avoir classés par grosseur? J'ai trouvé ça
sur le net, mais je ne trouve rien là-dessus dans les man pages.
Non, %k et "du" se servent du champs st_blocks du resultat de stat(2), pas du champ st_size comme dans ls ou "%s".
Tiré de man find:
%k File's size in 1K blocks (rounded up).
%s File's size in bytes.
Tu vois ce que je veux dire, Éric? Qu'est-ce que ces gens-là viennent foutre ici? Vas voir sur alt.os.linux.slackware, il y en a qui sont là depuis des années à brasser ce genre de merde.
[...]
:)
Tu viens de mettre le doigt sur un bug de documentation de find (ou un bug de find si la page de man/info est correcte).
Ouais, ouais... je te laisse leur écrire. Parce qu'il y a tout de même un petit problème: chez toi et chez moi, on n'a pas les mêmes résultats. Tu écris:
$ find a -printf '%kn' 16 $ find a -printf '%sn' 1048576001
pour prétendre que %k ne donne pas les kilo-octets, vu que 16Ko ne font pas 1048576001 octets.
Or, chez moi et chez n'importe qui, ça fonctionne parfaitement:
$ find hamilton.tif -printf "%k" 2312
$ find hamilton.tif -printf "%s" 2360268
Alors, tu sais, lorsqu'on pratique la désinformation, on a beau lancer au visage de tout le monde n'importe quelle connerie d'apparence technique, il faut tout de même faire attention de ne pas trop déconner dans le vérifiable.
GP
Stephane Chazelas wrote:
2005-01-29, 16:05(-05), GP:
Stephane Chazelas wrote:
Non, %k et "du" se servent du champs st_blocks du resultat de
stat(2), pas du champ st_size comme dans ls ou "%s".
Tiré de man find:
%k File's size in 1K blocks (rounded up).
%s File's size in bytes.
Tu vois ce que je veux dire, Éric? Qu'est-ce que ces gens-là viennent foutre
ici? Vas voir sur alt.os.linux.slackware, il y en a qui sont là depuis des
années à brasser ce genre de merde.
[...]
:)
Tu viens de mettre le doigt sur un bug de documentation de find
(ou un bug de find si la page de man/info est correcte).
Ouais, ouais... je te laisse leur écrire. Parce qu'il y a tout de même un
petit problème: chez toi et chez moi, on n'a pas les mêmes résultats. Tu écris:
$ find a -printf '%kn'
16
$ find a -printf '%sn'
1048576001
pour prétendre que %k ne donne pas les kilo-octets, vu que 16Ko ne font pas
1048576001 octets.
Or, chez moi et chez n'importe qui, ça fonctionne parfaitement:
$ find hamilton.tif -printf "%k"
2312
$ find hamilton.tif -printf "%s"
2360268
Alors, tu sais, lorsqu'on pratique la désinformation, on a beau lancer au
visage de tout le monde n'importe quelle connerie d'apparence technique, il
faut tout de même faire attention de ne pas trop déconner dans le vérifiable.
Non, %k et "du" se servent du champs st_blocks du resultat de stat(2), pas du champ st_size comme dans ls ou "%s".
Tiré de man find:
%k File's size in 1K blocks (rounded up).
%s File's size in bytes.
Tu vois ce que je veux dire, Éric? Qu'est-ce que ces gens-là viennent foutre ici? Vas voir sur alt.os.linux.slackware, il y en a qui sont là depuis des années à brasser ce genre de merde.
[...]
:)
Tu viens de mettre le doigt sur un bug de documentation de find (ou un bug de find si la page de man/info est correcte).
Ouais, ouais... je te laisse leur écrire. Parce qu'il y a tout de même un petit problème: chez toi et chez moi, on n'a pas les mêmes résultats. Tu écris:
$ find a -printf '%kn' 16 $ find a -printf '%sn' 1048576001
pour prétendre que %k ne donne pas les kilo-octets, vu que 16Ko ne font pas 1048576001 octets.
Or, chez moi et chez n'importe qui, ça fonctionne parfaitement:
$ find hamilton.tif -printf "%k" 2312
$ find hamilton.tif -printf "%s" 2360268
Alors, tu sais, lorsqu'on pratique la désinformation, on a beau lancer au visage de tout le monde n'importe quelle connerie d'apparence technique, il faut tout de même faire attention de ne pas trop déconner dans le vérifiable.
GP
Stephane Chazelas
2005-01-29, 22:28(-05), GP: [...]
$ find a -printf '%kn' 16 $ find a -printf '%sn' 1048576001
pour prétendre que %k ne donne pas les kilo-octets, vu que 16Ko ne font pas 1048576001 octets.
Or, chez moi et chez n'importe qui, ça fonctionne parfaitement:
$ find hamilton.tif -printf "%k" 2312
$ find hamilton.tif -printf "%s" 2360268
Alors, tu sais, lorsqu'on pratique la désinformation, on a beau lancer au visage de tout le monde n'importe quelle connerie d'apparence technique, il faut tout de même faire attention de ne pas trop déconner dans le vérifiable. [...]
Tetu, hein ?
Je dis que "du" (qui veut dire "disk usage") et %k ne donnent pas la taille du fichier (le nombre d'octets qui seraient renvoyés si on faisait un "cat le-fichier"), mais l'occupation disque, c'est a dire le nombre de kilo octets alloués par le systeme de fichiers pour ce fichier.
Regarde sur un fichier d'1 MO, par exemple,
$ dd bs=1M count=1 < /dev/zero > a $ ls -l a -rw-r--r-- 1 chazelas chazelas 1048576 Jan 30 09:13 a $ du -k a 1028 a $ find a -printf %kn 1028
Ce qui fait 4ko de plus que 1Mo (= 1024 ko). C'est du a la structure interne du systeme de fichiers. Le systeme de fichiers (FS) alloue l'espace disque par blocks (de taille definie au depart a la creation du FS, 4096 dans mon cas).
Un fichier a un i-node dans une table d'inodes ou sont stockees les informations du fichier ainsi qu'une liste d'adresses de blocks. Comme l'inode ne fait que quelques octets (128), pour les fichiers de plus de 12 blocks, le FS alloue des blocks supplementaires, qui contiennent les adresses de blocks suivants (qu'on appelle des blocks d'indirection).
Maintenant:
$ rm a $ echo toto | dd bs=1M seek00 of=a $ ls -l a -rw-r--r-- 1 chazelas chazelas 1572864005 Jan 30 09:18 a $ find a -printf %kn 12
Ce fichier de 1500 Mo occupe 12ko (3 blocks) sur disque.
C'est un fichier a trous, un sparse file.
Un block d'indirection permet de referencer 1024 blocks (sur mon FS pour lequel la taille des blocks est de 4ko). Pour un fichier de plus de (1024 + 12) blocks de taille, il faut donc un block de double indirection, qui contient les adresses de blocks d'indirection supplementaires, avec ce block de double indirection, on peut donc adresser les blocks d'un fichier de (1024 * 1024 + 1024 + 12) blocks (4 Go et des poussieres).
Donc, tu peux comprendre quels sont ces trois blocks alloués pour mon fichier:
1 block de double indirection, qui contient des zeros sauf pour l'adresse d'1 block d'indirection qui contient des zeros sauf pour l'adresse d'un block de donnees qui contient les cinq octets "toton" et 4091 autres octets inutilisés.
Si ca t'amuse, tu peux jouer avec debugfs pour voir le contenu du FS.
Pour mon fichier, ca donne:
debugfs: stat /chazelas/a [...] BLOCKS: (DIND):987546, (IND):987547, (384000):987548 TOTAL: 3
$ sudo dd bs=4k skip7548 count=1 if=/dev/hda8 | od -tc 0000000 t o t o n 0000020 * 0010000
-- Stéphane
2005-01-29, 22:28(-05), GP:
[...]
$ find a -printf '%kn'
16
$ find a -printf '%sn'
1048576001
pour prétendre que %k ne donne pas les kilo-octets, vu que 16Ko ne font pas
1048576001 octets.
Or, chez moi et chez n'importe qui, ça fonctionne parfaitement:
$ find hamilton.tif -printf "%k"
2312
$ find hamilton.tif -printf "%s"
2360268
Alors, tu sais, lorsqu'on pratique la désinformation, on a beau lancer au
visage de tout le monde n'importe quelle connerie d'apparence technique, il
faut tout de même faire attention de ne pas trop déconner dans le vérifiable.
[...]
Tetu, hein ?
Je dis que "du" (qui veut dire "disk usage") et %k ne donnent
pas la taille du fichier (le nombre d'octets qui seraient
renvoyés si on faisait un "cat le-fichier"), mais l'occupation
disque, c'est a dire le nombre de kilo octets alloués par le
systeme de fichiers pour ce fichier.
Regarde sur un fichier d'1 MO, par exemple,
$ dd bs=1M count=1 < /dev/zero > a
$ ls -l a
-rw-r--r-- 1 chazelas chazelas 1048576 Jan 30 09:13 a
$ du -k a
1028 a
$ find a -printf %k\n
1028
Ce qui fait 4ko de plus que 1Mo (= 1024 ko). C'est du a la
structure interne du systeme de fichiers. Le systeme de fichiers
(FS) alloue l'espace disque par blocks (de taille definie au
depart a la creation du FS, 4096 dans mon cas).
Un fichier a un i-node dans une table d'inodes ou sont stockees
les informations du fichier ainsi qu'une liste d'adresses de
blocks. Comme l'inode ne fait que quelques octets (128), pour
les fichiers de plus de 12 blocks, le FS alloue des blocks
supplementaires, qui contiennent les adresses de blocks suivants
(qu'on appelle des blocks d'indirection).
Maintenant:
$ rm a
$ echo toto | dd bs=1M seek00 of=a
$ ls -l a
-rw-r--r-- 1 chazelas chazelas 1572864005 Jan 30 09:18 a
$ find a -printf %k\n
12
Ce fichier de 1500 Mo occupe 12ko (3 blocks) sur disque.
C'est un fichier a trous, un sparse file.
Un block d'indirection permet de referencer 1024 blocks (sur mon
FS pour lequel la taille des blocks est de 4ko). Pour un fichier
de plus de (1024 + 12) blocks de taille, il faut donc un block
de double indirection, qui contient les adresses de blocks
d'indirection supplementaires, avec ce block de double
indirection, on peut donc adresser les blocks d'un fichier de
(1024 * 1024 + 1024 + 12) blocks (4 Go et des poussieres).
Donc, tu peux comprendre quels sont ces trois blocks alloués
pour mon fichier:
1 block de double indirection, qui contient des zeros sauf pour
l'adresse d'1 block d'indirection qui contient des zeros sauf pour
l'adresse d'un block de donnees qui contient les cinq octets
"toton" et 4091 autres octets inutilisés.
Si ca t'amuse, tu peux jouer avec debugfs pour voir le contenu
du FS.
Pour mon fichier, ca donne:
debugfs: stat /chazelas/a
[...]
BLOCKS:
(DIND):987546, (IND):987547, (384000):987548
TOTAL: 3
$ find a -printf '%kn' 16 $ find a -printf '%sn' 1048576001
pour prétendre que %k ne donne pas les kilo-octets, vu que 16Ko ne font pas 1048576001 octets.
Or, chez moi et chez n'importe qui, ça fonctionne parfaitement:
$ find hamilton.tif -printf "%k" 2312
$ find hamilton.tif -printf "%s" 2360268
Alors, tu sais, lorsqu'on pratique la désinformation, on a beau lancer au visage de tout le monde n'importe quelle connerie d'apparence technique, il faut tout de même faire attention de ne pas trop déconner dans le vérifiable. [...]
Tetu, hein ?
Je dis que "du" (qui veut dire "disk usage") et %k ne donnent pas la taille du fichier (le nombre d'octets qui seraient renvoyés si on faisait un "cat le-fichier"), mais l'occupation disque, c'est a dire le nombre de kilo octets alloués par le systeme de fichiers pour ce fichier.
Regarde sur un fichier d'1 MO, par exemple,
$ dd bs=1M count=1 < /dev/zero > a $ ls -l a -rw-r--r-- 1 chazelas chazelas 1048576 Jan 30 09:13 a $ du -k a 1028 a $ find a -printf %kn 1028
Ce qui fait 4ko de plus que 1Mo (= 1024 ko). C'est du a la structure interne du systeme de fichiers. Le systeme de fichiers (FS) alloue l'espace disque par blocks (de taille definie au depart a la creation du FS, 4096 dans mon cas).
Un fichier a un i-node dans une table d'inodes ou sont stockees les informations du fichier ainsi qu'une liste d'adresses de blocks. Comme l'inode ne fait que quelques octets (128), pour les fichiers de plus de 12 blocks, le FS alloue des blocks supplementaires, qui contiennent les adresses de blocks suivants (qu'on appelle des blocks d'indirection).
Maintenant:
$ rm a $ echo toto | dd bs=1M seek00 of=a $ ls -l a -rw-r--r-- 1 chazelas chazelas 1572864005 Jan 30 09:18 a $ find a -printf %kn 12
Ce fichier de 1500 Mo occupe 12ko (3 blocks) sur disque.
C'est un fichier a trous, un sparse file.
Un block d'indirection permet de referencer 1024 blocks (sur mon FS pour lequel la taille des blocks est de 4ko). Pour un fichier de plus de (1024 + 12) blocks de taille, il faut donc un block de double indirection, qui contient les adresses de blocks d'indirection supplementaires, avec ce block de double indirection, on peut donc adresser les blocks d'un fichier de (1024 * 1024 + 1024 + 12) blocks (4 Go et des poussieres).
Donc, tu peux comprendre quels sont ces trois blocks alloués pour mon fichier:
1 block de double indirection, qui contient des zeros sauf pour l'adresse d'1 block d'indirection qui contient des zeros sauf pour l'adresse d'un block de donnees qui contient les cinq octets "toton" et 4091 autres octets inutilisés.
Si ca t'amuse, tu peux jouer avec debugfs pour voir le contenu du FS.
Pour mon fichier, ca donne:
debugfs: stat /chazelas/a [...] BLOCKS: (DIND):987546, (IND):987547, (384000):987548 TOTAL: 3
$ sudo dd bs=4k skip7548 count=1 if=/dev/hda8 | od -tc 0000000 t o t o n 0000020 * 0010000
-- Stéphane
Eric Jacoboni
Stephane Chazelas writes:
Mais j'imagine que ton find a plein d'options inspirees du GNU find (et qui ne sont pas beaucoup plus /portable/) comme -print0 -maxdepth, -iname, -regex...
Possible. Je n'ai pas dit que -printf était "evil", hein. J'ai dit que je n'en disposait pas et que, donc, je ne pouvais pas répondre à mon interlocuteur. Faut pas être susceptible comme ça, je vais finir par croire que tu est un utilisateur de la Debian...
Est-ce moi, ou ce newsgroup semble manquer un peu d'ouverture d'esprit.
Mais j'imagine que ton find a plein d'options inspirees du GNU
find (et qui ne sont pas beaucoup plus /portable/) comme -print0
-maxdepth, -iname, -regex...
Possible. Je n'ai pas dit que -printf était "evil", hein. J'ai dit que
je n'en disposait pas et que, donc, je ne pouvais pas répondre à mon
interlocuteur. Faut pas être susceptible comme ça, je vais finir par
croire que tu est un utilisateur de la Debian...
Est-ce moi, ou ce newsgroup semble manquer un peu d'ouverture
d'esprit.
Mais j'imagine que ton find a plein d'options inspirees du GNU find (et qui ne sont pas beaucoup plus /portable/) comme -print0 -maxdepth, -iname, -regex...
Possible. Je n'ai pas dit que -printf était "evil", hein. J'ai dit que je n'en disposait pas et que, donc, je ne pouvais pas répondre à mon interlocuteur. Faut pas être susceptible comme ça, je vais finir par croire que tu est un utilisateur de la Debian...
Est-ce moi, ou ce newsgroup semble manquer un peu d'ouverture d'esprit.
Le contraire serait nouveau et surprenant.
-- Éric Jacoboni, né il y a 1410521088 secondes
Stephane Chazelas
2005-01-30, 11:28(+01), Eric Jacoboni:
Stephane Chazelas writes:
Mais j'imagine que ton find a plein d'options inspirees du GNU find (et qui ne sont pas beaucoup plus /portable/) comme -print0 -maxdepth, -iname, -regex...
Possible. Je n'ai pas dit que -printf était "evil", hein. J'ai dit que je n'en disposait pas et que, donc, je ne pouvais pas répondre à mon interlocuteur. Faut pas être susceptible comme ça, je vais finir par croire que tu est un utilisateur de la Debian... [...]
Voir en-tetes.
Pas une question de susceptibilité. Question d'honneteté, intellectuelle. Tu sembles faire du bashage systematique de GNU et de RMS, j'ai juste trouvé ta remarque initiale sur "info" deplacee et injustifiee.
Je suis le premier a critiquer les outils GNUs quand ils sont mal concus, et en particulier findutils d'ailleurs (qui viennent d'avoir un nouveau mainteneur qui commence a fixer les nombreux problemes).
Voir http://groups-beta.google.com/group/comp.unix.shell/msg/0d72a806824b0d49 par exemple.
Mais j'imagine que ton find a plein d'options inspirees du GNU
find (et qui ne sont pas beaucoup plus /portable/) comme -print0
-maxdepth, -iname, -regex...
Possible. Je n'ai pas dit que -printf était "evil", hein. J'ai dit que
je n'en disposait pas et que, donc, je ne pouvais pas répondre à mon
interlocuteur. Faut pas être susceptible comme ça, je vais finir par
croire que tu est un utilisateur de la Debian...
[...]
Voir en-tetes.
Pas une question de susceptibilité. Question d'honneteté,
intellectuelle. Tu sembles faire du bashage systematique de GNU
et de RMS, j'ai juste trouvé ta remarque initiale sur "info"
deplacee et injustifiee.
Je suis le premier a critiquer les outils GNUs quand ils sont
mal concus, et en particulier findutils d'ailleurs (qui viennent
d'avoir un nouveau mainteneur qui commence a fixer les nombreux
problemes).
Voir
http://groups-beta.google.com/group/comp.unix.shell/msg/0d72a806824b0d49
par exemple.
Mais j'imagine que ton find a plein d'options inspirees du GNU find (et qui ne sont pas beaucoup plus /portable/) comme -print0 -maxdepth, -iname, -regex...
Possible. Je n'ai pas dit que -printf était "evil", hein. J'ai dit que je n'en disposait pas et que, donc, je ne pouvais pas répondre à mon interlocuteur. Faut pas être susceptible comme ça, je vais finir par croire que tu est un utilisateur de la Debian... [...]
Voir en-tetes.
Pas une question de susceptibilité. Question d'honneteté, intellectuelle. Tu sembles faire du bashage systematique de GNU et de RMS, j'ai juste trouvé ta remarque initiale sur "info" deplacee et injustifiee.
Je suis le premier a critiquer les outils GNUs quand ils sont mal concus, et en particulier findutils d'ailleurs (qui viennent d'avoir un nouveau mainteneur qui commence a fixer les nombreux problemes).
Voir http://groups-beta.google.com/group/comp.unix.shell/msg/0d72a806824b0d49 par exemple.
-- Stéphane
Eric Jacoboni
Stephane Chazelas writes:
Voir en-tetes.
Je les avais vu...
Pas une question de susceptibilité. Question d'honneteté, intellectuelle. Tu sembles faire du bashage systematique de GNU et de RMS
N'importe quoi... ça fait des années que j'utilise les outils GNU et que, pour certains, j'en fais même la doc et la publicité.
j'ai juste trouvé ta remarque initiale sur "info" deplacee et injustifiee.
On va dire que tu n'es pas d'accord avec moi, ça suffira bien... M'enfin, si tu te sors un peu la tête du sable, tu noteras que je ne suis pas le seul à critiquer les manpages de Linux. J'ai même choisi FreeBSD à la fac car je voulais que mes étudiants aient des pages de manuel décentes lorsqu'ils faisaient de la prog sys, entre autres.
Je suis le premier a critiquer les outils GNUs quand ils sont mal concus, et en particulier findutils d'ailleurs (qui viennent d'avoir un nouveau mainteneur qui commence a fixer les nombreux problemes).
Donc, où est le problème lorsque je critique info, qui est inutile et mal foutu ?
Pas une question de susceptibilité. Question d'honneteté,
intellectuelle. Tu sembles faire du bashage systematique de GNU
et de RMS
N'importe quoi... ça fait des années que j'utilise les outils GNU et
que, pour certains, j'en fais même la doc et la publicité.
j'ai juste trouvé ta remarque initiale sur "info"
deplacee et injustifiee.
On va dire que tu n'es pas d'accord avec moi, ça suffira
bien... M'enfin, si tu te sors un peu la tête du sable, tu noteras que
je ne suis pas le seul à critiquer les manpages de Linux. J'ai même
choisi FreeBSD à la fac car je voulais que mes étudiants aient des
pages de manuel décentes lorsqu'ils faisaient de la prog sys, entre
autres.
Je suis le premier a critiquer les outils GNUs quand ils sont
mal concus, et en particulier findutils d'ailleurs (qui viennent
d'avoir un nouveau mainteneur qui commence a fixer les nombreux
problemes).
Donc, où est le problème lorsque je critique info, qui est inutile et
mal foutu ?
Pas une question de susceptibilité. Question d'honneteté, intellectuelle. Tu sembles faire du bashage systematique de GNU et de RMS
N'importe quoi... ça fait des années que j'utilise les outils GNU et que, pour certains, j'en fais même la doc et la publicité.
j'ai juste trouvé ta remarque initiale sur "info" deplacee et injustifiee.
On va dire que tu n'es pas d'accord avec moi, ça suffira bien... M'enfin, si tu te sors un peu la tête du sable, tu noteras que je ne suis pas le seul à critiquer les manpages de Linux. J'ai même choisi FreeBSD à la fac car je voulais que mes étudiants aient des pages de manuel décentes lorsqu'ils faisaient de la prog sys, entre autres.
Je suis le premier a critiquer les outils GNUs quand ils sont mal concus, et en particulier findutils d'ailleurs (qui viennent d'avoir un nouveau mainteneur qui commence a fixer les nombreux problemes).
Donc, où est le problème lorsque je critique info, qui est inutile et mal foutu ?
-- Éric Jacoboni, né il y a 1410523586 secondes
Stephane Chazelas
2005-01-30, 12:12(+01), Eric Jacoboni: [...]
Je suis le premier a critiquer les outils GNUs quand ils sont mal concus, et en particulier findutils d'ailleurs (qui viennent d'avoir un nouveau mainteneur qui commence a fixer les nombreux problemes).
Donc, où est le problème lorsque je critique info, qui est inutile et mal foutu ? [...]
Parce que c'est faux.
Tu ne m'as toujours pas cité d'avantage du format de man par rapport a info, sauf que c'etait plus universel, je t'ai cité plusieurs avantages d'info et plusieurs inconvenients de man, un peu comme dans une argumentation, quoi.
Je peux te citer des inconvenients d'info pour t'aider: - binding par defaut a la emacs (configurable toutefois) - pas de recherche par regexp (pinfo et probablement emacs et vim ont ca, mais ont d'autres inconvenients) - l'acces a l'index est perfectible
-- Stéphane
2005-01-30, 12:12(+01), Eric Jacoboni:
[...]
Je suis le premier a critiquer les outils GNUs quand ils sont
mal concus, et en particulier findutils d'ailleurs (qui viennent
d'avoir un nouveau mainteneur qui commence a fixer les nombreux
problemes).
Donc, où est le problème lorsque je critique info, qui est inutile et
mal foutu ?
[...]
Parce que c'est faux.
Tu ne m'as toujours pas cité d'avantage du format de man par
rapport a info, sauf que c'etait plus universel, je t'ai cité
plusieurs avantages d'info et plusieurs inconvenients de man, un
peu comme dans une argumentation, quoi.
Je peux te citer des inconvenients d'info pour t'aider:
- binding par defaut a la emacs (configurable toutefois)
- pas de recherche par regexp (pinfo et probablement emacs et
vim ont ca, mais ont d'autres inconvenients)
- l'acces a l'index est perfectible
Je suis le premier a critiquer les outils GNUs quand ils sont mal concus, et en particulier findutils d'ailleurs (qui viennent d'avoir un nouveau mainteneur qui commence a fixer les nombreux problemes).
Donc, où est le problème lorsque je critique info, qui est inutile et mal foutu ? [...]
Parce que c'est faux.
Tu ne m'as toujours pas cité d'avantage du format de man par rapport a info, sauf que c'etait plus universel, je t'ai cité plusieurs avantages d'info et plusieurs inconvenients de man, un peu comme dans une argumentation, quoi.
Je peux te citer des inconvenients d'info pour t'aider: - binding par defaut a la emacs (configurable toutefois) - pas de recherche par regexp (pinfo et probablement emacs et vim ont ca, mais ont d'autres inconvenients) - l'acces a l'index est perfectible
-- Stéphane
Stephane Chazelas
2005-01-30, 12:12(+01), Eric Jacoboni: [...]
On va dire que tu n'es pas d'accord avec moi, ça suffira bien... M'enfin, si tu te sors un peu la tête du sable, tu noteras que je ne suis pas le seul à critiquer les manpages de Linux. [...]
Je n'ai pas emis d'avis sur les manpages de Linux, on parlait de info par rapport a man.
-- Stéphane
2005-01-30, 12:12(+01), Eric Jacoboni:
[...]
On va dire que tu n'es pas d'accord avec moi, ça suffira
bien... M'enfin, si tu te sors un peu la tête du sable, tu noteras que
je ne suis pas le seul à critiquer les manpages de Linux.
[...]
Je n'ai pas emis d'avis sur les manpages de Linux, on parlait de
info par rapport a man.
On va dire que tu n'es pas d'accord avec moi, ça suffira bien... M'enfin, si tu te sors un peu la tête du sable, tu noteras que je ne suis pas le seul à critiquer les manpages de Linux. [...]
Je n'ai pas emis d'avis sur les manpages de Linux, on parlait de info par rapport a man.
-- Stéphane
Emmanuel Florac
Le Sat, 29 Jan 2005 19:09:27 +0000, Stephane Chazelas a écrit :
Donne-moi un seul format de manuel mieux adapté qu'info pour de la lecture de manuel en ligne.
man, indiscutablement. Au fait, fu2...
-- L'esprit qu'on veut avoir gâte celui qu'on a. Jean-Baptiste Louis Grisset.
Le Sat, 29 Jan 2005 19:09:27 +0000, Stephane Chazelas a écrit :
Donne-moi un seul format de manuel mieux adapté qu'info pour de
la lecture de manuel en ligne.
man, indiscutablement. Au fait, fu2...
--
L'esprit qu'on veut avoir gâte celui qu'on a.
Jean-Baptiste Louis Grisset.
Le Sat, 29 Jan 2005 19:43:47 +0000, Stephane Chazelas a écrit :
Est-ce que man permet un acces direct a l'information a partir d'un index ou d'une table des matieres (avec en prime de la completion?).
man -k ? apropos ?
-- Si non confectus non reficiat.
Emmanuel Florac
Le Sun, 30 Jan 2005 01:32:32 +0000, Stephane Chazelas a écrit :
Ainsi « quelqu'un a inventé man en 1970, il ne saurait etre inventé rien de mieux » et tout est dit ?
Ben si, il y a docbook, qui permet de générer du man, du html, etc. info est totalement supérfétatoire : il n'a ni la simplicité et l'universalité de man, ni les qualités et l'universalité de html. C'est tout con mais info est complètement dépassé. man aussi, mais son côté universel et simpliste fait qu'il perdure (et predurera) alors qu'info est un pur GNUisme qui ne s'imposera jamais, que ça te plaise ou non (et c'est un FSFien qui te le dit).
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
Le Sun, 30 Jan 2005 01:32:32 +0000, Stephane Chazelas a écrit :
Ainsi « quelqu'un a inventé man en 1970, il ne saurait etre
inventé rien de mieux » et tout est dit ?
Ben si, il y a docbook, qui permet de générer du man, du html, etc. info
est totalement supérfétatoire : il n'a ni la simplicité et
l'universalité de man, ni les qualités et l'universalité de html. C'est
tout con mais info est complètement dépassé. man aussi, mais son côté
universel et simpliste fait qu'il perdure (et predurera) alors qu'info est
un pur GNUisme qui ne s'imposera jamais, que ça te plaise ou non (et
c'est un FSFien qui te le dit).
--
Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir
aristocratique de déplaire.
C. Baudelaire.
Le Sun, 30 Jan 2005 01:32:32 +0000, Stephane Chazelas a écrit :
Ainsi « quelqu'un a inventé man en 1970, il ne saurait etre inventé rien de mieux » et tout est dit ?
Ben si, il y a docbook, qui permet de générer du man, du html, etc. info est totalement supérfétatoire : il n'a ni la simplicité et l'universalité de man, ni les qualités et l'universalité de html. C'est tout con mais info est complètement dépassé. man aussi, mais son côté universel et simpliste fait qu'il perdure (et predurera) alors qu'info est un pur GNUisme qui ne s'imposera jamais, que ça te plaise ou non (et c'est un FSFien qui te le dit).
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
