Convertir l'arbre CVS des ports en git (round 2)
Il y a quelques mois je cherchais tranquillement à convertir l'arbre cvs des ports FreeBSD en arbre git.
Ça avait bien marché, mais il y avait deux inconvénients majeurs :
- C'était trop long a faire
- Les mises à jours était horrible à faire.
Et puis hier, gaston me montre ça nonchalamment, puis ça, bon j'y crois pas trop mais je me lance
Récupération du CVSROOT
Créer le fichier de config suivant pour csup
*default host=cvsup.free.org
*default base=/var/db
*default prefix=/usr/portsdev/cvsroot
*default release=cvs
*default delete use-rel-suffix
*default compress
ports-all
Puis récupérer le cvsroot :
$ csup cvsroot-supfile
Installation des pré-requis
Installation des packages
$ make -C /usr/ports/devel/mercurial install clean
$ make -C /usr/ports/lang/ruby18 install clean
$ make -C /usr/ports/textproc/ruby-iconv install clean
$ make -C /usr/ports/devel/ruby-rbtree install clean
Installation de rcsparse
$ hg clone http://ww2.fs.ei.tum.de/~corecode/hg/rcsparse
$ cd rcsparse
$ ruby extconf.rb
$ make
$ make site-install
Récupération des sources de fromcvs
$ hg clone http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs
Conversion du CVSROOT en git
Préparation du répertoire de destination
$ mkdir /usr/portsdev/freebsd-ports.git
$ cd /usr/portsdev/freebsd-ports.git
$ git init --bare
Conversion
$ cd /usr/portsdev/fromcvs
$ ruby togit.rb /usr/portsdev/cvsroot ports /usr/portsdev/freebsd-ports.git
2h30 (oui seulement 2h30 !!! ) après c'était fait
Le répertoire de destination fait 720Mo.
Repack du rep
$ cd /usr/portsdev/freebsd-ports.git && git repack -a -f -d
Ce coup ci ça ne dure que 5 petites minutes et le répertoire ne fait plus que 410Mo
Mise à jour de l'arbre git
Comme fromcvs fonctionne de manière incrémentale, il faudra juste relancer le csup de temps en temps et relancer la commande togit.rb pour faire très rapidement les mises à jours
Bilan du round 2
fromcvs n'est pas parfait (il n'importe pas encore les tags) en revanche il a été capable de me conserver plus de branches que ce que parsecvs avait fait, en plus il est beaucoup, beaucoup, beaucoup plus rapide :
Pour les ports la conversion passe de 17h30 à 2h30 le repack passant lui de 28h50 à 5min, la taille du repos avant repack de 4go à 710Mo.
Par contre attention togit.rb est un très gros consommateur de RAM : il a bouffé mes 4Go de RAM plus 3Go de SWAP pour convertir les ports !!!
La mise à jour fonctionne parfaitement. Autant dire que je garde cette méthode. J'ai bien essayé de modifier fromcvs afin qu'il puisse importer les tags, mais je n'y suis pas arrivé, le ruby ne m'aime définitivement pas.
Du flan oui mais convi
De plus en plus dans mon boulot je dois faire du flan, du corpo flan même je dirai, le problème c'est qu'il faut pour cela utiliser OpenOffice... Et OpenOffice bah c'est très très lourd, c'est bloat, et quand je rédige, je ne vois pas pourquoi j'utiliserai autre chose que mon convi vim.
Heureusement pandoc existe, il s'agit d'un convertisseur de document qui gère entre autre en entrée le format markdown et gère entre autre en sortie le format odt.
Je tente le coup, je rédige un début de document en markdown avec mon plus beau vim et je le converti en odt.
$ pandoc -f markdown -t conviflan.txt -o corpoflan.odt
Le résultat est presque parfait, mon document OpenOffice respecte différente hiérarchie de style. Presque parfait parce qu'il faut que j'y applique le style de la boite à ce document, quand même. Pour cela rien de plus simple.
On extrait le style d'un document corpoflan déjà existant :
$ unzip corpoflan-modele.odt styles.xml
Puis on l'insère dans le document générer :
$ zip corpoflan.odt styles.xml
Et voilà un beau document rédigé en toute légèreté qui respecte la mise en forme corpo.
Voici une autre petite astuce que j'ai trouvé pour rédiger des diagrammes simplement :
J'utilise pgf/tikz parce que ça fait très simplement de très belles choses corpo ready via LateX. Je fait donc mon diagramme en LateX et le transforme en pdf avec pdflatex, enfin, pour pouvoir le réutiliser sous la forme de png dans les documents corpoflan, imagemagick est mon sauveur :
$ convert -density 200x200 -quality 90 -trim diagramme.pdf diagramme.png
Elle n'est pas belle la vie ?
UPDATE
Si dans votre modèle de document d'origine il y a des images, pour les récupérer il faudra déterminer où elle se trouve de corpoflan-modele.odt, pour xmlstarlet peut vous aider :
$ xml sel -N draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" -N xlink="http://www.w3.org/1999/xlink" -t -v "//draw:image/@xlink:href" styles.xml
Pictures/100000000000004200000032A4B86058.png
d'où
$ unzip Pictures/100000000000004200000032A4B86058.png corpoflan-modele.odt
$ zip corpoflan.odt Pictures/100000000000004200000032A4B86058.png
(Il faut noter là que xml c'est le nom du binaire de xmlstarlet sous FreeBSD sous linux c'est généralement xmlstarlet le nom du binaire.
Exemple en image :
- Rédaction dans vim :
- Aperçu avant application du style
- Aperçu après application d'un style de framasoft
Une forge sous NetBSD
Installation des packages
Installation de pkgin
D'abord on installe le package pkgin en lui même via la méthode binaire "traditionnelle" NetBSD
$ export PKG_PATH=ftp://ftp.fr.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/5.0/All
$ pkg_add -v pkgin
Il faut ensuite modifier le fichier /usr/pkg/etc/pkgin/repositories.conf pour y ajouter la ligne
ftp://ftp.fr.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/5.0/All
Puis mettre à jour la liste des packages binaire disponibles
$ pkgin update
Installation des autres composants
Les composants dont on aura besoin sont les suivant :
- git : scmgit
- postgresql : postgresql84-server
- le connecteur postgresql pour ruby : ruby18-postgres-pr
- le binding imagemagick pour ruby : ruby18-RMagick
- le serveur web ruby : thin
On installe donc tout ça
$ pkgin install scmgit postgresql84-server ruby18-postgres-pr ruby18-RMagick thin
Quelques minutes plus tard tout est arrivé et installé
Installation des gems
Il faudra ensuite installer les Ruby On Rails via les gem
$ gem install rail -v=2.2.2
Récupération de redmine
Exemple pour la version 0.8.6 ici :
$ ftp http://rubyforge.org/frs/download.php/66633/redmine-0.8.6.tar.gz
Maintenant que tout est près passons à la configuration
Configuration
Ajouts des utilisateurs
Nous allons faire tourner chaque processus avec des utilisateurs différents :
redmine:redmine pour le serveur web thin git:git pour le daemon git
$ groupadd _redmine
$ groupadd _git
$ useradd -m -g _redmine _redmine
$ useradd -m -g _git _git
Préparation du serveur postgresql
D'abord on copie le script d'init de postgresql dans /etc/rc.d/ pour qu'il puisse être activé au démarrage :
$ cp /usr/pkg/share/examples/rc.d/pgsql /etc/rc.d/pgsql
$ echo "pgsql=YES" >> /etc/rc.conf
Puis on initialise la base :
$ /etc/rc.d/pgsql initdb -E unicode
Enfin on démarre le serveur
$ /etc/rc.d/pgsql start
On crée ensuite la base qui va bien
$ createuser -I -E -P -S -R -D redmine
Renseigner le mot de passe
$ createdb -T template0 -O redmine -E UTF8
Postgresql est maintenant utilisable
Configuration de redmine
$ tar xvfz redmine-0.8.6.tar.gz
$ mv redmine-0.8.6 redmine # non obligatoire
$ cd redmine
Configuration de la base de production redmine
$ cp config/database.yml.example config/database.yml
Il faut modifier ensuite ce fichier pour correspondre à :
production:
adapter: postgresql
database: redmine
host: localhost
username: redmine
password: mon_pwd
On initialise la base redmine :
$ RAILS_ENV=production rake db:migrate
Et on insère les données par défaut :
$ RAILS_ENV=production rake redmine:load_default_data
Afin que redmine puisse fonctionner, l'utilisateur dans lequel va tourner le serveur thin doit pouvoir accéder à certains répertoires :
$ mkdir tmp public/plugin_assets
$ sudo chown -R _redmine:_redmine files log tmp public/plugin_assets
$ sudo chmod -R 755 files log tmp public/plugin_assets
Configuration du serveur thin
Notez que ici redmine est installé dans /home/_redmine
Il faut simplement créer un script rcng pour démarrer automatiquement thin : /etc/rc.d/thin
#!/bin/sh
#
# PROVIDE: thin
# REQUIRE: DAEMON
. /etc/rc.subr
name="thin"
rcvar=$name
command="/usr/pkg/bin/$name"
stop_cmd="/usr/pkg/bin/thin -c /home/_redmine/redmine -e production stop"
command_args="-c /home/_redmine/redmine -e production -d -u _redmine -g _redmine start"
load_rc_config $name
run_rc_command $1
Puis l'activer
$ chmod 755 /etc/rc.d/thin
$ echo "thin=YES" >> /etc/rc.conf
$ /etc/rc.d/thin start
Un serveur thin tourne maintenant sur le port 3000 du serveur
le daemon git
On considère ici que les dépots git se trouveront dans /home/_git/depots Tout comme pour thin il faut simplement créer un script rcng
#!/bin/sh
#
# PROVIDE: gitdaemon
# REQUIRE: DAEMON
. /etc/rc.subr
name="git-daemon"
rcvar=$name
pidfile="/var/run/$name.pid"
command="/usr/pkg/libexec/git-core/git-daemon"
command_args="--detach --base-path=/home/_git/depot --user=_git --group=_git --pid-file=$pidfile"
load_rc_config $name
run_rc_command $1
Puis l'activer
$ chmod 755 /etc/rc.d/gitdaemon
$ echo "gitdaemon=YES" >> /etc/rc.conf
$ /etc/rc.d/gitdaemon start
Déposer les dépots git dans /home/_git/depots et ils seront automatiquement disponibles, par exemple :
Pour un depot /home/_git/depots/CBlog.git :
$ git clone git://monbeauserveur/CBlog.git
Pour plus d'information ici UnixGarden est ton ami : là et là
Conclusion
La forge est maintenant opérationnelle, pour y accéder : http://monbeauserveur:3000 .
UPDATE :
rhaamo vient de rajouter le support de mercurial
Snif c'est beau le libre : Merci !!
Un petit post pour dire merci.
Merci pourquoi ?
Alors voila la petite histoire, je ne fais pas d'autohébergement à part mon blog, or il y a quelques temps j'ai voulu faire un planet BSD francophone, ne trouvant rien d'ultra simple et léger j'ai développer le mien : CPlanet, rapidement c'est posé la question de l'hébergement.
En effet je voulais un service qui tourne tout le temps or l'auto hébergement c'est dépendant du fait que je joue ou pas avec mes machines et je joue souvent donc je br0tch souvent :).
C'est là que monsieur bsdsx en plus de contribuer à CPlanet me propose une petite jail FreeBSD toute mignonne chez lui pour héberger tout ça, depuis ça donne ça.
Pour l'hébergement de mes projets en eux même, je me suis tourné vers github qui me proposait gratuitement un bug tracker, du git, et un wiki, un petite forge sympathique en somme. Mais avec le temps ça n'allait pas du tout : impossible d'envoyer des fichiers dans la section download sans une saleté d'applet en flash qui pue à mort.
C'est là que monsieur rhaamo, en plus d'utiliser CBlog me propose un petit domU qui "of course run NetBSD" pour héberger le développement, depuis ça donne ça.
Un petit redmine+lighttpd+git-daemon+postgresql le tout propulsé par du NetBSD et installé très très rapidement grâce au beau pkgin de monsieur iMil.
Bon j'ai plus le choix maintenant il faut que je fasse une release stable de CPlanet et CBlog.
Bien sûr je vais bientôt documenter l'installation de brokk (pour info brokk est un lutin^Wnain forgeron de la mythologie Nordique)
VirtualBox sur un hôte FreeBSD
Au boulot pour les mails, nous utilisons Br0tchus Notes, un espèce de daube infâme qui te pique ta ram pire qu'un firefox dans ces mauvais jours, bref.
Mon problème c'est que mon Desktop c'est du FreeBSD et que les gens de chez IBM, il ne fournissent de clients que pour Linux (si on ne considère que les environnements libre) - le java ça ne devait pas permettre de faire des applis qui tourne chez tout le monde ??? (oui il y a des vrais morceaux d'eclipse donc de java dans les derniers clients Notes)... bref -
VirtualBox ayant été porté récemment sous FreeBSD avec le support des extensions Vt-X je me suis donc lancé dans la virtualisation d'une debian minimaliste qui n'aura pour seul but que de lancer le client Notes et de le confiner en RAM afin qu'il ne me pique pas tout ce que j'ai de disponible sur ce Desktop.
Pour cela je l'ai donc installé depuis les ports (il faudra faire attention pour lancé les VMs à bien avoir mounté /proc - oui le ports n'est pas encore super propre, mais on fera avec). Comme c'est déjà super long à compiler je l'ai compilé en enlevant le support QT4, en effet la GUI n'apporte pas grand chose à cette application et en plus elle ne permet pas d'accéder à des fonctionnalités intéressantes de VBox.
Pour finir afin d'être plus souple j'ai utilisé les volumes zfs comme disques pour l'invité.
Installation de virtualbox
$ make -C /usr/ports/emulators/virtualbox config
Choisissez les options qui vous plaisent
$ make -C /usr/ports/emulators/virtualbox install clean
Si tout ce passe bien vous disposez maintenant de virtualbox sur votre machine.
Préparation du disque d'accueil de l'invité
Règle devfs
Pour que les volumes pour l'invité puisse être modifié par l'application virtualbox, ils doivent appartenir au groupe vbox, devfs nous permet de le faire à la volée, pour cela, dans le fichier /dev/devfs.rules :
[localrules=1]
add path 'zvol/vbox/*' mode 0660 group vbox
Ne pas oublier de modifier /etc/rc.conf pour qu'il le prenne en compte :
devfs_system_ruleset="localrules"
Un petit redémarrage de devfs pour finir :
$ /etc/rc.d/devfs restart
Création du volume
5G suffirons largement pour notre installation et encore je suis très large
$ zfs create -V 5G vbox/debian
Nous disposons maintenant d'un disque qu'il ne reste plus qu'à ajouter au pool de disques VirtualBox :
$ VBoxManage internalcommands createrawvmdk -filename melebian.vmdk -rawdisk /dev/zvol/vbox/debian
$ VBoxManage registerimage disk debian.vmdk
Création de la machine virtuelle
Création de la VM sans disque
Nous allons donc créer la VM pour qu'elle support les extensions VT-x et qu'elle soit limitée à 256Mo de RAM il ne s'agirait pas non plus que notes se sente trop à son aise.
$ VBoxManage createvm -name debianVM -register
$ VBoxManage modifyvm debianVM --ostype debian -memory 256M
$ VBoxManage modifyvm debianVM --vtxvpid on
Nous allons aussi déporter le port 22 de l'invité sur le port 2222 local afin de se simplifier la tâche pour le réseau (on laisse le réseau par défaut de virtualbox)
$ VBoxManage setextradata debianVM "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/GuestPort" 22
$ VBoxManage setextradata debianVM "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/HostPort" 2222
$ VBoxManage setextradata debianVM "VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/Protocol" TCP
Ajout du disque à la nouvelle VM et de l'iso de l'installeur
Tout d'abord on liste les disques disponibles dans le pool pour récupérer son identifiant :
$ VBoxManage list hdds
UUID: b6db4102-90fd-4073-ae61-c1c57556bb85
Format: VMDK
Location: /home/bapt/debian.vmdk
Accessible: yes
Il suffit maintenant de le rajouter :
$ VBoxManage modifyvm debianVM -hda b6db4102-90fd-4073-ae61-c1c57556bb85
On enregistre l'iso dans le pool VirtualBox :
$ VBoxManage registerimage dvd /home/bapt/Desktop/debian-501-i386-netinst.iso
Et on l'ajoute de la même manière à la VM
$ VBoxManage list dvds
UUID: b3329255-221a-4bb6-b1f4-be2d4bdc0f2f
Path: /home/bapt/Download/debian-501-i386-netinst.iso
Accessible: yes
$ VBoxManage modifyvm debianVM -dvd b3329255-221a-4bb6-b1f4-be2d4bdc0f2f -boot1 dvd
Installation de l'invité
Pour l'installation de l'invité, on démarrera en mode sdl pour la suite ça ne sera plus nécessaire :
$ VBoxManage startvm debianVM --type sdl
Ou
$ VBoxSDL startvm debianVM
il ne vous reste plus qu'à faire votre installation debian normale à laquelle vous ajouterez votre client br0tchus notes et le configurerez.
afin que votre VM puisse accéder au disque de l'hôte sans se prendre la tête, VirtualBox prévoie un mécanisme bien sympathique :
$ VBoxManage sharedfolder add debianVM -name share -hostpath /home/bapt/sharedvm
Pour y accéder depuis votre debian, il faudra installer les guestutils
$ apt-get install virtualbox-ose-guest-modules virtualbox-ose-guest-utils
Puis dans le /etc/fstab de l'invité
share /home/bapt/sharedHost vboxsf uid=bapt,gid=bapt 0 0
Maintenant lorsque vous démarrerez votre VM vous le ferez de la manière suivante :
$ VBoxManage startvm debianVM --type headless
Ou
$ VBoxHeadless startvm debianVM
Et pour se connecter à la VM depuis l'hôte :
$ ssh -Y -p 2222 bapt@localhost
lancez notes ou votre application désirée.
Comme je suis un gentil lutin j'ai partagé tout ça de manière plus générique sur GCU
CBlog bientôt une release donc un ports
Une nouvelle fonctionnalité vient de faire son apparition dans CBlog : la possibilité de pouvoir désactiver les commentaires via un simple "Comments: false" dans l'entête d'un message (à la demande de rhaamo - oui il y a au moins deux utilisateurs de CBlog :)).
En fait c'est encore mieux que ça, un nouveau champs Posts.nb.allow_comments est disponible dans le HDF (datafile) du coup vous pouvez faire ce que vous voulez avec dans votre template, il correspond au contenu de l'entête Comments:. Dans le template d'exemple si il est égale à false, il n'affiche pas le formulaire de commentaires.
Il me reste deux fonctionnalités à implémenter pour faire une release 1.0 :
- la gestion de page statiques.
- la gestion d'une page d'erreur pour afficher les problèmes plutot que le stderr.
Bien sûr il reste toujours du nettoyage a faire pour rendre plus propre et robuste le code, de la documentation :)
En ce qui concerne CPlanet il n'y a plus que du nettoyage car je ne vois pour le moment aucun besoin de rajouter de fonctionnalitées.
Dans tous les cas dès la release venue, un joli ports FreeBSD fera son entrée.
Toute contribution est la bienvenue, surtout que pour le moment le code n'a été testé que sous FreeBSD.
Reconstruire les paquets cassés
Voici un petit script ZSH pour rechercher les binaires systèmes qui ne trouvent pas les bibliothèques dont ils dépendent et les reconstruire en utilisant portmaster.
#!/usr/local/bin/zsh typeset -a torebuild rep=(/usr/local/bin/**/*(.)) rep+=(/usr/local/lib/**/*.so(.)) rep+=(/usr/local/sbin/**/*(.)) for bin ($rep) { file $bin | grep -q "ELF" && { ldd =$bin | grep -q "not found" && { torebuild+=$(pkg_info -qoW $bin) } } } portmaster -f ${(u)torebuild}
Convertir l'arbre CVS des ports en git
Voulant pouvoir jouer tranquillement avec les ports via git, je me suis dit que j'allais convertir les CVS des ports en git tout simplement.
Récupération du CVSROOT
Créer le fichier de config suivant pour csup
*default host=cvsup.free.org
*default base=/var/db
*default prefix=/usr/portsdev
*default release=cvs
*default delete use-rel-suffix
*default compress
ports-all
Puis récupérer le cvsroot :
$ csup cvsroot-supfile
Récupération et construction de parsecvs
Récupérer les sources
$ git clone git://anongit.freedesktop.org/~keithp/parsecvs
Contruire les lib git qui seront nécessaires, sans les installer.
$ make -C /usr/ports/devel/git
Modifier le Makefile de parsecvs pour qu'il ressemble à celui-ci
GCC_WARNINGS1=-Wall -Wpointer-arith -Wstrict-prototypes
GCC_WARNINGS2=-Wmissing-prototypes -Wmissing-declarations
GCC_WARNINGS3=-Wnested-externs -fno-strict-aliasing
GCC_WARNINGS=$(GCC_WARNINGS1) $(GCC_WARNINGS2) $(GCC_WARNINGS3)
GITPATH=/usr/ports/devel/git/work/git-1.6.4
CFLAGS=-O2 -g $(GCC_WARNINGS) -I$(GITPATH) -DSHA1_HEADER='<openssl/sha.h>' -I/usr/local/include
LIBS=-L$(GITPATH) -lgit $(GITPATH)/xdiff/lib.a -lssl -lcrypto -lz -liconv -L/usr/local/lib
YFLAGS=-d -l
LFLAGS=-l
OBJS=gram.o lex.o parsecvs.o cvsutil.o revdir.o \
revlist.o atom.o revcvs.o git.o gitutil.o rcs2git.o \
nodehash.o tags.o tree.o
parsecvs: $(OBJS)
cc $(CFLAGS) -o $@ $(OBJS) $(LIBS)
$(OBJS): cvs.h
lex.o: y.tab.h
lex.o: lex.c
y.tab.h: gram.c
clean:
rm -f $(OBJS) y.tab.h gram.c lex.c parsecvs
install:
cp parsecvs edit-change-log ${HOME}/bin
Construction et installation de parsecvs
$ gmake
$ cp parsecvs edit-change-log /usr/local/bin
Conversion du CVSROOT en git
$ cd /usr/portsdev/ports
Si vous utilisez zsh :
$ print -l **/*,v | parsecvs
Sinon
$ find . -name "*,v" -print | parsecvs
Attention c'est long, très long : 17h30 sur un Q6600 avec 4Go de RAM et un disque SATA 150 en zfs Le facteur principal est la vitesse du disque dur en effet la consommation de RAM et CPU est négligeable comparée à l'utilisation disque.
Une fois cette étape terminée vous disposez d'un répertoire git fonctionnel mais énorme : plus de 4Go
Repack du rep
$ git repack -a -f -d -l
Cette étape est très longue aussi et dépend de la vitesse de votre disque pour beaucoup. Ici ça a pris 28h50
Une fois cette étape finie vous voila avec un répertoire git de 400M ce qui est quand même beaucoup mieux.
Préparation pour les mises à jour
Alors comme cvsps foire prodigieusement souvent via git cvsimport, il faut le lancer de côté :
$ export CVS_RSH=ssh
$ export CVSROOT=anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs
$ cvsps -x --norc -u -A ports > /tmp/cvsps.out
Mise à jour de l'arbre git
$ git cvsimport -o master -P /tmp/cvsps.out ports
Vous voila avec un git à jour, pour continuer à mettre à jour, recommencer les deux dernières étapes.
En un seul coup pour zsh :
$ git cvsimport -o master -P <(cvsps -x --norc -u -A ports) ports
zcp un wrapper pour cp
L'autre jour sidh me demandait si je n'avais rien en zsh pour pouvoir suivre la progression d'un cp volumineux et je n'avais rien, mais j'ai trouvé l'idée intéressante. Un petit man cp plus tard, je me rend compte que le cp de FreeBSD il est beau et bien foutu, en lui envoyant un SIGINFO il nous dis ce qu'il fait et ou il en est. De là a wrapper tout dans un petit script zsh il n'y avait qu'un pas.
De plus zsh permet de créer un tty virtuel (zpty) dans lequel on peut exécuter des commandes et interagir, du coup, voici un petit script bien pratique :
#!/usr/local/bin/zsh setopt extendedglob zmodload zsh/zpty zpty copy "cp $@ 2>&1" ZPTYPID=${${=${(M)${(f)"$(ps -o pid,ppid,command)"}:#[[:space:]]#[[:digit:]]##[[:space:]][[:space:]]#$$*zsh*}}[1]} CPPID=${${=${(M)${(f)"$(ps -o pid,ppid,command)"}:#[[:space:]]#[[:digit:]]##[[:space:]][[:space:]]#${ZPTYPID}*cp*}}[1]} line="" while [ : ] do zpty -rt copy out if [[ $#out -gt 0 ]] then newline=${${=${out}}[0,-2]} percent=${${=${out}}[-1]} if [[ -z $line || "x$newline" != "x$line" ]] then [[ -n $line ]] && print "${line}: done" line=$newline print "${line}: ${(l: ::4:)percent}\c" else print "\r${line}: ${(l: ::4:)percent}\c" fi fi kill -SIGINFO $CPPID 2>/dev/null || break done [[ -n $line ]] && print "${line}: done" zpty -d copy
la sortie donne : # zcp toto.iso bla/ toto.iso -> bla/toto.iso: 48%
UPDATE: Apparemment ça ne fonctionne qu'avec zsh 4.3.10+
Du nouveau sous le capot
Depuis quelques temps déjà je me suis mis à essayer de faire du C pour de vrai. Pour cela il me fallait un vrai projet, alors je me suis dit tiens un planet BSD pour les BSDistes actifs francophone ça sera pas mal, du coup j'ai codé CPlanet. Ce qui m'a fait découvir une bibliothèque vraiment choupi s'il en ait pour faire du Web en C : clearsilver.
Résultat : planet.etoilebsd.net
CPlanet est donc un aggrégateur de flux rss et atom (merci libmrss) qui génère un site statique. Il utilise un fichier de conf vraiment simplissime. C'est la solution pour qui souhaite mettre en place un planet sans contrainte, puisque celui-ci n'utilise aucun langage de script, ni de base de données, juste un tout petit binaire.
Tout ça m'a bien motivé alors vlati pas que je me dis que blosxom c'est sympa, mais ça fait pas tout ce que je veux et en plus ça m'oblige à ajouter des lib perl de partout pour les plugins. Je ressors donc mon plus beau vim, mon petit clearsilver tout choupi qui ne me quitte plus et je me lance. Cerise sur le gâteau, je découvre discount, une jolie lib pour transformer du texte en html en suivant la syntaxe markdown.
Resultat : un moteur de blog en C (sous la forme d'un cgi) qui ne nécessite donc pas de langage de script, qui ne nécessite pas non plus de base de donnée toute bloatée. Il reprend le format de post de bloxsom si vous l'utilisiez avec les plugins tags et markdown.
CBlog est bien sûr libre sous license BSD.
Ce blog est donc maintenant propulsé par CBlog version de développement j'ai changé mes rewrite rules afin que le minimum de liens soit cassé.
Et non pour le mauvaise langue ce n'est pas à cause de cblog que mon site de sera pas disponible pendant 15 jours à compter de samedi, c'est pour cause de vacances et de coupure de machine.
EDIT CPlanet et CBlog sont écologiques !!! comme ils ne sont pas plein de bloat de partout, ils vous font économiser du CPU donc des Watts, alors il n'y a aucune raison de ne pas les utiliser.
PS: si vous avez des flux pour le planet à proposer je suis preneur à noter que si les gens sur le planet doivent être francophone, leurs posts n'ont pas besoin de l'être.