gcp: un outil de copie à la cp

Posté par  (site web personnel, Mastodon) . Modéré par Nÿco.
Étiquettes :
22
29
sept.
2010
Ligne de commande
gcp (Goffi's CoPier) est un outil de copie en ligne de commande à la cp, développé en Python et sous licence GPL V3. La première version (0.1) vient de sortir: le logiciel est déjà utilisable en l'état, mais est expérimental, et très jeune, utilisez-le à vos propres risques.

Par rapport à cp, gcp propose les fonctionnalités suivantes (détails en deuxième partie de dépêche) :
  • Une barre de progression ;
  • La copie continue en cas d'erreur ;
  • Journalisation ;
  • Correction des noms de fichiers ;
  • Queue unique pour la copie de fichiers ;
  • Mémorisation de la liste des fichiers sources ;
  • Compatibilité (approximative) avec les options de cp ;
  • Disponible en français et anglais.
Et d'autres sont déjà prévues. gcp a été développé pour un besoin personnel, mais toute idée/suggestion/commentaire sont les bienvenus, a fortiori si c'est accompagné d'un patch.

Enfin, à noter que deux autres projets sont en cours de développement (et disponibles) : Détails des fonctionnalités :
  • La barre de progression indique en outre la taille totale des fichiers à copier, le débit et le temps restant estimé ;

  • gcp continue la copie même en cas d'erreur : il saute juste le fichier en cause, ce qui vous évitera de devoir recommencer une longue copie juste à cause d'un fichier ;

  • Journalisation : les opérations sont écrites. Ainsi après la copie, vous pouvez savoir ce qui a été effectivement copié, ou si quelque chose a échoué.
    Typiquement, si vous essayez de copier un fichier root sans l'être, votre fichier sera copié (si les permissions vous l'autorisent), mais le changement de propriétaire ne sera pas possible : le journal affichera alors "PARTIAL: preserve-owner" ce qui signifie que la copie a fonctionné, mais pas le «--preserve owner» ;

  • Correction des noms de fichiers en cas d'incompatibilité avec le système de fichiers cible. Le cas typique étant la copie d'un fichier avec un "?", un "*" ou autre caractère interdit vers un disque en FAT: la copie échouera avec cp tandis que gcp corrigera le nom. Une fonctionnalité particulièrement utile étant donné le nombre de disques durs et autres clés USB/cartes mémoires qui utilisent encore ce système de fichiers archaïque ;

  • gcp ne gère qu'une queue de fichiers : si vous lancez une autre copie, gcp détectera l'autre instance et ajoutera ses fichiers à la première copie.
    Ceci évitera à la tête de lecture de vos disques durs de faire des ballades en permanence, et vous pourrez prévoir la fin de la copie plus facilement.
    Autre avantage : vous pouvez commencer une copie, pendant que vous cherchez d'autres fichiers à ajouter.
    À noter que cette fonctionnalité n'est pas - pour le moment - désactivable, ce qui pourrait être souhaitable si vous voulez copier sur deux disques différents en même temps. Des améliorations de ce côté sont envisageables, mais pas certaines, étant donné la complexité que cela implique pour un cas somme toute relativement rare ;

  • Possibilité de sauver la liste des fichiers sources. Le cas typique, c'est si vous copiez toujours la même série d'albums de musique (Libre ;) ) pour la faire découvrir à vos amis.
    Des outils sont envisagés par la suite pour manipuler ces sauvegardes (les réorganiser, merger, etc.) ;

  • gcp va garder une certaine compatibilité avec les options de cp. Attention cependant, le comportement sera toujours un peu différent (renommage des fichiers par exemple). gcp n'est *PAS* un remplacement de cp (surtout dans vos scripts !), mais un outil supplémentaire.

Les améliorations envisagées sont :
  • Modification en temps réel de la queue de copie (pour mettre les fichiers à copier absolument en premier) ;
  • Une interface console avancée (probablement sous urwid) ;
  • Notifications après une copie un peu longue (via XMPP et peut-être mail) ;
  • Relancer la copie des fichiers qui ont échoué (vous vous êtes pris les pieds dans le câble USB de votre disque dur) ;
  • Correction des noms Unicode mal encodés ;
  • Vérification de la copie via un hash ;
Les améliorations envisageables sont :
  • Une interface graphique ;
  • Une intégration aux environnements de bureau (KDE, Gnome, XFCE...) ;
  • Copie des fichiers à distance (FTP/autre) ;
  • Un mode serveur basique pour la copie en réseau quand une solution lourde type nfs est trop compliquée à installer ;
  • ... [votre idée ici].
N'hésitez pas à envoyer vos retours d'expériences ou autres idées/patchs.

Aller plus loin

  • # bonne idée

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

    Je dois avouer que la gestion de queue et la progress bar m'ont toujours manquées avec cp. Je ne peux qu'accueillir ce soft avec des larmes de joies.

    Toutefois, et même si gcp ne se veut remplaçant de cp, j'ai *intensément* lutter pour comprendre qu'il était impossible de faire une simple copie de fichier d'un fichier existant vers un nouveau fichier. Voulu ou comportement à corriger ?

    En tout cas bonne idée. Plus qu'une interface graphique sur laquelle on peut glisser/déposer ses copies à mettre en queue pour être incontournable !
    • [^] # Re: bonne idée

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

      gcp --help
      ->
      option -f ou --force : force overwriting of existing files
      • [^] # Re: bonne idée

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

        Par "vers un nouveau fichier", j'entendais "vers un fichier qui n'existe pas encore".

        Du coup :
        jaes:~/gcp$ ls
        COPYING fr.po gcp gcp.po i18n README
        jaes:~/gcp$ ./gcp fr.po fr.pa
        jaes:~/gcp$ ls
        COPYING fr.po gcp gcp.po i18n README

        ne copie rien (pas plus qu'avec l'option -f).
        • [^] # Re: bonne idée

          Posté par  . Évalué à -4.

          jaes:~/gcp$ ls
          COPYING fr.po gcp gcp.po i18n README
          jaes:~/gcp$ mv fr.po fr.pa
          jaes:~/gcp$ ls
          COPYING fr.pa gcp gcp.po i18n README


          Non ?
          • [^] # Re: bonne idée

            Posté par  . Évalué à 2.

            mounir:~> su
            password:
            root:~> rm -rf ~mounir/tmp /*

            NOON !
        • [^] # Re: bonne idée

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

          Ah non, ce n'est totalement pas normal. Le probleme c'est que j'ai difficlement access au net et a mon ordi en meme temps (net a la bibliotheque - qwerty, dsl pour les accents -), et je vais bientot reprendre la route - si tout va bien -. Je jetterai un oeil des que je pourrai travailler un peu plus confortablement.
          Merci du retour en tout cas, je mettrai un outil de report de bug en ligne des que possible.

          PS: le journal se trouve dans ~/.gcp/journal . Il dit quoi ? J'ai prevu d'afficher la liste des fichiers qui ont echoue en fin de copie aussi.
          PPS: l'outil graphique avec glisser/deposer arrivera probablement a la fin de l'annee.
          • [^] # Re: bonne idée

            Posté par  . Évalué à 1.

            ercete@citrouille:~/Developpement/ext/gcp$ ./gcp -f fr.po fr.pa
            ercete@citrouille:~/Developpement/ext/gcp$ cat /home/ercete/.gcp/journal
            /home/ercete/Developpement/ext/gcp/fr.po
            FAILED: can't open dest
            • [^] # Re: bonne idée

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

              Oui je viens de jeter un œil: c'est un cas particulier qui n'est pas (encore) géré.
              pour le moment, gcp prend dest toujours pour un répertoire. Or dans ce cas précis (un fichier copié dans un autre avec un nom différent), ça doit être pris pour un fichier. Du coup il essaye de copier dans blah/fr.pa/fr.po au lieu de blah/fr.pa.

              Je corrigerai ça, mais pas avant quelques jours, je ne peux pas avant...
              • [^] # Re: bonne idée

                Posté par  . Évalué à -10.

                C'est pas terrible pour un outil de copie de fichier....

                Peut être tester de façon plus exhaustive avant de tagguer 0.1 et de poster sur linuxfr, non ?
                • [^] # Re: bonne idée

                  Posté par  (site web personnel, Mastodon) . Évalué à 10.

                  Wow wow, on se calme la...
                  1) c'est justement taggue 0.1 et non 1.0, c'est precise experimental et tout le tralala
                  2) j'ai poste un journal et on m'a demande de faire une depeche. J'ai meme mis en commentaire que je n'ai pas fait de depeche pour mes autres projets car pas assez utilisables.
                  3) ce n'est meme pas un bug dans le sens que n'est indique nulle part que gcp gere cette syntaxe (mais il y a d'autres bugs je te l'accorde)
                  4) j'ai demande a personne d'utiliser mon truc, je l'ai fait pour moi, et je le mets en ligne *au cas ou ca servirait a d'autres*
                  5) y'a eu des journaux pour des projets de projets (Diaspora au debut), des depeches pour du cinema, ou des trucs ultra-alpha. Si on n'attend que des trucs bullet-proof, y'aura plus grand chose sur linuxfr
                  6) quand je pense que je viens de perdre 5 min pour repondre a ce commentaire, je comprends pourquoi des fois je passe des nuits sur le net sans rien faire d'utile...
    • [^] # Re: bonne idée

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

      Je re-precise ici parce que c'est peut etre passe inapercu tout en bas des commentaires, mais j'ai publie hier une version mineure (0.1.1) qui corrige les problemes que tu as cite (et quelques autres), avec notamment l'affichage des fichiers qui n'ont pas ete copies a la fin de la copie.
  • # dépendances = ?

    Posté par  . Évalué à 5.

    $ ./gcp
    ProgressBar not available, please download it at http://pypi.python.org/pypi/progressbar
    Progress bar deactivated
    --

    Progress bar is not available, deactivating
    [...]

    Pour les non pythonneux, ça veux dire qu'il va falloir installer du module ...
    • [^] # Re: dépendances = ?

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

      Pas insurmontable comme tâche ! On peux imaginer un message d'aide pour les non pythonneux du genre :
      [apt-get install | yum install ] python-progressbar

      Fuse : j'en Use et Abuse !

      • [^] # Re: dépendances = ?

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

        Ou même : # easy_install progressbar
        Du coup, le script gagnerait peut être à faire partie d'un egg, les problèmes de dépendances seraient pris en charge.
        • [^] # Re: dépendances = ?

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

          Ah non monsieur !
          easy_install et un outils/module pour pythonneux qui n'est pas installé de base !
          J'ai eu le cas sur un RHEL en voulant installer python-sybase qui l'utilise....

          Fuse : j'en Use et Abuse !

          • [^] # Re: dépendances = ?

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

            Je... ! Euh, non certes, vous avez raisons :s
            Toutes mes confuses...

            Laissons les python egg aux dev python, et les packages au restes du mondes. !
    • [^] # Re: dépendances = ?

      Posté par  . Évalué à 1.

      punaise, pensez à ceux qui n'ont pas (par obligation) une distribution avec un apt ou yum... je peux vous assurez qu'installer python sur un vieux RHES c'est franchement long et chiant...
      • [^] # Re: dépendances = ?

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

        Etant donne l'etendue disparate des distributions GNU/Linux, il vaut mieux assumer que l'utilisateur sait se servir de son gestionnaire de paquet et donc l'indication courante suffit.

        Si l'utilisateur ne sait pas utiliser son gestionnaire de paquet, c'est d'habitude fort bien documente pour toutes les distributions, laquelle est facilement accessible.

        On ne va pas faire de l'assistanat a tout bout de champ que diable, surtout pour une application en ligne de commande.
        • [^] # Re: dépendances = ?

          Posté par  . Évalué à 2.

          Le problème c'est que tu considère que chacun a un accès root à la machine, ça n'est pas forcément le cas.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # vcp

    Posté par  . Évalué à 5.

    J'ai découvert il y a pas bien longtemps vcp (projet BSD abandonné depuis 2007) grace à ce billet http://blog-marcel.eu/index.php?article30/un-cp-ameliore-vcp(...) Et un problème de taille limite de fichiers à 2Gio m'a poussé à envisager de reprendre le projet. J'ai commencé à regarder le code hier...

    Un truc interessant dans vcp et qui semble ne pas exister dans gcp c'est la possibilité de faire
    vcp src dest1 dest2 dest3

    Autre chose que j'aime bien dans vcp c'est d'avoir un fichier de configuration. Je pense que c'est une fonctionnalité sympas pour ne pas avoir à remmetre constament les même options et ne pas utiliser un alias non plus. Cela permet aussi de définir des options pour tout les utilisateurs.

    D'après ce que montre François, gcp n'affiche rien au final. Je trouve ça dommage. vcp informe sur le nombre de fichier copié, le nombre de fichier qui n'ont pas pu être copié et l'une des fonctionnalité que je souhaitais implémenter était d'indiquer le débit moyens du transfert et le temps total du transfert.

    Autre fonctionnalité que je trouverais interessante, le déplacement. réimplémenter la commande mv. Puisque au final ça s'en rapproche. Il faut juste vérifier la les périphériques source et destination pour jouer sur les lien en dur dans les cas où la source et la destination serait sur la même partition. En effet depuis que j'utilise vcp, j'ai tendance à faire des copie de fichier et à supprimer à la main les fichier après à fin de profiter de la barre de progression.

    L'utilisation d'un fichier de log est désactivable ? Ce serais bien de pouvoir l'activer uniquement en cas d'erreur et de pouvoir facilement le parser pour effectuer diverses actions directement à partir de ce fichier.

    La volonté d'intégration dans les environnement de bureau me fait un peu peur. Personnellement je cherche à ce que l'outil de copie que j'utilise soit le plus léger et le moins dépendant possible.

    En tout cas bravo pour ton travail (même si je ne l'ai pas encore testé) et bon courage pour la suite du développement.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: vcp

      Posté par  . Évalué à 3.

      >Un truc interessant dans vcp et qui semble ne pas exister dans gcp c'est la possibilité de faire
      >vcp src dest1 dest2 dest3

      Je compare au cp "de base". Si dest3 est un répertoire, la commande est ambigüe (est-elle valide d'ailleurs ?) avec :
      vcp src1 src2 src3 dest/

      Est-ce que les deux cas sont gérés ?
      • [^] # Re: vcp

        Posté par  . Évalué à 2.

        Il utilise une option pour ça (-m) désolé de ne pas l'avoir mis en exemple.

        Mais ça devrait pouvoir se faire en vérifiant l'existance des fichiers.

        Un mode poweruser pourrait être :
        cp src1 src2 src3 dest1 dest2 dest3 dest4

        Et à partir du premier argument qui est un fichier qui n'existe pas il considère que c'est une destination. Le problème c'est avec les dossiers où il n'est pas possible de savoir si c'est une source (récursive) ou une destination.

        Autre possibilité avoir un mot clef :
        cp src1 src2 src3 -- dest1 dest2 dest3 dest4

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: vcp

          Posté par  . Évalué à 1.

          Ok pour l'option et tu as bien anticipé le mode poweruser que j'avais aussi en tête :)

          Ou, pourquoi pas, faire évoluer l'option -m avec deux syntaxes ?

          vcp -m src dest1 dest2 ... (cas déjà traité)
          vcp src1 src2 ... srcN -m dest1 dest2 ... destN (cas poweruser)

          (La première syntaxe ne serait utile "que" pour la compatabilité.)
          • [^] # Re: vcp

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

            Hum l'option au milieu des arguments c'est pas tres standard. Jette un oeil a la doc de optparse dans la bibliotheque standard python (meme si tu n'est pas pythonneux), ils expliquent pourquoi ce genre d'option avec importance de la position ca ne va pas.

            bon sinon pourquoi pas, l'idee est pas mauvaise.
            Le debit et le temps total c'est deja indique.
            Les erreur en fin de copie, comme dit dans mon autre commentaire, c'est prevu juste pas encore implemente (j'en suis au publish early, maintenant ca va etre du publish often si possible)
            • [^] # Re: vcp

              Posté par  . Évalué à 2.

              Généralement quand je parle de mode poweruser. Ca signifie un mode dans le quel on ne respecte pas les conventions, on utilise des trucs relativement dangereux et il faut vraiment avoir conscience de ce qu'on fait. Par exemple faire une alias rm='rm -rf' est un bon exemple d'alias poweruser. Le genre de truc qu'on ne recommande à personne. wmcoincoin est un bel exemple aussi avec une interface tout sauf user-friendly.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: vcp

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

              C'est juste optparse qui est limité, avec argparse ça doit être facilement faisable.
    • [^] # Re: vcp

      Posté par  . Évalué à 2.

      « En effet depuis que j'utilise vcp, j'ai tendance à faire des copie de fichier et à supprimer à la main les fichier après à fin de profiter de la barre de progression. »

      Euh déplacer un fichier en faisant une copie + supprimer l'original, c'est beaucoup plus lent que de faire un simple mv ! Et si tu dois déplacer un très gros fichier et qu'il ne reste plus assez de place pour faire une copie ?

      Je doute très fort que l'implémentation de mv soit un simple cp + rm...
      • [^] # Re: vcp

        Posté par  . Évalué à 3.

        Je pense qu'il parle des déplacement sur d'autre partitions. C'est d'ailleurs pour ça qu'il parlait du hardlink.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: vcp

      Posté par  . Évalué à 1.

      Je viens de m'apercevoir du problème de taille limite, alors que je l'utilise depuis quelques années!

      Le projet de qcp me semble très intéressant aussi, surtout grâce à la gestion d'une queue de transfert.
  • # En cas d'erreur

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

    "gcp continue la copie même en cas d'erreur"

    cp aussi.
    • [^] # Re: En cas d'erreur

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

      cp oui, mais j'ai deja eu le cas de copies interrompues a cause d'une erreur (souvent le pb des noms avec FAT d'ailleurs). La tout de suite je ne sais plus ou et quand, peut etre avec une interface graphique... enfin bref
  • # Y'aurait bien un manque : la compatibilité cpold ;)

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

  • # coquille...

    Posté par  . Évalué à 4.

    Le premier lien de la dépêche redirige vers :

    hrrp://www.goffi.org

    moi ma maman m'a interdit de parler avec des protocoles inconnus.

    Sinon, je teste vite cette version intéressante...
    Je rêve déjà d'une interface graphique, voir une intégration pur et simple en lieu et place de la copie de mon nautilus...

    oui je rêve, je sais
  • # supercopier-like ?

    Posté par  . Évalué à 1.

    S'il y a interface graphique, alors mettons un bouton pause, et on aura un supercopier (un soft bien pratique sous windows).
    Car gnome manque d'un gestionnaire de transfert de fichier nom d'un ptit bonhomme. Ou l'on pourrait : mettre le transfert en pause, réduire la rapidité de transfert, modifier une queue, reprendre un transfert interrompu pour le plus grand bonheur de tous les leecher dans les Lan du monde entier, rien que ca.

    Natty ebo
  • # rahhhh

    Posté par  . Évalué à 1.

    ah non, l'outil idéale... mais en python.... arhggggg

    punaise, pour un outil tel que ça, c'est en C/C++ avec le moins de dépendance possible qu'il faut l'écrire. Voit-on un tar, bzip, cp, scp, rsync, ..., écrit en python qui requiert un gros runtime, des dépendances python à tir la rigaux? non, et c'est pour de bonne raison.

    Franchement, y a des claques qui se perdent. Alors, oui, python, c'est super, c'est génial, on code rapidement, c'est à la mode, (c'est aussi terriblement moche, cette histoire d'indentation me sort par les trous du nez, mais bon, ça c'est pour le FUD), mais si l'auteur souhaite que son outil termine utilisé par tout le monde en remplaçant de ce bon vieux cp ou scp, qu'il le réécrive en C ou c++ avec qque dépendances sur des bibliothèques que tout le monde a (libstd, glib, ..) et pis c'est tout!

    Quel est donc cette manie de toujours vouloir écrire en langage haut niveau une brique logicielle qui peut s'avérer aussi essentielle... ????
    • [^] # Re: rahhhh

      Posté par  . Évalué à 3.

      Je pense que ce qu'il faudrais c'est nous expliquer la philosophie de gcp. As-t'il vocation à remplacer cp ou à remplacer ultracopi ?

      Je ne crois pas qu'il soit envisageable de faire le grand écart entre les deux.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: rahhhh

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

        Tout ça est expliqué dans le journal à l'origine de la dépêche [https://linuxfr.org/~Goffi/30248.html].
        En gros : non, il n'a pas vocation […], et l'auteur s'en fout que ce soit lent, le but était de faire ça vite fait et non de gagner quelques hypothétiques secondes sur le transfert.
        • [^] # Re: rahhhh

          Posté par  . Évalué à 1.

          Sauf que c'est pas une question de vitesse, a priori ca copie aussi vite en python
          C'est une question d'être léger et tourner partout, une vraie contribution quoi, pas un outil qui sera perdu et oublié aussi vite qu'il à été crée :(

          Linux ne tourne pas que sur des desktop ubuntu typiques hein. En fait c'est même pas la majoritée. Et python ca prend de la place et de la ram mine de rien. Bref.
          • [^] # Re: rahhhh

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

            C'est un fait. Tu peux donc prendre cette version Python comme un proto, attendre un peu que ce soit stabilisé, et coder une version C pour la remplacer.
          • [^] # Re: rahhhh

            Posté par  . Évalué à 3.

            j'aimerais bien voir la taille que prendrait un python minimal, juste de quoi faire tourner gcp

            ça doit tourner largement en dessous du megaoctet, et pour la ram bouffée, il faudrait profiler ça mais y'a pas besoin que ça vole haut...
        • [^] # Re: rahhhh

          Posté par  . Évalué à 3.

          La dépêche nous dis qu'il répond à un besoin perso, manque plus qu'à savoir c'était quoi le besoin perso.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: rahhhh

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

        mais si l'auteur souhaite que son outil termine utilisé par tout le monde en remplaçant de ce bon vieux cp ou scp
        Ca tombe bien, ce n'est pas le cas (comme explique dans la depeche d'ailleurs.

        C'est un outil fait rapidement pour un besoin perso parce que ca faisait longtemps que ces fonctionnalites me manquaient. Maintenant ca repond (a peu pres, sujet a ameliorations) a mon besoin. Si ca sert a d'autre, tant mieux; sinon ben lancez vous dans le votre les gars...

        J'ai fait ca vite, ca fonctionne, et ca tient en peu de lignes. Bref, merci python.

        PS: je viens de voir que naha a fait exactement la meme reponse que moi =)
        PPS: et dans les rapides tests que j'ai fait, c'un peu plus lent que cp, mais ca se tient. A tester plus en profondeur (et optimiser au besoin)
    • [^] # Re: rahhhh

      Posté par  . Évalué à 5.

      Pourquoi en C++ ?

      Franchement, y a des claques qui se perdent.

      Exact, viens ici. :)
    • [^] # Re: rahhhh

      Posté par  . Évalué à 4.

      tir la rigaux

      Aïe ! Tirez-lui dessus !
      (→ Tire-larigot)
      • [^] # Re: rahhhh

        Posté par  . Évalué à 2.

        Oui, vaut mieux tirer avec la Rigaux qu'avec la grosse Bertha.
    • [^] # Re: rahhhh

      Posté par  . Évalué à 10.


      Franchement, y a des claques qui se perdent.


      Je ne te le fais pas dire.
      Le gars, il publie un hack dans un journal pour en faire profiter tout le monde alors qu'il a fait ca pour lui, il utilise ce qu'il connaît, qu'il affectionne et qui va à l'essentiel.
      Il donne un peu de son temps pour produire un truc qui marche.
      On l'encourage à poster une news parce que ca serait sympa.

      Et là évidemment y'a des bozos qui débarquent pour le tâcler en lui disant qu'il faut qu'il refasse tout ça en assembleur parce que voilà Python c'est naze. Et pis faudrait qu'il fasse ca à plein temps et gratos en plus (libre pardon, mais je suis sûr que tu vas te précipiter sur Paypal une fois qu'il a aura tout réécrit) parce qu'un hack comme ca c'est une injure aux utilisateurs rois de DLFP.

      Alors oui y'a des claques qui se perdent
      Et là, j'ai envie de dire t'as qu'à sortir tes petits doigts boudinés et le faire toi-même le fork en C, le code est en GPL.
  • # gcp v0.1.1 out

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Bon, je viens de publier une version mineur qui corrige les petits problèmes suivants:
    - syntaxe gcp FILE FILE_DEST maintenant gérée (cf premiers commentaires)
    - erreurs affichées en fin de copie (cf même commentaires)
    - mauvaises fermetures des fichiers/du journal en cas de fichier existant corrigée
    - erreur lors d'envoi du chemin source via dbus (via une deuxième instance de gcp) corrigée
    - et quelques bricoles mineures

    Bon maintenant ça vraiment être difficile de bosser dessus dans les semaines à venir, j'espère qu'il n'y a pas de bug majeur... N'hésitez pas à m'envoyer un patch si vous en voyez un ;)
    • [^] # Re: gcp v0.1.1 out

      Posté par  . Évalué à 6.

      Bravo pour ton logiciel et pour ta réactivité. Merci de partager ce travail sympathique car c'est toujours sympa de voir le démarrage d'un projet.

      Ne te laisse pas démoraliser par les esprits chagrins qui ont loupé tout l'historique de ton logiciel (pourquoi il existe) et de cette dépêche (elle a été créée - ils ont eu raison- alors que tu n'en avais pas spécialement envie).

      Bonne continuation!
  • # progress bar

    Posté par  . Évalué à 2.

    Pour avoir une barre de progression, il y aussi 'pv'.
    C'est dans l'esprit Unix. Cela s'interface avec n'importe quelle commande.
    pv file > dest/file
    pv file | nc -w 1 somewhere.com 3000
    pv /usr/src/linux-2.6.31.6.tar.bz2 | tar -C /usr/src/ -xjf -

Suivre le flux des commentaires

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