Pour ceux ayant raté ma dépêche présentant dfc(1) le 1er avril dernier, sachez qu'il s'agit d'un utilitaire en ligne de commande se voulant une alternative au vénérable df(1), apportant notamment de nombreuses options supplémentaires ainsi qu'un affichage coloré comportant des barres de graphe.
Plusieurs lecteurs de LinuxFr.org avaient fait part de leurs suggestions d'améliorations et requêtes de nouvelles fonctionnalités en commentaire de la dépêche et elles ont pour la plupart pris place dans cette nouvelle version majeure de dfc(1), aux côtés d'autres améliorations.
Au rayon des améliorations d'ordre général, on peut citer le support de l'internationalisation comportant la traduction complète de dfc(1) vers le français, un fichier de configuration optionnel ainsi qu'une amélioration conséquente de la fonctionnalité d'auto-ajustement.
dfc(1) 3.0.0 présente également un meilleur support multi-plateforme puisque les utilisateurs de Mac OS X bénéficient maintenant également de l'option -o permettant d'afficher les options de montage et que l'utilitaire a été porté sous DragonFly BSD, NetBSD ainsi qu'OpenBSD. De nouvelles options font également leur apparition :
- -d permet d'afficher la taille utilisée (et oui, cela n'existait pas avant !)
- -e permet l'export vers les formats CSV, TeX et HTML. Voici un exemple d'export HTML en couleur et un exemple d'export sans couleur.
- -l permet d'afficher uniquement les systèmes de fichiers locaux (option similaire à celle existant dans df(1))
- -p permet de filtrer le résultat en fonction du système de fichiers. Par exemple, dfc -p /dev/sd limitera le résultat aux système de fichiers /dev/sd*, etc.
- -q trie le résultat en fonction du nom du système de fichiers, du type de système de fichiers ou du point de montage.
Le fonctionnement de ces nouvelles options est évidemment documenté dans la page de manuel.
Cette version de dfc(1) a également subit une refonte du code afin de s'adapter aux nouvelles contraintes et a connu diverses optimisations et corrections de bugs. Le bug le plus notable ayant été corrigé concernait les utilisateurs de FreeBSD pour lesquels les informations affichées pouvaient être incorrectes. Finalement, j'aimerais profiter de cette dépêche pour remercier les contributeurs ayant révisé le code, fournit des patches ou maintenant des paquets dfc(1).
A ce propos d'ailleurs, dfc(1) est maintenant présent dans les dépôts de Debian testing et unstable et est par conséquent également disponible dans les dépôts de la future Ubuntu 12.10. Il est aussi toujours disponible dans les dépôts de Mageia 2, Frugalware current et les ports FreeBSD. Les utilisateurs d'Archlinux peuvent toujours installer dfc(1) via AUR et ceux de Gentoo via l'ebuild proposée par Laurent Bachelier.
Aller plus loin
- Site officiel du projet (2188 clics)
- Annonce de la version 3.0.0 (221 clics)
- Wiki (279 clics)
- FAQ (115 clics)
# Paquet sourcemage créé
Posté par KaZeKaMi (site web personnel) . Évalué à 7.
Merci pour cet utilitaire bien sympathique !
Je viens de créer un paquet pour la distribution SourceMage GNU/Linux, il devrait être dispo dans les prochaines heures.
[^] # Re: Paquet sourcemage créé
Posté par Rolinh (site web personnel) . Évalué à 2.
Merci à toi pour le paquet !
# Problème de compilation
Posté par barmic . Évalué à 2.
En suivant le README, je tombe sur cette erreur quand je lance make :
Je vois pas ce que j'ai raté (j'ai juste fais mkdir build && cd build && cmake .. && make).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Problème de compilation
Posté par Rolinh (site web personnel) . Évalué à 1.
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)?
[^] # Re: Problème de compilation
Posté par barmic . Évalué à 2.
Debian stable, architecture AMD64 avec un noyau 3.3.7.
Par acquis de conscience j'ai refais tout le processus et voici l'ensemble des log :
Il semble qu'il trouve tout.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Problème de compilation
Posté par Rolinh (site web personnel) . Évalué à 2.
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.
[^] # Re: Problème de compilation
Posté par barmic . Évalué à 2.
Je serais un peu surpris mais peut être.
Merci. Ne te prend pas trop la tête pour moi non plus.
J'avais oublié d'essayer. J'ai la même erreur.
Je me suis installé la version 2.5 depuis Desbian testing ça fonctionne même si ce n'est pas la dernière version.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Problème de compilation
Posté par Rolinh (site web personnel) . Évalué à 2.
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.
[^] # Re: Problème de compilation
Posté par barmic . Évalué à 3.
Merci de ton aide c'est ce que je vais faire :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Problème de compilation
Posté par laurentb (site web personnel) . Évalué à 2.
En fait le
CMakeLists.txt
détecte la présente delibintl
, et active ou désactiveENABLE_NLS
selon ça. Je n'aime pas trop ce comportement, mais heureusement commeoption()
est utilisé, on peut l'écraser avec un-D
.Peut-être que ça ne marche pas avec les versions plus anciennes, en tout cas avec celles de Gentoo (2.8.7) ça me permet de supporter les deux modes !
Sur ce… ebuild mis à jour, et bien mieux écrit que le précédent !
[^] # Re: Problème de compilation
Posté par Rolinh (site web personnel) . Évalué à 1.
Ce comportement est dû au fait que le support des traductions nécessite la
libintl
. Par conséquent, le comportement consiste à désactiver automatiquement le support des traductions si cette bibliothèque n'est pas trouvée plutôt que de tenter une compilation et échouer ensuite. Évidement, il est possible d'activer/désactiver manuellement le support des traductions via-DNLS_ENABLE=false
comme cela est expliqué dans leREADME
.Donc je ne comprend pas pourquoi ce comportement te dérange tant.
Merci pour l'ebuild ;)
[^] # Re: Problème de compilation
Posté par laurentb (site web personnel) . Évalué à 1.
Globalement pour cette raison http://www.gentoo.org/proj/en/qa/automagic.xml
Mais du moment que ça se force (dans un sens comme dans l'autre), ce n'est pas un problème !
[^] # Re: Problème de compilation
Posté par Corentin Chary (site web personnel) . Évalué à 2.
Elle est où l'ebuild de la 3.0.0 ? Que je mette ça dans gentoo-x86 (avec les metadata.xml si possible) :).
[^] # Re: Problème de compilation
Posté par Corentin Chary (site web personnel) . Évalué à 3.
Trouvée, rajoutée dans l'arbre gentoo officiel :).
[^] # Re: Problème de compilation
Posté par Rolinh (site web personnel) . Évalué à 1.
Merci à toi :)
[^] # Re: Problème de compilation
Posté par laurentb (site web personnel) . Évalué à 1.
Wahou merci !
Il faudrait que je participe à Sunrise, plutôt que de faire ça dans mon coin… surtout depuis qu'il n'y a plus de Subversion.
# Disponible sur archlinuxfr
Posté par cdeblesson . Évalué à 4. Dernière modification le 31 mai 2012 à 20:54.
Tout est dans le titre.
Pour moi qui ai le
df -h
compulsif, ça me change la vie.Merci à toi, tu fais mon jour.
[^] # Re: Disponible sur archlinuxfr
Posté par fabricius . Évalué à 10.
Quelle affreuse francisation du "you made my day"!!!
# il y a aussi
Posté par Bayet Thierry . Évalué à 2.
pydf, mais c'est vrai que c'est du python.
[^] # Re: il y a aussi
Posté par pralines . Évalué à 2.
tiens, c'est curieux, les 2 utils ne me renvoient pas le même % d'utilisation, 5 points d'écart !
la sortie de dfc semble en accord avec celle de df qui semble en erreur sur le calcul du % d'utilisation ???
taille = 206664892
utilisée = 183537924
disponible = 12780996 (ça ne correspond pas à la soustraction taille-utilisée !!!
% d'utilisation = 94% pour df et dfc, 88.8% pour pydf
un utilitaire fait le rapport entre taille/utilisée et l'autre entre taille/disponible
et comme disponible contient une valeur que je ne comprends pas
Envoyé depuis mon Archlinux
[^] # Re: il y a aussi
Posté par pralines . Évalué à 3.
hum, je soupçonne que ces 5 points d'écart sont les 5% réservés pour le root en ext3/4
Envoyé depuis mon Archlinux
[^] # Re: il y a aussi
Posté par Rolinh (site web personnel) . Évalué à 2.
Effectivement, l'entier de la taille des partitions n'est pas utilisable par l'utilisateur. D'ailleurs, la structure
statvfs
(décrite dansstatvfs(3)
) distingue clairement la taille "libre" de la taille "disponible". Ce qui est libre ne correspond pas à ce qui est disponible et cela dépend aussi du système de fichiers.Pour
dfc(1)
, je calcule le pourcentage utilisé en fonction de l'espace disponible restant pour l'utilisateur.# Hum
Posté par Nicolas Blanco (site web personnel) . Évalué à 3.
DFC… à ne pas confondre avec l'utilitaire DTC, qui lui à bien la réponse à tout.
hou il est tard je vais aller me coucher :D
[^] # Re: Hum
Posté par Bayet Thierry . Évalué à -4.
«DTC» est-elle une réponse à tout? Je dirais non, car la grande réponse à: «la grande question à propos de la vie, l'univers et le reste» est quand même 42.
[^] # Re: Hum
Posté par zebra3 . Évalué à 7.
Non, c'est une réponse à « où ? ».
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Couteaux suisses
Posté par zebra3 . Évalué à 6.
Merci pour cet outil, il m'a l'air rudement pratique.
C'est à utiliser avec ncdu, qui remplace du de manière plus graphique et permettant des actions directes sur les répertoires.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Couteaux suisses
Posté par Sébastien Wilmet . Évalué à 1.
Pareil top -> htop.
Ce qu'il me manque, c'est un cp et mv --progress. J'avais testé une fois un script de ce genre, mais c'était plus un hack qu'autre chose, en utilisant tar (sans compression) dans une série de pipes.
[^] # Re: Couteaux suisses
Posté par Juke (site web personnel) . Évalué à 1.
Tu as pv qui peut être pratique :
http://www.ivarch.com/programs/pv.shtml
[^] # Re: Couteaux suisses
Posté par Sébastien Wilmet . Évalué à 1.
Justement, je trouve ça bête d'utiliser des pipes (donc plusieurs processus) dans l'unique but d'afficher la progression. D'ailleurs ça ne m'étonnerait pas que le script que j'avais testé se basait sur pv… cp et mv n'ont besoin que d'un seul processus, à ma connaissance.
Je ne sais plus pourquoi je n'utilise plus le script, sans doute pcq il était trop limité (peu ou pas d'options, …).
L'affichage de la progression devrait être implémenté directement dans l'outil qui effectue la copie ou le déplacement des fichiers. Cela n'exclus évidemment pas le fait que l'outil utilise une bibliothèque pour l'affichage de la progression (mais je ne sais pas si une telle bibliothèque existe).
[^] # Re: Couteaux suisses
Posté par laurentb (site web personnel) . Évalué à 1.
Il ne me semble pas que pv soit considéré comme un affichage de progression fait pour remplacer ceux intégrés. C'est plutôt utile pour les cas où ça n'a pas été prévu, ou surtout que c'est inhabituel.
Pour le --progress, rsync peut remplacer cp avec quasiment les mêmes options. Il y a beaucoup d'autres raisons de l'utiliser à la place de cp en plus.
Pour le mv, c'est plus compliqué (il faudrait détecter l'intérêt d'utiliser rsync --remove-source-files suivant les cas).
[^] # Re: Couteaux suisses
Posté par Alex . Évalué à 3.
De tête, mon alias est rsync -aP (mais je n'ai pas de machine pour vérifier)
Il me semble que le cp de gentoo était patcher pour avoir une barre de progression, avec l'option -g
il me semble également qu'il éxiste une réecriture de certains coreutils en ruby et en python, avec de la couleur, des barres de progressions et d'autres option s sexy… mais je n'arrive plus à me rappeler du nom
[^] # Re: Couteaux suisses
Posté par laurentb (site web personnel) . Évalué à 2.
Ça n'a pas duré (je ne sais plus pourquoi).
[^] # Re: Couteaux suisses
Posté par zebra3 . Évalué à 4.
En ncurse, Midgnight remplit bien ce rôle, surtout si on connait quelques raccourcis par cœur (+ et - pour sélectionner ou déselectionner par motif, * pour inverser, F5 et F6 pour copier et déplacer) et ses deux listes sont toujours aussi pratiques.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Couteaux suisses
Posté par Sébastien Wilmet . Évalué à 1.
Ça tombe bien, ça faisait un petit temps que je comptais essayer mc (tout comme zsh qui est sur ma todo list depuis des lustres… /me sifflote).
[^] # Re: Couteaux suisses
Posté par barmic . Évalué à 3.
De tête je te dirais vcp (plus maintenu et limité a des fichiers de 2Gio) ou gcp dont on a parlé ici écris en python.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Couteaux suisses
Posté par Nonolapéro . Évalué à 4.
Tu as aussi Gcp écrit par Goffi qui poste régulièrement dans le coin. Voici la copie de la page de présentation (http://wiki.goffi.org/wiki/Gcp)
# Sur Mageia
Posté par Axone . Évalué à 3.
Je ne connaissais pas cet utilitaire, mais je vois avec plaisir qu'il est dans les dépôts de ma Mageia 2 fraîchement installée. Evidemment, ce n'est pas la version 3, mais la 2.4 qui apporte déjà beaucoup par rapport à df.
Merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.