willoblog

Bon, troisième post de la journée sur le sujet, après les deux premiers. Petits trucs et astuces pour pouvoir afficher des scripts bash comme cela est réalisé sur mon site.

Pour le transcript, deux problèmes

Balises malgré elles

SyntaxHighlighter transforme tous les chevrons « < » et « > » en entités html correspondantes, respectivement « &lt; » (less than) et « &gt; » (greater than). Ce ne serait pas grave s'il ne le faisait pas seulement pour presque tous les chevrons... Or il cherche à détecter automatiquement les balises (ce qui n'est pas très malin dans du code bash d'ailleurs, ce qui fait que mon adresse mail par exemple était comprise comme une balise, dégradant quelque peu la suite de l'affichage. Total : il faut le faire pour lui.
Au départ, j'avais choisi d'utiliser readline en php, à savoir

<pre class="brush: bash">
<?PHP  @readline('compil'); ?>
</pre>

Mais transformer les chevrons à l'avance n'est pas beaucoup plus compliqué :

<pre class="brush: bash">
<?PHP  echo str_replace('<','&lt;',str_replace('>','&gt;',file_get_contents('compil'))); ?>
</pre>

Vous aurez remarqué que du coup, dès que le fichier est modifié, c'est le code de la dernière version qui s'affiche. Zéro maintenance (le fichier compil est un lien symbolique vers /usr/local/bin/compil sur mon serveur).

Décidément, ces chevrons...

Et c'est à ce moment que l'on relit un peu ce qui s'affiche à l'écran, et qu'on se rend compte que plein de chevrons (mais pas tous) sont restés à l'état d'entités html. Alors qu'en enlevant l'influence de SyntaxHighlighter, on obtient bien le résultat attendu. Il m'aura fallu quelques minutes pour me souvenir que lt et gt, sont des mots-clés en bash, justement pour des tests numériques plus grand/plus petit (ouais, tout est lié). Un grand dilemme se pose alors. Soit on laisse comme ça, et le code affiché est faux. Soit on s'arrange pour ne jamais avoir de chevrons (ce qui est impossible quand on a besoin de redirections). Soit on commente les mots-clés gt et lt dans le fichier de définition shBrushBash.js, et tant pis pour leurs rares apparences en tant que tests, où ils ne seront pas colorés comme il faut. J'ai choisi cette dernière solution.

Pour l'aide

Ah, là ça se corse. Au départ j'avais recopié telle quelle la réponse de compil -h. Je me suis dit alors « mais si t'as une coquille dans l'aide ou que tu la modifies, il faudra revenir ici... au secours ». Alors j'ai trouvé un moyen. Après plusieurs tâtonnements et hésitations sur la meilleure fonction php entre exec, system et passthru, j'ai opté pour

<pre class="aide">
$ compil -h
 
<?PHP 
exec('[ ! -e compil.help -o compil -nt compil.help ] && compil -h | tr -d "\033" | sed -e "s/\[1m/<b>/g" -e "s/\[0m/<\/b>/g" > compil.help');
@readfile('compil.help'); ?>
</pre>

Explication : la dernière commande lit et affiche un fichier compil.help. On va donc y mettre l'aide. Problème, j'utilise un formatage à base de caractères bizarres qui permettent de mettre en gras du texte en console. On prend donc le résultat de compil -h, on en vire donc le caractère bizarre (grâce à la commande tr -d), puis on identifie le début et la fin des mises en gras, que l'on remplace de façon moche mais fonctionnelle par des balises de formatage html.
Le début est un test, qui permet d'exécuter la commande seulement si compil.help n'existe pas ou est plus ancien que compil. Cela semble fonctionner à peu près correctement.

J'ai découvert il y a quelques semaines un (gros) bout de code génial. Bon, ce n'est pas une grande découverte, il est déjà très utilisé, mais je n'avais jamais vraiment eu besoin de ce genre de trucs jusqu'à maintenant...

Comme le dit son site, il s'agit d'un code de surlignage syntaxique, ou comment rendre des bouts de codes déjà lisibles encore plus lisibles.

L'utiliser n'est pas très compliqué, puisqu'il suffit de télécharger le dernier .zip, de le dézipper et de regarder ce qu'on trouve. Un répertoire scripts contenant en particulier shCore.js qui est le cœur de la machinerie, ainsi que plein de shBrush*.js, qui contiennent les définitions des syntaxes pour différents langages. Personnellement, je n'ai pas besoin de tout, donc je n'ai choisi de garder que ce qui m'intéresse : Bash, Php, Plain que j'utiliserai souvent, Css, JScript et Sql un peu moins, et puis aussi au cas où Diff, Perl, Python, Xml. Un dossier styles contient lui les fichiers de mise en page css, parmis lesquels shCore.css est obligatoire et ensuite shThemeDefault.css correspond au seul thème écrit en noir sur blanc (les autres font du blanc sur noir, je déteste ça). Sans oublier les trois icônes qui seront affichées dans la toolbar et l'icône de retour à la ligne.

Donc on prend tous ces fichiers, on met tout ça dans un répertoire, appelé par exemple syntaxhighlighter, à la racine de notre formidable site web qu'on adore et dont on prend soin. Il ne reste plus qu'à modifier les pages web en ayant besoin. Il faut rajouter dans l'entête html :

<script type="text/javascript" src="/syntaxhighlighter/shCore.js"></script>
  <link type="text/css" rel="stylesheet" href="/syntaxhighlighter/shCore.css"/>
  <link type="text/css" rel="stylesheet" href="/syntaxhighlighter/shThemeDefault.css"/>
  <script type="text/javascript" src="/syntaxhighlighter/shBrushPlain.js"></script>
  <script type="text/javascript" src="/syntaxhighlighter/shBrushBash.js"></script>
  <script type="text/javascript">
    SyntaxHighlighter.all();
  </script>

Ensuite, tous les paragraphes de type <pre> seront analysés, pour peu qu'on dise à quel langage ils correspondent, en ajustant la classe :

<pre class="brush: bash">

par exemple. J'ajoute aussi, pour éviter la numérotation des lignes quand il s'agit d'une simple ligne de commande :

<pre class="brush: plain; gutter: false">

Le résultat a été utilisé dans de nouvelles pages sur mon site, dédiées à des scripts dont je me sers assez souvent et que j'ai écrits pour cela. C'est là qu'on se dit que la coloration syntaxique rend le code plus lisible.

Pour info, la coloration effectuée dans les articles du blog n'est absolument pas due à SyntaxHighlighter mais à un plugin pour Dotclear nommé SyntaxeHl.

Suite du message précédent : ah, enfin un peu de temps à soi (bon en fait, je l'ai pas vraiment, tout ce temps, mais je le prends quand même...), j'ai acheté un nouveau nom de domaine rien qu'à moi (je ne pensais pas que ça ne coûtait que 1€ chez ovh), un certificat ssh propre rien qu'à moi pour un an (à 15$ chez RapidSSLOnline comme j'en avais déjà parlé).

Et du coup je m'amuse un peu avec Apache, à faire des vrais virtual hosts et à utiliser un peu l'URL Rewriting. Ça a l'air de fonctionner maintenant (désolé pour la gêne occasionnée). Entre temps le blog a déménagé sur une nouvelle adresse rien qu'à lui, à savoir http://blog.cyril-ravat.fr/. L'ancienne adresse fonctionne toujours, a priori jusqu'à ce que j'en ai marre, et tout est redirigé automatiquement ici.

Ceux qui ont déjà cherché un certificat ssl ont souvent, comme moi, abandonné en se disant « Quoi ? 5000€ pour un truc qui me sert si peu ? ». Merci Verisign.

Au final, tout le monde (ou du moins, tous ceux qui n'ont pas derrière eux le budget pharaonique des ressources informatiques du CAC40), ont choisi de s'auto-fabriquer leur certificat, car c'est pas si compliqué, relativement bien expliqué partout, et surtout totalement gratuit. Et puis ça fait un peu geek aussi. :)

Le problème, c'est qu'aucun navigateur ne me fait confiance de base. Du coup, quand vous venez sur mon site en https, il vous demande s'il doit me faire confiance. Avec insistance. Beaucoup d'insistance, de plus en plus même, et la nouvelle politique de Firefox 3 en la matière me paraît quelque peu excessive : 5 clics obligatoires, passant par du jargon très informatique, et avec des pages ressemblant beaucoup trop à des pages d'erreur classiques...

C'est pas si gênant, et la preuve est que je fais avec depuis assez longtemps, en particulier parce que je ne me sers pas de ssl pour l'authentification du site (je ne suis pas une banque, si d'aventure un jour qqun tentait de me piquer des internautes en se faisant passer pour moi, grand bien lui fasse). Je ne m'en sers que pour chiffrer les connexion quand je le souhaite, typiquement quand je donne des accès par http(s donc) à des documents confidentiels (principalement des photos, si si) à des personnes de confiance. Du coup, si la personne est ok et a cliqué 5 fois, on peut discuter tranquillement sans que personne ne puisse savoir de quoi on parle, et c'est ça qui m'importe. Reste la petite gène pour ceux qui doivent cliquer frénétiquement sur les « oui, je suis sûr de ce que je fais, j'ai toutes mes facultés mentales et je veux accéder à ce site ».

Aujourd'hui, je me disais que j'en avais marre de cette situation, que j'aimerais que des choses changent. Petite recherche google plus tard, il y a des solutions (j'ai pas le temps de m'en occuper maintenant, d'où la note pour plus tard) :

• startcom.org propose un certificat gratuit. Si si, gratuit, c'est incroyable ! Et reconnu par Firefox et Safari. Bon, bien sûr, Internet Explorer, non (il faudra donc cliquer sur « oui blablabla » dans IE).
• Et il y a les certificats RapidSSL qui sont pas trop cher, du moins beaucoup moins que les autres. Reconnu sur tous les navigateur existants ou presque, c'est la fête.

Le problème de RapidSSL ? Je rappelle que je ne me sers des certificats que comme clé de chiffrement des connexions : du coup, plus grosse est la clé, plus difficile est le déchiffrement. Je ne suis pas sûr de ce que je raconte parce que je connais mal, mais normalement j'ai actuellement une très grosse clé (ne croyez pas que je m'en vante tous les jours non plus), et même Firefox me le dit : « connexion chiffrée : chiffrement de haut niveau (AES-256 256bit) ». Et RapidSSL, tous les sites le vendent avec « Fort Cryptage 128 Bit, Standard SSL de l’industrie ». Bref, moins bien que ce qu'on peut faire en auto-signé. M'enfin, si c'est pour éviter des clics inutiles (qui comme tout le monde le sait contribuent au réchauffement de la planète)...

RapidSSL, si j'ai bien compris, fait partie des certificats reconnu par Verisign et donc par le reste du monde. Mais plein de fournisseurs en revendent, et a priori il n'y a pas de risque à les prendre là. Les deux premiers ou presque dans Google sont finalement pas si cher :

• trustico.fr à seulement 12€ par an.
• rapidSSLonline à seulement 12$ par an (ça fait combien en centimes d'euros ? ;) ).

Allez, un jour peut-être.

Entre d'autres choses à faire, parce que les vacances sont un concept totalement galvaudé, petite mise à jour des choses les plus visibles depuis la page d'accueil. Je commence enfin à trouver douteux ce choix de violet, c'est plutôt bon signe.

Toujours pas eu le temps de réfléchir à la mise à jour du top10-musiques. Désolé.

Ce soir, j'ai eu envie de reprendre un peu en main mon blog, qui commençait à dépérir. Après un petite recherche pour mettre à jour le plugin de changement de thème disponible sur le blog de ClashDesign (qui ne fonctionnait plus suite à une un peu trop périlleuse tentative de migration), j'ai trouvé via l'excellente liste officieuse des plugins compatibles DC2 un plugin de sauvegarde automatique très très bon. Merci aux auteurs de ces plugins et à ceux des plugins dont je ne me sers pas : c'est par la vivacité d'une communauté que l'on peut juger de la qualité d'un logiciel open-source.

La suite : les thèmes.