Rolinh a écrit 77 commentaires

Et bien je confirme: c'est bien la version de cmake qui pose problème. J'ai installé la version des backports (2.8.7) sur ma VM Debian 6.0.5 et tout fonctionne bien.

C'est peut-être lié à la version de cmake un peu vieille (2.8.2). Je vais me faire une VM avec Debian stable et voir ce que je peux faire.

En attendant, tu peux toujours compiler sans les traductions.

Sur quelle plateforme? CMake n'a-t-il pas généré des erreurs par rapport à gettext (qui est nécessaire afin de construire les traductions)? Si oui, quelles sont-elles?

Et j'imagine que tout se passe bien en compilant sans le support des traductions (cmake .. -DNLS_ENABLE=false)?

Merci à toi pour le paquet !

Si si, les kimsufi sont des dédiés…
Donc comme toi, je suis dubitatif.

PS: et les hébergements sans ssh sont légions…

C'est quelque chose qui peut se faire, effectivement. J'avais déjà eu une demande par rapport à une feature de tri mais ne l'ai pas encore traitée, la jugeant moins importante que le reste.

Par contre, je peux ajouter une nouvelle option pour le tri selon le FS. C'est une excellente idée.

J'ajoute cela à la liste de features prévues pour la version 3.0.0.

Cette option est maintenant disponible (version 2.5.0).
Il s'agit de -W ;)

Oui, effectivement (j'ai finit tard hier soir…).

Merci.

Merci :)

Oui, tu as été clair. ;)

A vrai dire, je n'avais pas vraiment de but pour dfc(1) à la base. Je l'ai écrit parce que ça m'amusait puis, le trouvant pas trop mal, je l'ai partagé pour en faire profiter d'autres.

Maintenant, je suis toujours ouvert à la discussion même s'il est peu probable que j'inclue les options longues dans dfc(1).

N'en déplaise à certains, j'ai estimé profitable à tout le monde la sortie d'une nouvelle version de dfc(1). Elle apporte pas mal de choses dont le support de Mac OS, le support de l'option -o pour FreeBSD, une nouvelle option, un petit changement visuel et la correction des bugs relevé par des gens ici en plus de plusieurs autres ainsi qu'une réorganisation de code majeure.
Pour les détails, lire l'annonce (en).

Oui, c'est vrai, getopt_long(3) est aussi disponible sous les systèmes *BSD. En revanche, les outils standards *BSD ne possèdent pas d'option longues. En utiliser pour dfc le rendrait incompatible avec les df(1) des *BSD au même titre que ne pas en utiliser rend dfc incompatible avec df(1) des coreutils.
C'est dans ce sens là que j'entendais que le fait que dfc(1) soit multiplateforme est un "problème", pas dans le sens "les options longues ne sont pas disponibles pour les systèmes *BSD" puisque ce n'est pas le cas. ;)

De toute façon, il y a un choix à faire et le mien est de ne pas utiliser les options longues (pour la raison que j'ai évoquée).

C'est un point de vue que je comprend. Cependant, il faut comprendre pourquoi ce n'est pas possible de mon point de vue: dfc est multiplateforme.

Le df(1) de FreeBSD n'est pas le même que le df(1) des coreutils par exemple. Les options ne sont pas les mêmes déjà rien que par le fait que les outils système des *BSD ne possèdent pas les options longues (qui, comme je l'ai déjà dit, sont une extension GNU). (manpage de df(1) de FreeBSD, manpage de df(1) des coreutils).

Dans ce contexte, je suis obligé de faire des choix. Mon point de vue est que les options longues sont une aberration (c'est mon avis, il est subjectif hein) et je ne les utilise donc pas. Donc je peux essayer d'être au plus proche des options des df(1) mais je ne pourrais jamais avoir exactement les mêmes. Une compatibilité à 100% avec les df(1) est simplement impossible.

En revanche, je ne conseillerais pas d'utiliser dfc(1) dans des scripts destinés à être partagés (peu importe pour les scripts perso) pour la simple et bonne raison que ce n'est pas un outil fournit de base avec le système, au contraire de df(1).

Je suis désolé si j'en déçois certain mais je ne pense pas que mon choix soit irrationnel.
Et puis taper "dfc" ne fait toujours qu'une lettre de plus que "df". ;)

Pourquoi pas?
Allez, je mets dans la roadmap pour la version 3.0.0 ;)

Merci :)

Oui, les champs trop long sont tronqués afin de ne pas perturber l'affichage. Je vais ajouter une option permettant de ne pas les tronquer (mais cela nécessite plus de place pour être affiché à l'écran).

Heu… Je ne pensais pas sortir une version tout de suite, sinon je vais encore me faire taper sur les doigts. :P

Enfin bon, j'ai corrigé plusieurs bugs relevés par des gens d'ici et ai porté dfc sous Mac OS (merci à un lecteur de linuxfr au passage). Ça serait peut-être dommage de faire patienter les utilisateurs de MacOS jusqu'à la version 3.0.0 qui ne sortira sûrement pas avant un bon bout de temps…

Oui c'est vrai. Je viens de tester pour voir comment cela donnait et avec la couleur je trouve que c'est trop "flashy" avec les #.
J'ai testé avec le signe "=" est cela semble un bon compromis (plus lisible que les * mais pas autant flashy que les # ). Peut-être le bon choix?

image avec les tests

C'est vrai que l'URL pour le dépôt git est un peu cachée. Je trouverais logique qu'elle soit affichée quelque part lorsque l'on clique sur "Repository" mais il me semble que Chiliproject ne le permet pas (ou en tout cas, je n'ai pas trouvé l'option).

Pour ce qui est de udev, je ne suis pas certain qu'il s'agisse d'un bug. Le filtrage se fait sur le type de système de fichiers.
Exemple (dfc -T):

FILESYSTEM  TYPE     (*) USED      FREE (-) %USED AVAILABLE     TOTAL MOUNTED ON 
rootfs      rootfs   [*********-----------]   44%      5.6G      9.9G /
/dev/root   ext4     [*********-----------]   44%      5.6G      9.9G /
/run        tmpfs    [*-------------------]    0%    989.2M    989.4M /run
udev        devtmpfs [--------------------]    0%    989.1M    989.1M /dev
tmpfs       tmpfs    [--------------------]    0%    989.4M    989.4M /dev/shm
/dev/sda2   ext4     [**------------------]   10%    826.2G    913.8G /home

Et donc (dfc -T -t -devtmpfs):

FILESYSTEM  TYPE     (*) USED      FREE (-) %USED AVAILABLE     TOTAL MOUNTED ON 
rootfs      rootfs   [*********-----------]   44%      5.6G      9.9G /
/dev/root   ext4     [*********-----------]   44%      5.6G      9.9G /
/run        tmpfs    [*-------------------]    0%    989.2M    989.4M /run
tmpfs       tmpfs    [--------------------]    0%    989.4M    989.4M /dev/shm
/dev/sda2   ext4     [**------------------]   10%    826.2G    913.8G /home

Pour l'histoire de la troncation, cela devait être une feature que j'ai implémenté sur demande d'une personne. Je pensais que l'on ne perdait pas d'information pertinente mais il se trouve que cela semble être le cas.

Enfin, le recouvrement des colonnes est un véritable bug dont il faut que je m'occupe.
Merci d'avoir rapporté ces problèmes.

Ta remarque est très pertinente mais de toute façon, je ne vais pas avoir le temps de continuer à ce rythme. ;)

Les prochaines versions devraient être beaucoup plus espacées dans le temps maintenant que les fonctions principales que je souhaitais sont intégrées.

Oui, cela fait grosso-modo la même chose. Tu peux trouver deux captures d'écran de dfc(1) sur la page principale du wiki.

Ce ne sera pas le cas en raison de certains choix que j'ai effectués.
La première chose, c'est que l'affichage par défaut de dfc(1) utilise le format "human-readable". Je trouvais cela pertinent étant donné que la plupart du temps ces données sont lues par… des humains. Donc une option -h n'a pas tellement de sens.

L'autre raison vient du fait que df(1) utilise les options longues qui sont possibles en utilisant getopt_long(3) mais cette dernière est une extension GNU et je ne l'utilise pas (je me contente de getopt(3) et getsubopt(3)).

Pour le reste des options, elles sont quand même relativement similaires:
-a pour l'affichage de systèmes de fichiers pas forcément pertinent
-t pour filtrer en fonction du type
-T pour l'affichage du type de système de fichiers

C'est vrai que du coup, j'utilise par exemple -s au lieu de --total pour faire la somme mais de nouveau, c'est en raison de la non-utilisation d'options longues.

Bref, le mieux serait peut-être de ne pas faire d'alias vers df?

Je suis d'accord que ces limites ne sont pas forcément optimales.

Merci pour tes remarques, j'en tiendrais compte pour l'avancement de dfc.

Heu… regarde les commits dans le dépôt git?
Sinon, tu peux aussi afficher l'historique des versions dans la section "roadmap" du site et voir les changements apportés à chaque version. Ou encore, lire les annonces que j'ai rédigé pour chaque version.
Tu as le choix. ;)

Mais bon, dfc c'est grosso-modo 1200-1300 lignes de C, pas plus, donc y ajouter une fonctionnalité n'est pas comparable à ajouter une fonctionnalité à Firefox ou Chromium.

Pour continuer dans le rythme, je peux déjà dire que la 2.4.0 ne devrait pas trop tarder et apportera le support officiel de FreeBSD (merci à un lecteur de linuxfr!!).

Enfin bon, ce rythme tend à ralentir maintenant que la plupart des choses que je voulais ajouter l'ont étés. ;)

Le problème c'est que si je change cette limite, cela pourrait casser l'affichage chez d'autres personnes (spécialement si l'option -i est activée).

Cela serait possible de faire un calcul de la taille nécessaire mais… je ne suis pas sur que le jeu en vaille la chandelle. Enfin, si quelqu'un me propose un patch correct, je l'accepte volontiers. :)

Tu es sûr que ce n'est pas une question de largeur de ton terminal?

Chez moi cela fonctionne parfaitement, que ce soit avec xterm, le Terminal de Xfce, le tty ou encore rxvt-unicode.
Si jamais, il y a toujours l'option -f. Si le problème ne vient pas de là, alors c'est qu'il doit y avoir un bug.

Oui, le comportement consiste à ne pas afficher le graphe lorsque la largeur du terminal est <= 80. Dans ton cas, cela laisse peut-être un espace et l'affichage aurait été correct cependant la largeur pouvant varier énormément en fonction des points de montage, ce n'est pas forcément le cas. Il y a toujours l'option -f au cas où.

Tu as parfaitement raison pour le man. Je vais corriger cela.

Et puis non, non, pas de poisson d'avril ni de trojan (tu peux aller voir les sources, le tout étant sous licence BSD). J'avais écris la dépêche hier sans penser qu'aujourd'hui on était le premier avril! Et je n'avais d'ailleurs pas tout de suite compris le premier commentaire…