Mirmo Dynamics - howto

Débuter avec le Zend Framework

Geoffrey — Thu, 12 Apr 2007 00:31:00 +0200

Je suis un peu triste parce que je voulais m'atteler à cette tâche, mais bon il faut croire que j'ai trop lambiné :)

Mini Howto: Serveur et Packages PEAR

Geoffrey — Fri, 02 Mar 2007 12:11:00 +0100

Pour installer le serveur PEAR, c'est simple:

pear channel-discover pear.chiaraquartet.net
pear install chiara/Chiara_PEAR_Server
pear run-scripts Chiara_PEAR_Server

Ensuite on répond aux question, et c'est automagique.

Après, pour créer des packages, ça se corse. Tout d'abord, on a besoin de PEAR_PackageFileManager:

pear install PEAR_PackageFileManager

Ensuite, le but est de générer les package.xml qui vont bien. Voilà comment j'ai procédé pour le package Zend:

mkdir -p ~/pear/zend/src && cd ~/pear/zend
wget http://framework.zend.com/download/tgz -O - | tar xzC ~
mv ~/ZendFramework-0.8.0/library/Zend* src/
php ./mkpkg.php make
cd src && pear package

Ceux qui ont bien suivi auront noté que mkpkg.php est sorti un peu de l'espace :-) Vous trouverez son contenu à la fin du billet.

Pour résumer, on créé un répertoire de travail (~/pear/zend/), dans lequel on créé un répertoire src, qui contiendra tous les fichiers du package, puis le script mkpkg.php se charge 1) d'analyser le contenu de src, et 2) de créer le package.xml qui va bien, selon les instructions qui lui sont fournies.

Nous disposons désormais d'un package Zend-0.8.0.tgz dans ~/pear/zend/src, que nous n'avons plus qu'a uploader via l'interface d'administration du serveur PEAR précédemment installé :-)

Le fichier mkpkg.php:

<?php

require_once('PEAR/PackageFileManager2.php');

PEAR::setErrorHandling(PEAR_ERROR_DIE);

$packagexml = new PEAR_PackageFileManager2;

$e = $packagexml->setOptions(array(
    'baseinstalldir' => '/',
    'packagedirectory' => dirname(__FILE__).'/src',
));

$packagexml->setPackage('Zend');
$packagexml->setSummary('Zend Framework');
$packagexml->setDescription('The Zend\'s PHP Framework');
$packagexml->setChannel('pear.phpmafia.net');
$packagexml->setAPIVersion('0.8.0');
$packagexml->setReleaseVersion('0.8.0');
$packagexml->setReleaseStability('devel');
$packagexml->setAPIStability('devel');
$packagexml->setNotes("Still a preview release");
$packagexml->setPackageType('php'); // this is a PEAR-style php script package
$packagexml->addRelease(); // set up a release section
$packagexml->setPhpDep('5.1.2');
$packagexml->setPearinstallerDep('1.4.0a12');
$packagexml->addMaintainer('lead', 'ash', 'Geoffrey Bachelet', 'geoffrey+pear@zubrowka.org');
$packagexml->setLicense('New BSD License', 'http://framework.zend.com/license/new-bsd');
$packagexml->generateContents(); // create the <contents> tag

$pkg = &$packagexml->exportCompatiblePackageFile1(); // get a PEAR_PackageFile object

if (isset($_GET['make']) || (isset($_SERVER['argv']) && @$_SERVER['argv'][1] == 'make')) {
    $pkg->writePackageFile();
    $packagexml->writePackageFile();
} else {
    $pkg->debugPackageFile();
    $packagexml->debugPackageFile();
}

?>

Remplacer un caractère par un "Carriage Return" dans vim

Geoffrey — Wed, 03 Jan 2007 11:04:00 +0100

Par exemple, imaginons qu'on récupère une query string, et qu'on veuille l'exploser sur plusieurs lignes, on peut faire:

:s/&/\="\<CR>"/g

le \="" annonce à VIM que la chaine de substitution sera une chaine a interpréter avant utilisation, et le \<CR> représente tout simplement le Carriage Return.

Annuler un changeset SVN

Geoffrey — Sun, 17 Dec 2006 16:43:00 +0100

Méthode bourrin, je ne sais pas si il en existe une meilleure. Disons qu'on veut annuler la révision 329 (et que c'est la dernière en date):

$ svn update
$ svn merge -r 329:328 .
$ svn commit -m "cancel 329"

En tout cas chez moi ça a marché.

ViewHelper de génération d'urls

Geoffrey — Fri, 24 Nov 2006 20:27:00 +0100

Pré-requis: Zend_Controller_RewriteRouter.

Nous allons voir aujourd'hui comment générer automagiquement des URLs à partir des routes définies dans le RewriteRouter, ainsi que les avantages que cela présente. Le Helper que nous allons utiliser nécessite le stockage du routeur dans le registre:

Zend::register('router', $router);

Avant de voir le Helper lui même, un petit Use Case. Admettons que vous développiez une application de gestion de petites annonces, vous aurez à un moment ou un autre à créer un lien quelconque pour, par exemple, créer une annonce, et en voir les détails. Disons que vous ayez des routes route du genre (je zappe les defaults):

announceCreate.route = /announce/create
announceDetails.route = /announce/:id/details

L'objectif est de pouvoir créer les liens grâce au code suivant (à partir de la view):

<a href="<?php echo $this->href('announceCreate'); ?>">Créer une annonce</a>
<a href="<?php echo $this->href('announceDetails', array('id' => $announce->id)); ?>">Voir l'annonce</a>

Et comme le Zend Framework est bien fait, c'est très simple à réaliser sous forme de ViewHelper:

class Zend_View_Helper_Href {
	
	/**
	 * Returns the href to a given route
	 *
	 * @param string $routeName
	 * @param array $args
	 * @return string
	 */
	
	public function href($routeName, $args = array()) {
		try {
			return Zend::registry('router')->getRoute($routeName)->assemble($args);
		} catch (Zend_Controller_Router_Exception $e) {
			return '#404';
		}
	}
}

Tellement simple que pour combler un peu je vous offre le docblock qui va avec ;-)

Là où ça devient très pratique, c'est quand on souhaite localiser les URLs. Par exemple, imaginons que vous souhaitiez françiser les URLs pour, par exemple, améliorer votre référencement. Vous n'avez qu'a définir un jeu de routes fr_FR, par exemple ainsi:

announceCreate.route = /annonce/creer

announceDetails.route = /annonce/:id/details



[routes_en_UK]

announceCreate.route = /announce/create

announceDetails.route = /announce/:id/details



[routes:route_fr_FR]

announceCreate.defaults.controller = announce

announceCreate.defaults.action = create



announceDetails.defaults.controller = announce

announceDetails.defaults.action = details

L'utilisation de l'héritage géré par Zend_Config nous permet ici d'éviter la redondance des defaults.

Elle est pas belle la vie ?

Note: cette fonctionnalitée est prévue pour être builtin plus tard.

Zend Framework: Un plugin simple pour le Front Controller

Geoffrey — Sun, 19 Nov 2006 21:30:00 +0100

L'implémentation du Front Controller du Zend Framework inclue un système bien pratique de plugins, qui va nous permettre de réaliser plus simplement et proprement l'automatisation des vues, initialement embarquée dans une extension de Zend_Controller_Action (ce qui pose quelques problèmes, nottament au lors de l'utilisation de __forward() et _redirect()).

Techniquement, un plugin est une classe qui implémente l'interface des plugins (Zend_Controller_Plugin_Interface). Dans la pratique, une classe abstraite est fournie pour simplifier la tache (Zend_Controller_Plugin_Abstract). Notre premier plugin s'appellera AutoView (My_Controller_Plugin_AutoView, stocké dans My/Controller/Plugin/AutoView.php).

Un plugin est donc une classe dont les méthodes seront appelées a différents moments de la dispatch loop du controlleur frontal, comme on peut le voir dans Zend_Controller_Front::dispatch():

routeStartup(), à la mise en route du routeur
routeShutdown($action), à l'arrêt du routeur
dispatchLoopStartup($action), avant la dispatch loop
preDispatch($action), avant d'executer une action
postDispatch($action), après avoir executé une action
dispatchLoopShutdown(), pour finir.

A chaud, on pourrait se dire que postDispatch est exactement ce dont on n'a besoin, et on se tromperait. Ce qu'il faut savoir, c'est que l'argument $action passé à postDispatch contient l'action qui suit celle qui vient d'être executé. Dans la majorité des cas, n'ayant qu'une seule action à executer, $action sera vide, et on se retrouve l'air un peu con.

Bon donc, on va user d'un stratagème: notre plugin va stocker les actions qui passent dans preDispatch, pour s'occuper de la dernière à être passée dans dispatchLoopShutdown. Dernier détail, notre plugin s'occupera lui même de gérer son instance de Zend_View. Et sans plus attendre, le code, qui n'a finalement rien de compliqué:

<?php

require_once 'Zend/Controller/Plugin/Abstract.php';

class My_Controller_Plugin_AutoView extends Zend_Controller_Plugin_Abstract {

	private $_lastAction;

	public function __construct() {
		$view = new Zend_View;
		$view->setScriptPath(APP_ROOT.'/views/');
		Zend::register('view', $view);
	}

	public function preDispatch($action) {
		$this->_lastAction = clone($action);
		return $action;
	}

	public function dispatchLoopShutdown() {
		if (!is_null($this->_lastAction)) {
			$viewPath = sprintf('%s/%s.php', $this->_lastAction->getControllerName(), $this->_lastAction->getActionName());
			echo Zend::registry('view')->render($viewPath);
		}
	}
}

?>

Bien, notre plugin vaillament codé, il nous faut désormais expliquer au controlleur frontal qu'on aimerai bien qu'il en tienne compte. Cela se passe fort logiquement dans le bootstrap, via la méthode registerPlugin du sus-cité controlleur frontal, qui prend en argument une instance d'un objet implémentant Zend_Controller_Plugin_Interface:

$controller = Zend_Controller_Front::getInstance();
$controller->registerPlugin(new My_Controller_Plugin_AutoView);

And viola !

Migrer un dépot subversion

Geoffrey — Thu, 09 Nov 2006 17:25:00 +0100

Imaginons que vous souhaitiez déplacer votre dépôt subversion myproject d'une machine old-server à une machine new-server. Vite fait, bien fait:

old-server# svnadmin dump /var/lib/subversion/myproject > ~/myproject.svndump
old-server# scp ~/myproject.svndump new-server:
new-server# svnadmin create /var/lib/subversion/myproject
new-server# svnadmin load /var/lib/subversion/myproject < ~/myproject.svndump

Attention, il vous faut par contre migrer vos éventuelles hooks à la main, ils ne sont effectivement pas gérés par svndump. Une autre méthode, incluant les hooks celle-ci, serait d'utiliser svnadmin hotcopy, mais je n'ai pas testé.

Plus d'infos:

Howto: Utiliser Zend_Controller_RewriteRouter avec Zend_Config

Geoffrey — Tue, 31 Oct 2006 20:26:00 +0100

Comme je le disais plus bas, le Zend Framework Preview 0.2.0 est dans les bacs ! Cette nouvelle mouture apporte son lot de nouveautés, et nous allons nous pencher sur une des plus interressantes: le RewriteRouter. Le RewriteRouter est un routeur pour le composant MVC du Zend Framework qui va nous permettre de configurer nos URL comme dans Ruby on Rails, c'est à dire (en gros), via un fichier de configuration, et c'est là que Zend_Config entre en jeu.

Mettre en place le routeur

C'est bien beau tout ça, mais pour l'utiliser, il faut déjà en informer le controlleur. Pour cela, rien de plus simple, on utilise la méthode addRouter:

$router = new Zend_Controller_RewriteRouter;
$controller = Zend_Controller_Front::getInstance();
$controller->setRouter($router);

Le RewriteRouter est pré-configuré avec deux routes qui permettent d'assurer la compatibilité descendante avec l'ancien routeur, donc jusque là, tout va bien.

Déclarer les routes

Nous utiliserons un fichier de configuration dédié aux routes, que nous appellerons sobrement routes.ini, et que nous placerons dans app/, à coté de son compagnon config.ini. Ce fichier de configuration contiendra une unique section [routes], qui contiendra à son tour les multiples définitions de routes que nous souhaitons y caser. Une route se compose de 5 éléments principaux:

L'identifiant de la route. C'est un identifiant interne utilisé par le RewriteRouter,
l'URL de la route, c'est ce qui permet au routeur de reconnaitre la route à utiliser,
les valeurs par défauts des variables,
les requirements de la route, qui permettent de déterminer si une route est bien formée ou non.

Sans plus attendre, un petit exemple: la route qui pourrait permettre d'accéder à un billet dans dotclear 2:

post.route = post/:year/:month/:day/:title
post.reqs.year = "\d+"
post.reqs.month = "\d+"
post.reqs.day = "\d+"
post.reqs.title = "[a-zA-Z0-9_:-]"+
post.defaults.controller = post
post.defaults.action = view
post.defaults.title =

Elle pourrait seulement, car en fait, la regexp du title est trop restrictive (une URL peut contenir d'autres caractères que ceux là), et de plus, les URL stockées par dotclear 2 en base de données comprennent tout ce qui se trouve après post/ (par exemple le champs post_url de ce billet contient: 2006/10/31/Howto:-Utiliser-Zend_Controller_RewriteRouter-avec-Zend_Config).

Cela étant dit, la route que nous venons de décrire s'appliquera aux URLs suivantes:

/post/2006/30/10/ZendFramework
/post/42/2006/56/Foobar
/post/2006/30/10/
etc.

Mais pas à:

/post/2006/Foobar
/post/Foobar/2006/30/01
etc.

On note donc d'ores et déjà:

que la validation des composants d'une route se fait par expression régulière
qu'on peut ommettre le dernier composant d'une route si il possède une valeur par défaut (récursivement)
qu'on ne peut pas modifier l'ordre des composants d'une route
qu'on doit spécifier manuellement le nom du controlleur et de l'action à utiliser
et c'est déjà pas mal.

Décortiquons maintenant une URL: /post/2006/30/10/ZendFramework. Le routeur va diviser cette URL ainsi:

Controller: post (d'après les defaults)
Action: view (d'après les defaults)
Paramètres: year: 2006, month: 30, day: 10, title: ZendFramework (d'après l'URL)

Les paramètres ainsi détectés seront disponibles via la méthode $this->_getParam($name); a l'intérieur du controlleur.

Dernier point de ce chapitre, une déclaration de route peut comporter deux variables spéciales: :controller et :action, qui servent respectivement à détecter le controller et l'action à utiliser dans l'url. Par exemple, la route builtin compat chargé d'assurer la compatibilité descendante se déclare ainsi:

compat.route = :controller/:action
compat.defaults.controller = index
compat.defaults.action = index

Assembler le tout

Dernière étape, transférer directement toutes ces déclarations dans le Routeur: n'y allons pas par quatre chemin:

$router->addConfig(new Zend_Config_Ini('/path/to/routes.ini', null), 'routes');

C'est aussi simple que ça. Ce qui nous donne, en prenant en compte le morceau de code du début de l'article:

$router = new Zend_Controller_RewriteRouter;
$router->addConfig(new Zend_Config_Ini($routes_path, null), 'routes');
$controller = Zend_Controller_Front::getInstance();
$controller->setRouter($router);

And voilà. Je ne saurais que vous conseiller la lecture du manuel pour plus d'informations (sachant qu'en fait, addRoute attend en deuxième argument une instance de Zend_Controller_Router_Route, mais qui s'instancie avec les paramètres qu'ils passent à addRoute, petite coquille du manuel :p).

Mettre en place un SSO avec Invision Power Board

Geoffrey — Wed, 25 Oct 2006 23:02:00 +0200

Rien de plus simple, tout est déjà prévu. Après l'installation de votre forum IPB, nous allons enregistrer une nouvelle méthode de login. Pour se faire, dans le panneau d'administration, nous nous dirigeons vers Tools and Settings, puis dans Create New Log In du menu Log In Manager. On se retrouve devant un formulaire (assez explicite) que je vous laisse le soin de remplir. On dira juste que nous appellerons cette méthode de login Mon SSO (Log In Title) et qu'il vivra dans le répertoire mon_sso (Log In Files Folder Name). Pour que votre méthode de login soit active, vous devez cocher Log In Enabled, et il est toujours bon de passer en mode On-Fail, ainsi que d'autoriser la création d'utilisateurs (Log In Allow Member Creation), qui créera automagiquement les utilisateurs dans la base locale d'IPB.

Ensuite on met les mains dans le camboui. Dans le répertoire sources/loginauth/ de votre installation, il doit exister un repertoire external/, qui nous servira de base. On commence donc par le dupliquer:

cp -r external mon_sso

Puis on regarde un peu ce qu'il y a dedans:

mon_sso/
	auth.php
	conf.php
	index.html

Le fichier index.html n'est qu'un empécheur de tourner en rond pour les gens qui explorent un peu trop les arbos web. Le premier fichier qui nous interresse est conf.php, il contient les informations relatives à la base de données distantes. Là encore, c'est assez explicite et bien commenté. Le seul petit truc à savoir est que l'utilisateur qui se connectera à la base a besoin des droits SELECT sur toute la table, pas seulement sur les champs login / pass.

Dans le meilleur des cas, votre SSO est prêt :p Le fichier auth.php contient les méthodes appelées par le gestionnaire d'identification. Vous pouvez avoir besoin de modifier __compare_password, pour la vérification du mot de passe (j'ai par exemple changé la méthode de cryptage qui est md5 par défaut).

A ce stade, vos utilisateurs peuvent s'identifier, mais le forum leur demande quand même leur mail et quelques infos que j'ai oublié. Il est bien évidemment possible d'éviter ça :-) Dans la méthode authenticate, vers la fin, quand un utilisateur local est créé, la main est passée à la méthode create_local_member, qui redirige ensuite vers l'écran de complétion du compte. C'est là que nous intervenons. La méthode create_local_member n'est pas implémenté dans login_method, mais dans login_core, qui se trouve dans le fichier sources/loginauth/login_core.php, nous commençons par la copier/coller dans notre login_method, puis nous modifions sa déclaration pour lui permettre de recevoir $remote_member en paramètre:

function create_local_member( $remote_member )
{

Cette méthode permet de piocher dans les informations récupérées dans la base distante. Dans la partie Populate member table(s), par défaut, un faux mail est créé:

$email_tmp = $username.'@'.$timenow;

Qu'on peut remplacer par le mail qu'on a déjà potentiellement dans la base distante (disons que le champs s'appelle mail):

$email_tmp = $remote_member['mail'];

On peut ensuite récupérer les champs que l'on veut pour les ajouter au membre local, par exemple dans mon cas, le display_name (nickname chez moi):

$display_name = $remote_member['nickname'];

en les rajoutant dans le tableau $member.

Les deux derniers appels de méthode dans create_local_member, $this->ipsclass->DB->do_insert et $this->ipsclass->print->redirect_screen sont à commenter, et on rajouter avant le bout de code suivant:

$this->return_code = 'SUCCESS';
return;

Retour dans authenticate, dans la partie Got no member - but auth passed - create?, on modifie la première partie du if ainsi:

if ( $this->allow_create )
{
	$this->create_local_member( $remote_member );
	$this->_load_member($username);

	if ( $this->member['id'] )
	{
		$this->return_code = 'SUCCESS';
	}
	else
	{
		$this->return_code = 'NO_USER';
	}
	return;
}

And voilà, nos utilisateurs peuvent désormais s'identifier sans avoir a re-entrer des informations que l'on possède déjà :-)

Relayer un stream audio avec icecast2

Geoffrey — Fri, 20 Oct 2006 22:05:00 +0200

Pour économiser la bande passante au boulot, j'ai décidé de relayer le stream Club ! de 1.fm sur le LAN. Après avoir vainement tenté d'utiliser streamripper (on verra plus tard pourquoi vainement), j'ai sorti l'artillerie lourde: icecast2:

sudo apt-get install icecast2

Si on sait un peu lire, le script de post-configuration nous incite à aller fourrer notre nez dans /etc/default/icecast2, où l'on apprend (vers la fin) que icecast est désactivé par défaut à cause de la directive ENABLED=false. C'est en fait une feinte pour nous pousser à configurer le bousin (de toute façon si on le configure pas, il marchera pas). Direction /etc/icecast2/icecast.xml donc, pour un brin de configuration (les explications qui suivent se basent sur le fichier par défaut d'une installation sur une ubuntu).

La première partie qui nous interresse s'intitule authentication (vers la ligne 23). Elle contient les informations d'authentification pour les clients qui se connectent en tant que source (source-password), les serveurs qui se connectent en tant que slave (relay-password, en fait je ne suis pas sur à 100%, c'est une déduction) et pour l'interface d'administration (admin-user et admin-password). Une fois ces informations modifiées, direction la directive hostname, qu'on remplira avec au choix, le nom de la machine, son ip, etc. J'ai personellement mis l'ip privée de ma machine (172.16.x.y), pour que ça correspondent à la prochaine directive qui nous interresse: listen-socket. Ici on définit le port et l'ip sur laquelle icecast va écouter. En gros, si vous spécifier 127.0.0.1, votre serveur de streaming ne sera accessible qu'en local. On y met donc en général la même chose que dans hostname (172.16.x.y par exemple), avec un port qui va bien, libre de préférence (8000 par défaut).

Maintenant on passe a la partie qui nous interresse vraiment, la section relay. Rien de bien compliqué ici. Le stream que je souhaite relayer se trouve là: http://64.62.253.223:8060/, or icecast nous demande un server, un port, un point de montage (mount) et un point de montage local (local-mount). Vous avez déjà compris qu'on arrive a cette configuration:

   <relay>
       <server>64.62.253.223</server>
       <port>8060</port>
       <mount>/</mount>
       <local-mount>/1.fm</local-mount>
       <on-demand>0</on-demand>
       <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
   </relay>

Ainsi parés, il ne nous reste plus qu'a lancer modifier la directive ENABLED=false en ENABLED=true dans /etc/default/icecast2 et à lancer icecast:

sudo /etc/init.d/icecast2 start

Si vous avez bien tout fait, vous devriez pouvoir streamer depuis http://172.16.x.y:8000/1.fm, et vos collègues également ! Vous pouvez avoir une vue d'ensemble du serveur ainsi que quelques options d'administration en vous rendant sur l'interface d'admin: http://172.16.x.y:8000/ et en utilisant admin-user et admin-password pour vous authentifier.

A cela on peut ajouter un petit streamripper:

streamripper http://172.16.x.y:8000/1.fm -d ~/streamripped

Pour enregistrer. En parlant de streamripper, j'avais tenté au début de relayer avec streamripper -r, mais malgrès les apparences du netstat -pl (*:8000 LISTEN), il ne bind qu'en local, donc impossible d'en faire profiter les collègues :-)

Vous prendrez bien un peu de ssh avec votre tunnel ?

Geoffrey — Fri, 20 Oct 2006 20:06:00 +0200

Il arrive des fois où on aimerait pouvoir relier directment deux machines appartenant a deux réseaux distincts. C'est par exemple mon cas quand j'ai besoin (envie on va dire) d'accéder à ma machine du boulot depuis une machine non connectée au VPN. Dans ce genre de cas, il existe en général une machine qui possède des interfaces susceptibles d'accéder à chacune des machines (le concentrateur VPN par exemple). Nous appellerons cette machine relay, car elle servira de relai au tunnel. Pour éviter les sempiternelles appellations A et B qui embrouillent plus qu'autre chose, les machines s'appelleront startpoint pour la machine sur laquelle on a la main et endpoint pour la machine à laquelle on souhaite accéder.

Postulats de base:

relay possède un serveur SSH qui tourne
startpoint possède un client SSH capable de créer un tunnel (ssh, par exemple)
relay est accessible depuis startpoint et peut se connecter à endpoint

Bien, allons y franchement, la commande, à executer depuis startpoint, permettant de créer un tunnel SSH entre startpoint et endpoint est la suivante:

ssh -L 2222:endpoint:22 relay

Qu'avons nous fait là ? L'option -L de SSH sert à binder un port de la machine locale (startpoint donc), à un autre port (ou le même) de la machine distante (endpoint). Ici, on associe le port local 2222 (22 étant déjà pris par mon serveur SSH, mais on pourrait utiliser le port 22 si aucun serveur ne tournait, à la différence près qu'il faudrait lancer la commande en root pour pouvoir binder un port inférieur à 1024 (c'est comme ça)) au port 22 de endpoint, c'est à dire le serveur SSH. Il nous est dès lors possible d'ouvrir une connection SSH sur endpoint en se connectant au port 2222 de notre machine locale:

ssh -p 2222 localhost

Magique non ? Bien sur, il est possible de forwarder n'importe quel port au travers du tunnel:

ssh -L 8080:endpoint:80 relay

Faire pointer votre navigateur sur http://localhost:8080/ vous ammenera sur le serveur web de endpoint.

Mais un tunnel ne se limite pas à joindre deux machines d'un réseau différents. On peut également imaginer un tunnel entre deux machines dans l'unique but de sécuriser une transmission, par exemple, des échanges de mails. Imaginons que votre serveur mail preferré, pop.example.com, ne propose pas de connection POP sécurisée. Vous pouvez remédier à ce manque flagrant de confidentialité en créant un tunnel SSH:

ssh -L 1100:localhost:110 pop.example.com

Bien sur, ce cas de figure nécessite d'avoir un compte permettant une connexion SSH sur pop.example.com, ce qui n'est pas forcément le cas. Pour remédier a ceci, deux solutions: utiliser un relay qui possède un serveur SSH, ou installer un serveur SSH sur startpoint pour s'en servir comme relai (sudo apt-get install openssh-server sur toute distribution debian-like qui se respecte):

ssh -L 1100:pop.example.com:110 localhost

And voila, il n'y a plus qu'a indiquer à notre client mail que le pop se situe sur localhost au port 1100, et le tour est joué :-)

Bootstrap CLI

Geoffrey — Fri, 13 Oct 2006 18:31:00 +0200

Nous avons parcouru dernièrement la création du bootstrap HTTP qui sert de socle à une application utilisant le Zend Framework. Le même principe peut s'appliquer aux scripts CLI, mais comme les besoins sont fondamentalements différents, l'implémentation sera elle aussi complètement différente. Nous viserons les objectifs suivants:

Ne pas être obligé d'executer le bootstrap en ligne de commande
Simplifier au maximum l'écriture ultérieure des scripts CLI
Définir un jeu d'options de ligne de commande obligatoire
Mettre en place un environnement d'execution

La tentation serait de créer un système qui obligerait ce genre de commandes:

$ php batch/bootstrap.php monscript

Pour executer, par exemple, le script batch/monscript.php. Cela simplifierait grandement les choses, mais c'est moche, et puis on peut faire autrement, donc on ne va pas se priver ! Nous utiliserons a cette fin la fonction magique register_shutdown_function, qui s'occupera d'appeler une fonction qui executera les scripts ad hoc.

Avant d'aller plus loin, l'arborescence de fichiers que nous allons utiliser:

batch/
	monscript.php
	runtime.php
library/
	Zend.php
	My/
		Batch.php

runtime.php sera le fichier à inclure dans chaque script, tandis que My/Batch.php contiendra la classe d'abstraction My_Batch, qui définira les comportements par défaut de nos scripts.

Voici donc la première partie de notre bootstrap, batch/runtime.php:

ini_set('include_path', get_include_path().PATH_SEPARATOR.realpath(dirname(__FILE__).'/../library/'));

require_once 'Zend.php';
require_once 'My/Batch.php';

register_shutdown_function(array('My_Batch', 'runAll'));

Bien sur, cette méthode nous oblige à définir un format à respecter pour les fonctions à executer par la suite, nous partirons donc sur les bases suivantes:

Chaque batch doit être constitué d'une classe dont le nom commence par My_Batch_
Chaque batch doit posséder une méthode executable run

Ce qui nous donne donc:

abstract class My_Batch {
	static public function runAll() {
		$classes = get_declared_classes();
		foreach($classes as $className) {
			if (preg_match('/^My_Batch_(.+)$/', $className, $matches) && method_exists($className, 'run')) {
				try {
					$batch = new $className;
					$batch->run();
				} catch (Exception $e) {
					die(sprintf("%s: %s\n", $matches[1], $e->getMessage()));
				}
			}
		}
	}
	
	abstract public function run();
}

On en profite pour catcher toute Exception indésirable pour la transformer en un die, bien plus lisible dans un terminal qu'une backtrace :-)

Maintenant que nous avons résolu les points 1 et 2, attaquons nous à la suite. Le problème principal que j'ai rencontré lors de l'établissement d'un environnement d'execution, c'est que la gestion de la configuration repose en grande partie sur la valeur de $_SERVER['HTTP_HOST'], qui n'est bien évidemment pas disponible en CLI :-) Il me faut donc forcer le passage en argument du nom de la configuration à utiliser. C'est très simple à faire, grace a la méthode que nous avons employé: il suffit de vérifier la présence de cet argument dans le constructeur de My_Batch :-)

public function __construct() {
	foreach($GLOBALS['argv'] as $i => $arg) {
		switch ($arg) {
			case '--configname':
			case '-c':
				$this->_args['configname'] = $GLOBALS['argv'][$i+1];
			break;
		}
	}
	if (!isset($this->_args['configname'])) {
		throw new Exception('-c or --configname is mandatory');
	}
}

Voilà, le gros du travail est fait. Pour le reste, c'est la routine, mise en place d'un environnement avec Zend_Config et Zend_Db, a la suite dans le constructeur:

	$this->_config = new Zend_Config(
		Zend_Config_Ini::load(
			dirname(__FILE__).'/../../app/config.ini',
			$this->_args['configname']
		)
	);
	
	$this->_db = Zend_Db::factory(
		$this->_config->db->adapter,
		$this->_config->db->config->asArray()
	);
	
	Zend_Db_Table::setDefaultAdapter($this->_db);

Enfin, voila un exemple de script utilisant ce bootstrap:

require_once 'path/to/runtime.php';

class My_Batch_MonScript extends My_Batch {
	public function run() {
		// le code ici
	}
}

And voila !

L'environnement d'execution

Geoffrey — Thu, 12 Oct 2006 21:51:00 +0200

Voilà un article que j'avais déjà proposé sur un site a caractère privé, un peu remis au gout du jour et étoffé de quelques informations et ressources non négligeables. Nous verrons ici comment mettre en place un environement d'execution standard du Zend Framework, également appelé bootstrap de l'autre coté de l'atlantique.

Un petit dessin valant mieux qu'un long discours, entrons dans le vif du sujet. On assume ici un environnement préinstallé: Apache / PHP5 / MySQL, avec une copie du Zend Framework dans /usr/share/zend/, ainsi que le .htaccess suivant à la racine de votre site (il semblerait que cette dépendance à mod_rewrite soit sur la liste des choses à éliminer avant la release):

RewriteEnfine On
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

On peut également utiliser les règles suivantes, qui comportent l'avantage d'une plus grande simplicité pour intégrer des éléments d'application externe:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php

L'environnement

Les plus perspicaces d'entre vous l'auront surement déjà deviné, le fichier www/index.php servira de bootstrap, c'est à dire de point d'entrée unique pour toute l'application. Le Zend Framework se chargera lui même de décortiquer l'URL pour tenter de deviner ce à quoi l'utilisateur pouvait bien penser quand il a cliqué !

Pour ce qui est de l'arborescence de fichiers conseillée, un peu d'organisation est recommandée.

Pour utiliser le Zend Framework en toute quiétude, il nous faut nous assurer qu'il pourra accéder à ses propres composants. La première chose à faire est donc de modifier l'include_path:

set_include_path(get_include_path().PATH_SEPARATOR.realpath(dirname(__FILE__).'/../library/'));

Il n'est pas inutile également de prendre quelques précautions d'usage:

ini_set('error_reporting', E_ALL); # | E_STRICT);

if (get_magic_quotes_gpc()) {
	die('<strong>E_NOOB_ERROR</strong>: magic_quotes_gpc must be turned off.');
}

set_magic_quotes_runtime(false);

Last but not least, on charge la librairie Zend:

require_once 'Zend.php';

Ainsi préparés, nous pouvons nous plonger en toute quiétude dans la mise en place de quelques objets qui nous serons bien utiles tout au long du développement de notre application.

Les objets

La mise en place des objets est on ne peut plus claire. On configure le front controller (Zend_Controller_Front) pour lui dire où trouver les controllers, puis on configure les vues (Zend_View) pour leur dire où trouver... les vues :-) On enregistre ensuite l'objet $view dans le registre, qui n'est rien de plus qu'un endroit pratique où stocker des objets/données pour y avoir accès plus tard (Zend::register($name, $value) et $var = Zend::registry($name);).

Une petite liste (non exhaustive) d'objets interressants à stocker dans le registre:

Zend_Db

Zend::loadClass('Zend_Db');
Zend::loadClass('Zend_Db_Table');

$params = array(
	'host' => 'localhost',
	'username' => 'someobscureusername',
	'password' => 'someobscurepassword',
	'dbname' => 'yourdbname'
);

$db = Zend_Db::factory('PDO_MYSQL',$params);
Zend_Db_Table::setDefaultAdapter($db);

Zend::register('db', $db);

Zend_Config

Je vous renvois à mon article sur la gestion de la configuration :-)

Zend_View

Zend::loadClass('Zend_View');

$view = new Zend_View;
$view->setScriptPath(realpath(dirname(__FILE__).'/../app/views/'));

Zend::register('view', $view);

Le Dispatch

Dernière étape, le dispatch, qui utilise les objets Zend_Controller_Router et Zend_Controller_Dispatcher. Ces deux objets sont au coeur du processus de sélection du controller à executer. Le Router va déterminer, à partir de l'environnement (en général l'URL, via $_SERVER['REQUEST_URI'] par exemple) quelle action executer et dans quel controller, tandis que le Dispatcher va s'occuper lui de les trouver (par exemple dire FooController::bar(), dans controllers/FooController.php).

Le Zend Framework gère en natif les friendly urls, et ça c'est chouette. Par exemple: les urls suivantes:

http://example.com/foo/bar
http://example.com/foo
http://example.com/

Seront analysées comme suit par le Routeur par défaut:

controller: foo, action: bar
controller: foo, action: index
controller: index, action: index

Dernières choses à savoir sur la théorie:

quand le controlleur est défini par l'url mais non trouvé par le Dispatcher, celui ci execute index/noRoute.
les controllers sont des classes qui étendent Zend_Controller_Action (ou une classe qui elle même l'étend)
le Dispatcher par défaut va executer(en supposant une url type http://example.org/foo/bar) FooController::barAction dans FooController.php (modulo le path déterminé avec Zend_Controller_Front::setControllerPath)

Les vues

Dernier point de cette brève excursion dans le Zend Framework, les vues. Pas grand chose à en dire pour le moment, si ce n'est que par défaut l'objet Zend_View se contente d'include() les fichiers templates. Il parait que l'intégration avec des moteurs de template (Smarty par exemple) est très aisée, mais comme je ne suis pas fan de ce genre de choses, ce ne sera pas couvert ici :-)

Ma première impression sur XGL

Geoffrey — Tue, 03 Oct 2006 17:08:00 +0200

Bon voilà, je viens de suivre ce howto, et ça marche très bien. Passé le stade mais où sont mes efferalgans ?, on arrive rapidement au stade mais où mon smecta ?, tellement c'est gerbant de fluidité. Bref, le desktop mappé sur un cube, c'est sympa, mais on lui preferrera de loin les effets moins psychédéliques tels que la vraie transparence et les animations des fenetres (et encore).

Empecher la sauvegarde d'un mot de passe

Geoffrey — Sun, 24 Sep 2006 22:22:00 +0200

Le titre n'est pas très explicite, malheureusement, j'ai du mal a réfléchir ce soir. Nous parlons ici de la sauvegarde d'un mot de passe par Firefox quand on valide un formulaire contenant un champs password. Je ne connais pas exactement les règles qui régissent ce comportement, mais quand on à un formulaire d'enregistrement, en général, cette fonctionnalitée est plus une gène qu'autre chose. Pour la désactiver, il suffit donc d'affecter un attribut autocomplete de valeur off à votre champs:

<input type="password" name="password" id="password" autocomplete="off" />

Je sais, ça fait beaucoup de password.

Automatisation des vues

Geoffrey — Wed, 30 Aug 2006 13:17:00 +0200

Le rebutement principal que j'ai eu au début avec le Zend Framework était l'impossibilité (a priori) d'automatiser le rendu des vues en fonction du controlleur et de l'action appelés. Mes pérénigrations webesques m'ont finalement fait entrevoir la solution.

EDIT: mes nouvelles pérégrinations dans les sources du Zend Framework m'ont fait entrevoir une meilleure solution :-)

Tout se passe dans le destructeur du controlleur, et nous allons voir ici une version édulcorée de celle disponible dans le lien sus-cité. L'astuce qui sauve, c'est de savoir que l'objet Controller possède un membre _action, qui lui même propose (entre autres) deux méthodes bien utiles: getControllerName et getActionName. Il suffit donc de récupérer ces informations pour construire dynamiquement le chemin de la vue à utiliser pour un controlleur donné:

abstract class My_Controller_Action extends Zend_Controller_Action {
	public function __destruct() {
		$view = Zend::registry('view');
		$controller = $this->_action->getControllerName();
		$action = $this->_action->getActionName();
		$viewPath = sprintf('%s/%s.php', $controller, $action);
		try {
			echo $view->render($viewPath);
		} catch (Exception $e) {
			trigger_error('Unable to render view: ' . $e->getMessage(), E_USER_ERROR);
		}
	}
}

Fichier source

Ce controlleur requiert que vous ayez instancié, configuré et enregistré Zend_View au préalable. Il ira, lors de sa destruction, chercher la vue dont le nom correspond à controller/action.php, c'est à dire:

pour une URL du type http://example.com/foo/bar/, foo/bar.php,
pour http://example.com/, index/index.php,
pour http://example.com/foo/, foo/index.php.

Pour une raison obscure, on ne peut pas laisser trainer l'éventuelle exception générée par Zend_View dans le cas d'une vue inexistante. Cela entre en conflit avec une autre Exception qui traine, j'essayerai de tirer ça au clair :-)

Zend Framework et les sessions

Geoffrey — Sat, 12 Aug 2006 20:31:00 +0200

Bon voilà, j'ai commencé le développement d'un projet, et j'ai décidé d'utiliser le Zend Framework (pour des raisons que je détaillerais dans un autre billet si ça vous interresse). Après mise en application du tutoriel de Chris, Un premier problème s'est posé à moi: l'intégration des sessions. Après quelques recherches, on peut trouver un blog développé avec ZF. Me ruant sur la partie d'admin, je découvre a ma grande stupeur des session_start() incrustés a chaque méthode du controlleur, un peu comme ça:

class AdminController extends Zend_Controller_Action {
	function indexAction() {
		session_start();
	}
	function postAction() {
		session_start();
	}
}

Ce n'est évidemment pas une solution acceptable. J'ai opté pour ma part pour une surcharge de la classe Zend_Controller_Action, avec un appel à session_start() dans le constructeur:

abstract class My_Controller_Action extends Zend_Controller_Action {
	public function __construct() {
		session_start();
	}
}

class AdminController extends My_Controller_Action {
	function indexAction() {
		// code
	}
}

Bon là, la problèmatique de base est déjà résolue, mais on peut aller plus loin, et ajouter un destructeur:

abstract class My_Controller_Action extends Zend_Controller_Action {
	public function __construct() {
		session_start();
	}

	public function __destruct() {
		$session_id = session_id();
		if (!empty($session_id)) {
			session_write_close();
		}
	}
}

Voilà c'est tout pour aujourd'hui, la prochaine fois, on parlera de l'utilisation des Views, et nottament, comment éviter un appel rébarbatif à Zend::registry() dans chaque controlleur.

Faire du CLI en PHP

Geoffrey — Sat, 05 Mar 2005 13:02:47 +0000

Souvent les gens ne voient PHP que comme un langage de script orienté web. Même si il est vrai que c'est son but premier, ce n'est pas la seule chose que PHP peut faire. Penchons nous un peu sur l'utilisation de PHP en CLI, qui permet d'utiliser PHP comme un langage de script classique. Nous utiliserons pour se faire un système linux (ubuntu pour être précis) avec un binaire php-cli déjà installé.

Au commencement...

Au commencement est le shebang. Qu'est-ce que c'est donc que ça ? C'est simplement la première ligne d'un script shell, celle qui indique au shell quel interpréteur utiliser pour executer le script. Elle début obligatoirement par les caractères #! (qu'on appelle shebang), suivis du chemin absolu de l'interpréteur. Dans la plupart des cas, l'intérpréteur PHP se situe dans /usr/bin et s'appelle php, tout simplement. Ce qui nous donne donc:

#!/usr/bin/php

Bien sur, il est possible que votre interpréteur se situe ailleurs, /usr/local/bin/php par exemple. Pour le trouve, vous pouvez utiliser la commande which:

ash@sushi:~$ which php
/usr/bin/php

Si cette commande ne retourne rien, c'est que php-cli n'est pas installé, et là ça dépasse le cadre de cet article :)

Un petit détour par la doc

A ce stade, il est bon d'aller voir ce que la doc a a nous dire sur l'utilisation de PHP en ligne de commande. On y apprend toutes sortes de choses, a commencer par la compilation de PHP en CLI. On y apprend également que certaines valeurs du php.ini sont différentes de celles de PHP utilisé avec un server web, et nottement:

html_errors, pour ne pas afficher de HTML dans les erreurs
max_execution_time, pour autoriser un temps d'execution infini
register_argc_argv, pour peupler les variables $argc et $argv, sur lesquelles nous reviendrons plus tard

On y apprend aussi que php-cli enregistre automatiquement de nouvelles constantes telles que:

STDIN
STDOUT
STDERR

Qui représentent respectivement l'entrée standard, la sortie standard, et la sortie d'erreur standard. Nous reviendronts sur ces constantes et leur utilisation plus tard.

La dernière chose que nous retiendrons de cette page est que php-cli ne modifie pas le repertoire courant a l'execution d'un script. C'est à dire que si vous vous trouvez dans le répertoire /tmp, et que vous executez php /home/ash/foo.php, la fonction getcwd (GET Current Working Directory) retournera /tmp, et pas /home/ash.

Notre premier script en CLI

Il est grand temps d'entrer dans le vif du sujet et de faire notre premier script. Soyons originaux, créons un hello_world.php, avec le code suivant:

#!/usr/bin/php
<?php print "hello world !"; ?>

Une fois le fichier créé, nous avons deux possibilités pour l'executer. Soit lancer directement l'interpréteur PHP en lui précisant le script a executer:

$ /usr/bin/php ./hello_world.php

Soit rendre le script executable et l'executer directement:

$ chmod +x ./hello_world.php
$ ./hello_world.php

Dans tous les cas, le résultat est le même:

hello world !

Facile non ? Notez bien que si vous décidez de rendre le script executable, vous n'aurez a executer la commande chmod qu'une seule fois.

Vous remarquerez surement que votre prompt s'affiche directement après le !, c'est normal, nous n'avons pas inclus de caractère de nouvelle ligne () dans notre print. Vous pouvez donc modifier le script ainsi:

#!/usr/bin/php
<?php print "hello world !
"; ?>

Et le tour est joué.

Utilisation de $argc et $argv

Tout ça c'est bien beau, mais un script c'est quand même mieux quand on peut lui passer des arguments. Et non, executer ./hello_world.php?arg=value ne fonctionne pas :-) Comment faire alors ? Les variables $argc et $argv sont là pour ça.

Pour passer des paramètres à un shell script, on utilise usuellement la syntaxe suivante:

$ ./script [arg [arg...]]

C'est comme cela que nous procéderons en PHP-CLI. La variable $argc (ARGuments Count) contient le nombre de paramètres passés au script, tandis que la variable $argv (ARGuments Values) est un array contient les valeurs de ces arguments. Modifions donc notre script de tout à l'heure:

#!/usr/bin/php
<?php
var_dump($argc);
print_r($argv);
?>

Et executons le en lui passant quelques paramètres:

$ ./hello_world.php foo bar

Voyons le résultat:

ash@sushi:~$ ./hello_world.php foo bar
int(3)
Array
(
    [0] => ./hello_world.php
    [1] => foo
    [2] => bar
)

On remarque que le nom du script compte comme un argument.

Utilisation de STDIN

Ces constantes dont nous avons parlé plus tôt sont très importantes. Elles définissent les flux standards à votre disposition, mais nous ne nous interresserons qu'a STDIN dans cet article.

STDIN (STanDard INput) est l'entrée standard. C'est elle que vous devez utiliser que vous voulez interragir avec l'utilisateur. Par exemple pour lui faire entrer des données. Modifions encore une fois notre hello_world.php:

#!/usr/bin/php
<?php
$name = trim(fgets(STDIN));
print "hello $name !
";
?>

Et executons le:

ash@sushi:~$ ./hello_world.php 
geoffrey
hello geoffrey !

Le script a donc attendu que je tape quelque chose en terminant par un CRLF (Cariage Return Line Feed, la touche Entrée quoi ;). J'ai donc tapé geoffrey, et voilà. Notons l'utilisation de trim pour supprimer le CRLF en question.

Le mot de la fin

Voilà, avec ça, vous devriez avoir les bases nécessaire pour commencer a faire du PHP-CLI. Cela dit, cet article n'explore pas toutes les subtilités du CLI, et une bonne lecture de documentation est fortement conseillée :)

L'édition efficace avec vim

Geoffrey — Sat, 08 May 2004 23:20:02 +0000

Encore une traduction d'un article de Jonathan McPherson ! Cette fois l'article porte sur vim, l'éditeur de texte des décideurs pressés. Les remerciements vont cette fois à Grégoire Gilbert qui m'a traduit plus de la moitié de l'article quand même :)

"To me, vi is Zen.
To use vi is to practice zen.
Every command is a koan.
Profound to the user,
unintelligible to the uninitiated.
You discover truth every time you use it."

--reddy@lion.austin.com

Ce tutoriel recquiert des connaissances de base de vim -- mode insertion, mode commande, charger et sauver des fichiers, etc. Il a pour but d'aider les novices à développer leurs compétences pour utiliser vi efficacement.

Dans ce tutoriel, <C-X> signifie Ctrl-X -- c'est à dire, gardez la touche Ctrl enfoncée et appuyez sur X. Vous pouvez obtenir de l'aide sur la plupart des commandes utilisées en tapant :help command dans vim, en remplaçant command par ce sur quoi vous voulez de l'aide.

Se déplacer efficacement

Rester en dehors du mode insertion

En général, vous voulez passer le moins de temps possible dans le mode insertion de vim, car ce mode fait agir vim comme un stupide éditeur de texte. C'est pourquoi la plupart des novices passent tant de temps en mode insertion -- il rend vim facile à utiliser. Mais la vraie puissance de vim réside dans le mode commande ! Vous verrez que mieux vous connaitrez vim, moins vous passerez de temps en mode insertion.

Utilisez h, j, k et l

Le premier pas vers l'édition efficace avec vim est de vous sevrer des touches flèches. Un des avantages du design de vim est que vous n'avez pas constamment besoin de bouger vos mains entre les touches flèches et les touches lettres; quand vous êtes en mode commande, les lettres h, j, k et l correspondent aux directions gauche, bas, haut et gauche respectivement. Cela nécessite un peu d'entraïnement pour s'y habituer, mais vous verrez la différence quand vous y serez habitué.

Quand vous éditez un e-mail ou un autre texte formatté par paragraphes, vous remarquerez peut-être que les touches de direction sautent plus de lignes que vous ne le voudriez. C'est parceque vos paragraphes apparaissent comme une seule longue ligne dans vim. Tapez g avant h, j, k ou l pour bouger d'une ligne écran plutôt que d'une ligne virtuelle.

Utilisez les mouvements pour déplacer le curseur dans la ligne courante

La plupart des éditeurs n'ont que des commandes simples pour déplacer le curseur (gauche, haut, droite, bas, au début/à la fin de la ligne, etc). vim possède des commandes de déplacement très avancée; ces commandes sont appelées mouvements (NdT: motions). Quand le curseur bouge d'un point à un autre, le texte entre les points (points inclus) est considéré comme étant parcouru (C'est important pour plus tard).

Voici quelques uns des mouvements les plus utiles:

fx: Déplace le curseur en avant jusqu'à la prochaine occurence du caractère x (bien entendu, x peut-être n'importe quel caractère). C'est une commande extèmement utile. Vous pouvez taper ; pour répéter la dernière commande f.
tx: Pareil que f, mais bouge le curseur juste avant le caractère, pas juste dessus (Très utile, vraiment).
Fx: Déplace le curseur en arrière jusqu'à la prochaine occurence de x sur la ligne courante.
w: Déplace le curseur en avant d'un mot.
b: Déplace le curseur en arrière d'un mot.
0: Déplace le curseur au début de la ligne courante.
^: Déplace le curseur sur le premier caractère de la ligne courante.
$: Déplace le curseur à la fin de la ligne courante.
): Déplace le curseur en avant jusqu'à la prochaine phrase (Utile quand vous éditez un e-mail ou des documents textes).
(: Déplace le curseur en arrière jusqu'à la prochaine phrase.

Se déplacer efficacement dans le fichier édité

vim possède de nombreuses commandes qui peuvent vous transporter où vous le souhaitez dans votre fichier -- il est rare que l'on ait à le parcourir manuellement. Les combinaisons de touches ci-dessous ne correspondent pas techniquement à des déplacements, si on considère qu'elles servent à se déplacer dans le fichier et non pas dans une ligne.

<C-F>: Fait avancer le curseur à l'écran de texte suivant.
<C-B>: Fait reculer le curseur à l'écran de texte précédent.
numG: Place le curseur à la ligne num. (Par exemple, 10G déplace à la ligne 10.)
gg: Déplace le curseur au début du fichier.
G: Déplace le curseur à la fin du fichier.
H: Déplace le curseur en haut de l'écran.
M: Déplace le curseur au milieu de l'écran.
L: Déplace le curseur en bas de l'écran.
*: Lis la chaîne de caractères sous le curseur et déplace ce dernier à l'endroit suivant où elle apparait de nouveau. (Par exemple, si votre curseur se trouvait sur le mot bob, le curseur se déplacerait jusqu'à la prochaine occurence de bob dans votre fichier.)
#: Même chose que ci-dessus, sauf qu'il déplace le curseur sur l'occurence précédente.
/text: A partir de la position du curseur, trouve l'occurence suivante de la chaîne de caractères text et s'y rend. Vous devrez presser la touche Entrée pour exécuter la recherche. Pour ré-exécuter votre dernière recherche, tapez n (pour next occurance (NdT: occurence suivante).)
?text: Même chose que /, mais cherche dans la direction opposée.
ma: Crée un signet nommé "a" référant à la position actuelle du curseur. Un signet peut être nommé par nimporte quelle lettre en minuscule. Vous ne voyez pas le signet, mais il est là !
`a: Aller au signet a. Important: c'est une backquote et non pas une quote simple. La touche backquote s'obtient à l'aide de la combinaison de touches alt+7 (pavé principal) sur un clavier azerty.
`.: Aller à la dernière ligne que vous avez éditée. Cette fonction est très utile ! Si vous avez besoin de parcourir le fichier pour regarder quelque chose, vous pouvez revenir à l'endroit où vous vous trouviez sans avoir à utiliser de signet, en utilisant `.

Saisir efficacement

Utiliser la complétion de mots

vim a un système de complétion de mots très pratique. Cela signifie que vous pouvez ne taper qu'une partie d'un long mot, presser une touche, et vim fini de l'écrire pour vous. Par exemple, si vous avez une variable nommée JeSuisUneVariableAvecUnNomImbuvable quelque part dans votre code, vous ne voudrez probablement pas taper son nom en entier à chaque fois que vous souhaitez l'utiliser.

Pour utiliser la complétion de mots, tapez simplement les quelques premières lettres de la chaîne (pour notre exemple: JeSuisUn) et pressez <C-N> (cela signifie que vous devez maintenir enfoncé Ctrl et taper N) ou <C-P>. Si vim ne vous donne pas le mot que vous souhaitez du premier coup, continuez d'essayer -- vim vous proposera toutes les complétions possibles qu'il trouvera.

Entrez intelligemment dans le mode d'insertion

La plupart des nouveaux utilisateurs de vim, entrent dans le mode d'insertion en tapant i. Ca marche, mais c'est souvent inefficace car vi a un jeu de commandes permettant de basculer l'éditeur en mode d'insertion. Voici quelqu'unes des plus populaires:

i: Insère du texte à gauche du caractère courant.
I: Insère du texte au début de la ligne courante.
a: Insère du texte à droite du caractère courant.
A: Insère du texte à la fin de la ligne courante.
o: Crée une nouvelle ligne sous la ligne courante et y insère du texte.
O: Crée une nouvelle ligne au dessus de la ligne courante et y insère du texte.
c{déplacement}: Efface (change) le texte parcouru par le {déplacement} et insère du texte pour le remplacer. Par exemple, c$ effacera le texte du curseur à la fin de la ligne et entrera en mode d'insertion. ct! effacera le texte à partir du curseur jusqu'au point d'exclamation suivant (sans l'inclure) et entrera en mode d'insertion. Le texte effacé est copié dans le presse-papier et peut être collé.
d{motion}: Efface le texte parcouru par le {déplacement} -- comme c{déplacement}, mais n'entre pas en mode d'insertion.

Déplacer efficacement des blocs de texte

Utiliser la sélection visuelle et les modes de sélection appropriés

A la différence de l'original vi, vim vous laisse mettre en exergue du texte et y exécuter des opérations. Il y a trois modes de sélection visuelle principaux (ce sont les modes de mise en exergue). Ces modes sont les suivants:

v: Sélection par caractère. C'est le mode de sélection que la plupart des gens utilisent, donc entraînez-vous avec avant d'essayer les autres.
V: Sélection par ligne. Sélectionnera toujours des lignes entières. Plus pratique que le mode par caractère quand vous désirez copier ou déplacer un groupe de ligne.
<C-V>: Sélection par bloc. Extrêmement puissant et disponible dans très peu d'éditeurs. Vous pouvez sélectionner un bloc rectangulaire et tout le texte se trouvant à l'intérieur sera mis en exergue.

Toutes les touches de mouvement habituelles peuvent être utilisées -- donc, par exemple, vwww entrera dans le mode de sélection visuelle et mettra en exergue les trois mots suivants. Vjj entrera dans le mode de sélection visuelle par ligne et mettra en exergue la ligne courante et les deux sous cette dernière.

Couper et copier à partir de sélections visuelles

Une fois que vous avez une sélection mise en exergue, vous voulez probablement en faire quelque chose. Quelques-une des commandes les plus utiles que vous pouvez utiliser quand une partie d'un texte est mise en évidence:

d: Coupe (efface) le texte mis en exergue et le met dans le presse-papier.
y: Copie (ou yank (NdT: couper sec) qui est un terme vim-èsque pour copier) le texte mis en exergue dans le presse-papier.
c: Coupe le texte mis en exergue et le met dans le presse-papier. Comme d, à l'exception qu'il laisse l'éditeur en mode d'insertion.

Couper et copier à partir de sélections non-visuelles

Si vous savez exactement ce que vous voulez copier ou couper, vous pouvez le faire sans entrer dans le mode visuel. Vous gagnerez du temps.

d{déplacement}: Coupe le texte parcouru par le {déplacement} vers le presse-papier. Par exemple, dw coupera un mot et dfS coupera du curseur jusqu'à (en l'incluant) la prochaine lettre S en majuscule de la ligne courante.
y{déplacement}: Copie le texte parcouru par le {déplacement}.
c{déplacement}: Coupe le texte parcouru par le {déplacement} et laisse l'éditeur en mode d'insertion.
dd: Coupe la ligne courante.
yy: Copie la ligne courante.
cc: Coupe la ligne courante et laisse l'éditeur en mode d'insertion.
D: Coupe du curseur à la fin de la ligne courante.
Y: Yank la ligne entière, comme yy. (Oui, c'est contradictoire! Vous pouvez utiliser y$ pour faire ce que vous attendiez d' Y.)
C: Coupe du curseur à la fin de la ligne courante et laisse l'éditeur en mode d'insertion.
x: Coupe le caractère courant. (C'est, en quelque sorte, la touche d'effacement arrière du mode-commande.)
s: Coupe le caractère courant et laisse l'éditeur en mode d'insertion.

Coller

Coller est une chose simple. Mettez le curseur à l'endroit où vous voulez coller du texte et tapez p.

Utiliser plusieurs presses-papier.

La plupart des éditeurs ont un seul presse-papier. vim en a bien plus; les presse-papiers dans vim sont appellés registres. Vous pouvez lister tous les registres définis actuellement et leurs contenus en tapant :reg. Typiquement, vous utiliserez des registres en lettres minuscules; les autres étant utilisés par vim en internes et ne sont que rarement utiles.

Pour utiliser un registre spécifique pour une opération de type copier/coller, tapez simplement "a avant la commande, où a est le registre que vous voulez utiliser.

Par exemple, pour copier la ligne courante dans le registre k, vous pouvez taper "kyy. (Vous pouvez aussi taper V"ky. Pourquoi pas ?). Cette ligne restera dans le registre k jusqu'a ce que vous copiez spécifiquement quelque chose d'autre dans ce registre. Vous pouvez maintenant utiliser "kp pour coller le texte se trouvant dans le registre k.

Eviter les répétitions.

La stupéfiante commande .

Sous vi, taper . (un point) répettera la derniere commande que vous avez executé. Par exemple, si votre dernière commande était dw (effacement de mot (NdT: delete word), vi effacera un autre mot.

Utiliser les compteurs

Les compteurs sont une des plus puissantes et économiques (en temps) fonctionnalités de vim. Nimporte quelle commande peut être précédée d'un nombre. Le nombre dira à vim combien de fois exécuter la commande. Voici quelques exemples:

3j déplacera le curseur vers le bas, de trois lignes. 10dd effacera dix lignes.

y3&quote; copiera (yank) du curseur jusqu'à la troisième quotation mark (NDT: je laisse l'expression originale pour que vous puissiez comprendre la commande, mais il s'agit de guillemets) après le curseur, sur la ligne courante. Les compteurs sont utiles pour augmenter l'étendu d'un déplacement.

Enregistrement de macros

Occasionnellement, vous vous retrouverez à faire la même chose encore et encore sur des blocs de texte de votre document. vim vous laisse enregistrer une macro ad-hoc pour exécuter l'opération.

qregister: Commence l'enregistrement de macro dans le registre nommé register. Par exemple, qa commence l'enregistrement et met la macro dans le registre a.
q: Fin de l'enregistrement.
@register: Rejoue la macro stockée dans le registre register. Par exemple, @a rejoue la macro du registre a.

Gardez en tête que les macros enregistrent simplement vos pressions de touches pour les rejouer ensuite. Il n'y a rien de magique. Enregistrer des macros est presque une forme d'art car il y a tellement de commandes qui accomplissent une tâche donnée sous vim, et vous devez choisir avec attention les commandes que vous utilisez pendant que votre macro enregistre, afin qu'elles marchent aux endroits où vous avez prévu d'utiliser la-dite macro.

Ecrire du code sous vim

vim est un excellent éditeur de code source car il a de nombreuses fonctionnalités qui ont été spécifiquement conçues pour aider les développeurs. Voici quelques-unes des plus utiles:

]p: Comme pour p, mais ajuste automatiquement l'indentation du code collé pour correspondre au code dans lequel vous avez inséré. Essayez!
%: Mettre le curseur sur une acolade, un crochet ou une parenthèse et presser % enverra le curseur à l'acolade, au crochet ou à la parenthèse correspondant(e). C'est très pratique pour résoudre les problèmes de parsing liés à de multiples blocs de code imbriqués.
>>: Indente le code mis en exergue. (Voir la section plus haut, concernant la séléction efficace de texte. Si il n'y a pas de texte sélectionné, la ligne courante est indentée.)
<<: Comme >>, mais dés-indente.
gd: Aller à la ligne de définition (ou de déclaration) d'une variable
K: Aller à la page de manuel pour le mot actuellement sous le curseur. (Par exemple, si votre curseur est sur le mot sleep, vous verrez la page de documentation de sleep s'afficher.)

GNU Screen

Geoffrey — Thu, 01 Apr 2004 20:40:00 +0000

Ce billet est une traduction d'un article que j'ai trouvé sur kuro5hin. Ayant trouvé l'article très interressant, et me disant que putain faudrait que je mette du stuff utile sur digital fashion un jour, j'ai contacté l'auteur qui s'est empressé de me donner l'autorisation de traduire et publier son article sur mon blog, ainsi qu'une version plus actuelle de l'article sur son site. C'est cette version que je vous livre ici traduite. C'est ma première vraie traduction, donc soyez indulgent merci :) si vous rencontrez des fautes d'orthographe, de style, ou de tournure n'hésitez pas à le signaler dans les commentaires, je corrigerais en conséquence.

Je tiens à remercier l'auteur, Jonathan McPherson, pour avoir publié un si bon article et pour m'avoir autorisé à le traduire et à le publier, ainsi que Renaud Littolff, pour la relecture.

Voilà, bonne lecture.

Cet article est d'abord paru quand je l'ai écris pour kuro5hin. Si vous voulez lire la version originale de l'article avec des commentaires contenant des astuces utiles sur Screen, il est ici, archivé sur Kuro5hin.

La plupart des systèmes d'exploitations modernes basés sur Unix (par exemple Linux, MacOS X, et BSD) sont livrés avec un petit utilitaire en mode console appelé GNU Screen. C'est un outil puissant entre les mains d'un guerrier de la ligne de commande, un véritable couteau suisse de l'interaction homme-ordinateur en mode console.

Cet utilitaire, bien que d'une utilité considérable, reste utilisé par très peu de personnes. Pourquoi ? Peu de gens en connaissent seulement l'existence, et ceux-là comprennent rarement les problèmes qu'il résoud. Dans cet article, j'expliquerais ce que screen fait pour vous, et fournirais un jeu de commandes pour accomplir des tâches basiques avec screen. Je m'adresse ici à ceux qui sont compétents avec la ligne de commande mais qui n'ont peu ou pas d'expérience avec screen lui même.

Ce que screen fait

Screen peut-être décrit comme un multiplexeur de terminal. En l'utilisant, vous pouvez executer toutes les applications en mode console -- commandes de shell interactives, applications basées sur curses, éditeurs de textes, etc. -- que vous voulez dans un seul terminal. C'est cela qui accroche la plupart des utilisateurs de screen. J'avais l'habitude de lancer une demi-douzaine de terminaux quand je me connectais à ma machine: j'en voulais un pour lire mes e-mails, un pour éditer mon code, un pour compiler mon code, un pour mon lecteur de news, un pour un shell sur mon hébergeur, et ainsi de suite. Maintenant, je lance un terminal et execute screen à l'intérieur. Problème résolu.

L'autre fonctionnalitée cool de screen est sa capacité à détacher le terminal des programmes executés. Cela signifie que vous pouvez utiliser screen pour laisser tourner les programmes après avoir fermé accidentellement le terminal, ou même après vous être déconnecté et, plus tard, reprendre là où vous en étiez. Cela signifie que le concept de session dans laquelle vous executé des programmes est une entité flottant librement que vous pouvez attacher à n'importe quel terminal depuis n'importe où, ou aucun terminal si vous le voulez.

Débuter avec screen: lancer des programmes et permutage de fenêtres

Lancez screen en tapant screen dans votre shell preferré. Vous serez probablement accueilli par un message de bienvenue. Quittez le message de bienvenue et vous obtiendrez un prompt shell, qui ressemble beaucoup à ce que vous aviez avant de lancer screen. Que s'est-il passé ?

Chaque programme qui tourne dans screen s'execute dans une fenêtre, et chaque fenêtre est identifié par un numéro unique. Screen a créé une nouvelle fenêtre, l'a numérotée 0, et a lancé un shell a l'intérieur. Tapez quelque chose dans votre nouvelle fenêtre pour pouvoir la reconnaître quand vous y repasserez plus tard.

Maintenant créez une nouvelle fenêtre; ce sera la fenêtre 1. Pour cela, tapez C-a c; c'est à dire, tapez Ctrl-a puis tapez c (mnemotechnique:Create)

Maintenant que vous avez deux fenêtres, essayez de basculer de l'une à l'autre. Pour cela, tapez C-a C-a, ce qui vous fera basculer à la fenêtre que vous utilisez avant celle en cours. D'autres méthodes de basculement utiles dont vous aurez besoin si vous comptez lancer plus de deux programmes:

Utilisez C-a n et C-a p pour basculer respectivement vers la fenêtre suivante et précédente, par numéro.
Utilisez C-a N, où N est un numéro de 0 à 9, pour basculer vers la fenêtre correspondante.
Utilisez C-a " pour avoir une liste des fenêtres. Vous pouvez naviguer dans cette liste avec les flèches (ou en style vi, avec j et k), et activer une fenêtre en la mettant en surbrillance et en pressant Entrée. C-a w vous donnera une petite liste non interactive des fenêtres.

Détacher et réattacher: la magie du découplage de terminal

Si vous avez effectuer l'exercice ci-dessus, vous avez créer une session screen. Vous pouvez vous détacher de cette session en pressant C-a d. Vous pouvez aussi vous détacher juste en fermant l'émulateur de terminal qui contient la session. Cependant, gardez à l'esprit qu'aucune de ces manipulations ne termine votre session. Tout ce qu'elles font, c'est de détacher votre session du terminal courant. Tous les programmes qui sont lancés sous screen tournent encore. Vraiment.

Essayez: fermez l'émulateur de terminal que vous utilisiez pour l'exercice ci-dessus. Puis, si vous le désirez, déloguez vous et reloguez vous. Démarrez un nouvel émulateur de terminal, et tapez screen -r (r pour reattach). Vous serez exactement là vous en étiez quand vous avez détaché la session.

Vous pouvez surement imaginer moultes utilisations interressantes à cela. Vous pouvez lancer tous vos programmes console preferrés une fois et les laisser tourner dans une session screen persistante. Certaines personnes ont des uptime de screen de plusieurs mois.

Un autre d'exemple d'utilisation est d'avoir un bureau distant. Vous pouvez détacher une session au travail, vous vous connecter à la machine depuis chez vous et réattacher la session. Très très pratique. Avec un peu de pratique, vous pouvez même avoir plusieurs terminaux attachés à la même session, très utile pour le travail collaboratif et les rencontres.

Copier, coller, et remonter dans le buffer

Screen se souvient d'un nombre configurable de lignes de buffer, et vous en aurez besoin car vous ne pourrez pas utiliser les fonctionnalités de défilement de votre émulateur de terminal en utilisant screen. Vous pouvez accéder au buffer en vous mettant en mode copie (Copy Mode), en tapant C-a [. Vous pouvez marquer du texte n'importe où dans le buffer et le coller avec C-a ]. Screen est aussi capable d'écrire des fichiers de log, mais ceci dépasse le cadre de ce tutoriel.

Surveiller le silence et l'activité

Un des désavantage de faire tourner plusieurs programmes dans screen est que vous ne pouvez pas garder un oeil sur tous en même temps, puisqu'en général vous ne pouvez en voir qu'un seul à la fois (En fait, vous pouvez découper l'écran et voir plusieurs programmes à la fois, mais c'est un sujet avancé qui dépasse le cadre de ce tutoriel). Pour aider à atténuer ce problème, screen possède une fonctionnalité qui permet de surveiller le silence d'une fenêtre -- utile pour savoir quand une compilation est terminée par exemple -- ou son activité -- utile pour savoir quand quelqu'un parle finalement dans votre channel IRC preferré par exemple.

Pour commencer ou arrêter de surveiller une fenêtre pour un silence de 30 secondes, tapez C-a _; pour commencer ou arrêter de surveiller l'activité d'une fenêtre, tapez C-a M.

Le faire partir

Comme vous l'avez vu dans la section sur le déttachement et le réattachement, screen n'est pas facile à tuer. Vous ne pouvez pas juste fermer le terminal qui le contient (En fait vous pouvez, mais tous les programmes tournent encore sur votre système, prêts a être réattachés).

A ma connaissance, le seul moyen de quitter screen en douceur (cad sans envoyer de méchants signaux aux processus qui ne méritent pas ça) est de fermer chaque fenêtre de screen. Quittez tous les programmes ou shells qui tournent dans une fenêtre, et elle se fermera. Quand le dernier programme qui tourne dans screen est terminé, screen lui même se termine. Vous pouvez forcer l'arret de screen avec C-a C-_, mais je ne vous le recommande pas.

Autres trucs

Screen est capable de bien plus que ce que j'ai décris ci-dessus, mais c'est assez pour que vous débutiez. Vous pouvez taper C-a ? pour obtenir une liste laconique des commandes disponibles quand vous êtes sous screen. La page man de screen contient pas mal d'informations aussi. Et voilà quelques ressources web si vous avez des questions:

Yahoo GNU Screen Group
Une mailing-list à traffic relativement élevé pour screen. Beaucoup de personnes expérimentées trainent dessus.

La page screen de Sven Guckes
Une autre vue d'ensemble; un peu plus laconique que celle ci.

La page officielle de screen
Pas besoin d'explications. Les détails sont étonnemment clairsemés.

La page de manuel de screen
Formattée agréablement et divisée en sections. Bonne référence. N'oubliez pas de voir les sections sur .screenrc pour customiser screen.

Screen FAQ
Pas pour débutant, mais une bonne ressource pour régler les problèmes.