Journal libetc: faire le ménage dans son $HOME, la fin des fichiers de configuration cachés (dotfiles)

Posté par  (site web personnel) .
Étiquettes : aucune
0
24
avr.
2005
Sur ma machine j'obtiens:

% ls -d ~/.* | wc -l
421

Comme j'ai déjà du mal à classer tous les fichiers que je génère moi même, je préférerai mettre mes fichiers de configurations cachés "dotfiles" ailleurs. $HOME/$ETC me semble une bonne solution.

J'ai donc rapidement écrit une petite bibliothèque à charger avec LD_PRELOAD afin de rediriger tous les appels vers $HOME/.fichier vers $HOME/etc/fichier

Le code semble fonctionner avec les programmes que j'utilise tous les jours (sauf avec gimp pour le moment). Je pense que je vais donc utiliser cette bibliothèque tous les jours.

Pour ceux que cela intéresse, le code se trouve à l'adresse suivante:
http://ordiluc.net/fs/libetc/(...)

Ce problème avec les fichiers de configuration semble évoqué relativement souvent. Par exemple j'ai trouvé:
http://lists.debian.org/debian-policy/2003/01/msg00056.html(...)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282067(...)

Mais à part des solutions basées sur des liens je n'ai rien de trouvé de bien utile, c'est pour ça que j'ai écrit ces quelques lignes de C.

  • # freedesktop.org

    Posté par  . Évalué à 10.

    range les plutôt dans $XDG_CONFIG_HOME ( $HOME/.config par défaut)

    • [^] # Re: freedesktop.org

      Posté par  (site web personnel) . Évalué à 4.

      Merci beaucoup pour cette information. Je ne connaissais pas cette variable (il faut dire que le nom est un peu tordu !). Cela fera parti des prochaines modifications.

      • [^] # Re: freedesktop.org

        Posté par  . Évalué à 1.

        XDS = X Direct Save : http://www.newplanetsoftware.com/xds/(...)
        ça fait partie du projet freedesktop.org qui a pour but une bonne interopérabilité entre les différents bureau X.

        $XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.


        trad:
        $XDG_CONFIG_HOME definit le dossier de base où les fichiers de configuration spécifiques à un utilisateur devraient être stockés. Si $XDG_CONFIG_HOME n'est soit pas défini, soit vide, un dossier par défaut égal à $HOME/.config devrait être utilisé.


        C'est sûr que c'est pas ce qui vient en premier à l'esprit.

  • # Je suis pas sur de comprendre ton problème

    Posté par  (site web personnel) . Évalué à 3.

    Qu'est ce que ca va changer, le faite de déplacer les fichiers de config dans un autre répertoire ?

    • [^] # Re: Je suis pas sur de comprendre ton problème

      Posté par  (site web personnel) . Évalué à 9.

      Bah déjà ca evite de les avoir constamment sous les yeux quand on utilise un soft qui affiche les fichiers cachés. (genre moi ca m'arrive tous les jours quand je lance gftp et c'est vrai que c'est chiant...)

      C'est donc une très bonne idée, et je vais tester ca dès ce soir

      • [^] # Re: Je suis pas sur de comprendre ton problème

        Posté par  . Évalué à 9.

        Bah déjà ca evite de les avoir constamment sous les yeux quand on utilise un soft qui affiche les fichiers cachés.

        Faire une lib pour cacher les fichiers cachés ?

        Ok je -> []

      • [^] # Et avec Bluefish

        Posté par  . Évalué à 5.

        J'aime assez Bluefish mais l'explorateur de fichiers est vraiment mal foutu et il n'y pas moyen de masquer les fichiers cachés... Cette solution est peut être pratique... Si ce n'est pas prendre un marteau piqueur pour écraser une mouche

        • [^] # Re: Et avec Bluefish

          Posté par  (site web personnel) . Évalué à 2.

          Le marteau piqueur serait d'envoyer tout ça dans une base mysql. Là ce n'est qu'environ 600 lignes de C.

          Remarque le coup de la base Mysql ca pourrait servir pour partager sa config entre plusieurs machine (si on n'aime pas nfs et compagnie). Faut que je réflechisse à ça !!!

          • [^] # Re: Et avec Bluefish

            Posté par  (site web personnel) . Évalué à 4.

            Oui enfin le principe d'Unix c'est d'"hériter" de la configuration qui se trouve
            normalement sous /etc et de redéfinir tes préférences à toi dans tes .config.

            Après il y a l'approche gconf qui n'a pas l'air de faire l'hunanimité ....

            • [^] # Re: Et avec Bluefish

              Posté par  (site web personnel) . Évalué à 1.

              Le principe d'Unix sous AIX et HP-UX c'est d'avoir $HOME = / pour l'utilisateur root. Ca fait un beau bazarre au bout d'un certain temps si on ne crée pas un /root ou quelque chose du genre.

              Et pour gconf y a aussi des trucs qui existent sur les Unix classique. La base ODM sous AIX est un exemple. Ils y en a qui aiment... moi je trouve que pour faire des sauvegardes/restaurations ca complique la vie.

      • [^] # Re: Je suis pas sur de comprendre ton problème

        Posté par  (site web personnel) . Évalué à 4.

        >genre moi ca m'arrive tous les jours quand je lance gftp et c'est vrai que c'est chiant...

        Et c'etait pas plus simple de patcher gftp?

        • [^] # Re: Je suis pas sur de comprendre ton problème

          Posté par  (site web personnel) . Évalué à 5.

          Si il n'y avait qu'un seul logiciel à patcher... la réponse serait oui, bien sûr. Mais là il faudrait tout patcher.

          Et par rapport à gftp, on peut imaginer un bouton : afficher / cacher les fichiers de config. Mais le jour où on veut envoyer son .profile il faut retourner dans les préférences et faire la manip inverse... c'est lourd.

          Je préfère que mes fichiers de configuration soient là où je le souhaite. J'imagine bien que pour certaines personnes cela ne pose pas de problèmes d'avoir 400 fichiers cachés. Pour moi si. Par exemple j'ai des trucs du genre:

          % ls -lta ~/ | tail -n 3
          -rw-r--r-- 1 luc luc 852 1997-07-23 15:29 .FilesMagic
          -rw-r--r-- 1 luc luc 59 1997-07-20 21:12 .xkoules.opt
          -rw-r--r-- 1 luc luc 55 1997-07-18 15:54 .life

          Je ne sais même plus à quoi cela correspond.

          • [^] # Re: Je suis pas sur de comprendre ton problème

            Posté par  (site web personnel) . Évalué à 3.

            > -rw-r--r-- 1 luc luc 55 1997-07-18 15:54 .life

            Je ne sais même plus à quoi cela correspond.

            Life? Mhhh, c'est pas grave, tu n'en as plus besoin maintenant.

          • [^] # Re: Je suis pas sur de comprendre ton problème

            Posté par  (site web personnel) . Évalué à 2.

            En même temps, les fichiers ".*" comme fichiers cachés, c'est dans les standards Unix depuis des lustres, et ça me semble plutôt une faiblesse de gftp de ne pas suivre cette convention...
            D'ailleurs, la boite "ouvrir" de GTK2.4+ proposent une case à cocher "afficher les fichiers cachés" sur clic-droit (mais elle n'est malheureusement pas utilisée par tous les programmes, notamment Firefox ou gftp...


            Soit dit en passant, je ne trouve pas gftp bien terrible, l'interface n'est pas très pratique (et ne semble pas suivre le HIG) et il gère très mal les déconnexions intempestives. Je préfère encore utiliser Nautilus.

  • # Bonne idée

    Posté par  (site web personnel) . Évalué à 5.

    C'est une très bonne idée.

  • # syscall

    Posté par  . Évalué à 5.

    et comment tu fais si une appli utilise directement les fonctions open/read/write au lieu des fonctions de la libc ?

    Voir pire s'il y a un mix des 2...

    • [^] # Re: syscall

      Posté par  (site web personnel) . Évalué à 2.

      Le problème se pose aussi avec les applis liées statiquement. On peut toujours imaginer un module dans le noyau. Enfin dans ces cas là je préfere tout de même laisser écrire l'application là ou elle veut. Faut être tordu pour ne pas utiliser les fonctions de la libc pour lire/écrire un fichier.

      J'ai testé le truc avec firefox, thunderbird, gnome, kde, openoffice... A première vue cela semble fonctionner. Enfin pour faire des tests vaut peut être mieux créer un nouveau compte, ce que je fais pour le moment. Mais je pense que maintenant c'est utilisable. Je vais donc pas tarder à utiliser ça avec mon compte de tous les jours. Mon seul problème c'est que j'ai un bug avec gimp.

  • # $HOME/perso

    Posté par  . Évalué à -2.

    ou alors déplacer tes fichiers à toi dans par exemple,

    $HOME/perso

    et hop!

    ls -d ~/perso/* | wc -l
    0

    • [^] # Re: $HOME/perso

      Posté par  (site web personnel) . Évalué à 0.

      Pourquoi moinser ?
      Même si ce n'est pas la solution la plus élégante, c'est une solution qui est je pense assez utilisée ...

    • [^] # Re: $HOME/perso

      Posté par  (site web personnel) . Évalué à 0.

      Pourquoi moinser ?
      Même si ce n'est pas la solution la plus élégante, c'est une solution qui est je pense assez utilisée ...

  • # Elektra

    Posté par  (site web personnel) . Évalué à 4.

    Tu pourrais être intéressé par le projet Elektra :
    http://elektra.sf.net/(...)

    Au début de ma lecture, j'étais _très_ dubitatif, d'autant plus que le projet s'appelait Linux Registry, ce qui a réveillé mes vieux ressentiments contre la base de registres Windows et tous les problèmes qu'elle pose.
    Mais en fait, c'est vraiment classe, et ça élimine les problèmes de la base de registres Windows, tout en gardant ses avantages théoriques (MS est fort pour avoir des bonnes idées et mal les implémenter, donc autant garder l'idée et l'implémenter correctement).

    La constatation est que les fichiers de configuration utilisent toujours un système de clés/valeurs, ainsi qu'une arborescence éventuellement. Et c'est tout.
    Le but est donc de créer une API globale pour faire ça, afin d'avoir un comportement cohérent. En effet, qui n'a jamais été désapointé (voire soûlé) par les formats inutilement différents de chaque fichier de configuration...

    Ce n'est pas exactement lié à ton besoin, mais ça y répond par effet de bord.

    • [^] # Re: Elektra

      Posté par  . Évalué à 1.

      Le problème est qu'on revient encore au fait de devoir patcher toutes les applications.

      Et au vu des discusions houleuses ya quelque mois concernant ce projet, je crois que c'est loin de devenir un standarts

    • [^] # Re: Elektra

      Posté par  . Évalué à 0.

      MS est fort pour avoir des bonnes idées et mal les implémenter

      MS est surtout trés fort pour piquer les bonnes idées des autres... t'es sûr que la base de registre est une idée à eux ?

      Pour ce qui est de l'implémentation par contre, on est d'accord ;) mais ne pas oublier que dans la majorité des cas, leurs 'problèmes' d'implémentation ne sont pas des bugs, mais des 'fonctionnalités'.

  • # copyright

    Posté par  (site web personnel) . Évalué à 2.

    Ya un truc bizarre dans libetc.h quand même.
    * libetc - Copyright (C) 2005 Luc Dufresne <luc@ordiluc.net>
    [notice GPL]
    /* code pasted from various glibc include files */
    [code]
    À moins que tu n'ais écrit les .h de la glibc toi même :)

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.