Web services Ligne de commande

Source LinuxFr.org

Publié le 09.04.2018
Trois outils pour développeur : MailHog, Tokei et Pandoc

Dans cette dépêche, je vais vous présenter trois outils que j’utilise de temps en temps et qui pourraient servir à d’autres développeurs :

  • MailHog permet d’attraper des courriels pour les examiner ;
  • Tokei compte les lignes de code d’un projet ;
  • Pandoc est un couteau suisse pour manipuler des fichiers et les transformer d’un langage de balisage à un autre.

MailHog

MailHog (sous licence MIT) permet d’attraper des courriels envoyés par une plate‐forme de développement et de les afficher dans une interface Web. Pour cela, il fournit un serveur SMTP et un remplaçant au binaire sendmail, libre à vous de choisir le moyen qui vous convient le mieux. Il offre également, en option, la possibilité de transférer vers un vrai serveur SMTP les courriels et un outil de type chaos-monkey pour tester les cas d’erreurs d’envoi de courriels.

L’interface Web de MailHog avec trois courriels capturés

Je m’en sers quand je développe sur la partie serveur de Cozy Cloud. Cela permet de tester des fonctionnalités qui nécessitent l’envoi de courriels sans avoir à se compliquer la vie à configurer un vrai serveur d’envoi de courriels. En bonus, on évite de prendre le risque d’envoyer des courriels vers de vrais comptes d’autres personnes et on ne perd pas de temps à attendre que le courriel arrive, en attente d’un traitement anti‐pourriel.


Tokei

Pour estimer la taille d’un projet, le nombre de lignes de code peut être une métrique intéressante. Il existe plusieurs projets pour faire ça, celui que je trouve le plus pratique est Tokei (sous licence Apache ou MIT). Voici ce qu’il affiche pour le dépôt principal de code de LinuxFr.org :

-------------------------------------------------------------------------------
 Language            Files        Lines         Code     Comments       Blanks
-------------------------------------------------------------------------------
 CoffeeScript           10          770          642           31           97
 Dockerfile              1           70           49            4           17
 HTML                   24         2660         2161            4          495
 JavaScript             11         2686         2025          394          267
 Markdown                1          187          187            0            0
 Rakefile                2           33           24            3            6
 Ruby                  262        11593         8338         1500         1755
 Ruby HTML               1           47           46            0            1
 Sass                   47        27317        23467         1583         2267
 Shell                   4           68           50            4           14
 SVG                    41        10886        10865           17            4
 TeX                     1           53           43            0           10
 Plain Text             44          531          531            0            0
 XML                     1           11           11            0            0
 YAML                    4          173          160            4            9
-------------------------------------------------------------------------------
 Total                 454        57085        48599         3544         4942
-------------------------------------------------------------------------------

Par rapport à cloc, Tokei a plusieurs avantages :

  • il est beaucoup plus rapide (0,03 seconde pour Tokei contre 3,2 secondes pour cloc sur le dépôt principal de LinuxFr.org) ;
  • il est plus précis : cloc utilise des expressions rationnelles, alors que Tokei a de vrais analyseurs (en particulier, un début de commentaire dans une chaîne de caractères comme printf("/*") peut bien induire en erreur cloc) ;
  • il ignore par défaut les fichiers listés dans .gitignore (par exemple, quand j’ai lancé cloc sur l’exemple ci‐dessus, il a compté les fichiers dans tmp/cache et j’ai dû le relancer avec des options pour qu’il fasse ce que j’en attendais).

Pandoc

Il existe de nombreux langages de balisage : HTML, Markdown, reStructuredText, textile, DocBook, \LaTeX, MediaWiki markup, OrgMode, EPUB, etc. Et ces langages ont parfois plusieurs variantes (exemple : CommonMark et GitHub Flavored Markdown pour le Markdown). Bref, ce n’est pas toujours facile de connaître les différents langages et de passer de l’un à l’autre. Pandoc (sous licence GPL v2 ou plus) permet de convertir un texte de la plupart de ces langages vers un autre langage, ou d’autres choses comme du PDF ou de l’OpenDocument.

Je m’en sers, par exemple, pour écrire des présentations en Markdown et en générer une version PDF via la classe Beamer pour \LaTeX. Ça m’a également servi, par le passé, pour convertir un wiki d’un format à un autre.

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 19.03.2018
Des alternatives à grep, ls et find

Les outils en ligne de commande comme ls, grep et find existent depuis de nombreuses années et, même s’ils continuent de s’améliorer, il est parfois intéressant de regarder les alternatives. Je vais vous parler de ripgrep, exa et fd.

Ripgrep

Les alternatives à grep ne manquent pas. Déjà, la commande grep de son shell peut être soit le grep du projet GNU ou celui du projet BSD. Il y a aussi le grep intégré à Git. Et d’autres outils sont apparus ces dernières années, citons ack-grep, ag (the silver searcher), pt (the platinum searcher) et le petit dernier ripgrep.

Ces outils se battent pour savoir lequel est le plus rapide ou a le plus de fonctionnalités. Personnellement, j’utilise ripgrep car il est très rapide, réalise par défaut une recherche récursive dans les répertoires (un gros manque de GNU grep selon moi, mais c’est probablement bien trop tard pour changer le comportement de GNU grep), a une présentation par défaut des résultats que j’apprécie, et il sait chercher dans des fichiers compressés (gzip, bzip2, xz) avec l’option -z.

Exa

Lister des fichiers est un besoin de base dans un terminal et ls remplit bien ce besoin. Exa est une alternative à ls que j’utilise pour ses couleurs, qui viennent par défaut et que je trouve plus agréables que celles de ls. Il propose également une vue arborescente des répertoires et fichiers, qui remplace plutôt tree. Exa est aussi capable d’afficher le statut Git des fichiers et répertoires.

Fd

Fd peut remplacer avantageusement find. Je n’utilise que très peu l’un ou l’autre, mais fd a une syntaxe plus facile à retenir et il est, d’après ses tests, plus rapide que find. Il utilise par défaut l’encodage UTF-8, il a une sortie colorée et ignore les fichiers listés dans un .gitignore. Et surtout, ça fait deux fois moins de caractères à taper pour le nom de la commande. ;-)

Les points communs

Vitesse

On retrouve beaucoup de benchmarks autour de ces outils, les performances sont un vrai enjeu. Mettre trois secondes au lieu de quinze secondes peut paraître anecdotique pour des recherches un peu compliquées, mais cette différence peut casser le rythme : si une commande prend plus de dix secondes, je vais sûrement commencer à aller voir ailleurs.

Fonctionnalités et comportement par défaut

Ces outils ont beaucoup de fonctionnalités : les options que l’on peut passer en ligne de commande permettent de changer fortement leurs comportements. Ceci dit, en pratique, je n’utilise que peu d’options (et quasiment toujours les mêmes). En revanche, j’apprécie beaucoup que ces outils cherchent à avoir le comportement par défaut le plus utile.

Intégration avec Git

Ces outils ont tous une intégration avec Git : ripgrep et fd savent lire les fichiers .gitignore et exa sait afficher l’état Git des fichiers. Ce n’est pas un critère très important à mes yeux car je suis à l’aise avec Git en ligne de commande. Mais c’est intéressant de noter à quel point git est devenu incontournable en ligne de commande.

Rust

Un fait remarquable est que les trois outils présentés sont écrits en Rust. Il faut croire que ce langage convient bien pour écrire des outils en ligne de commande. C’est un domaine où le temps d’exécution est important (quand on lance une commande, c’est appréciable que le retour soit instantané ou en tout cas très rapide). Les langages de script (JavaScript, Ruby, Python) ont un temps de lancement de leur machine virtuelle qui peut casser cette impression de vitesse, je comprends donc que les développeurs d’outils en ligne de commande puissent s’en éloigner. En revanche, il est plus surprenant de ne pas retrouver d’outils en Go, en D, en OCaml ou en Haskell. Peut‐être que les lecteurs de LinuxFr.org auront une explication à cela.

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 23.04.2018
Quel terminal pour 2018 ?

Vous connaissez les terminaux, ces petites fenêtres le plus souvent noires où l’on tape des lignes de commande bizarres ? Eh bien, vous risquez d’être surpris : le choix du logiciel pour faire ça n’est pas aussi simple que ça en a l’air et des gens continuent de proposer de nouvelles alternatives. Cette dépêche vise à présenter rapidement quelques fonctionnalités intéressantes que les terminaux historiques ne géraient pas forcément et à présenter quelques terminaux.

Sommaire

Les fonctionnalités

Apparence et polices

Historiquement, les terminaux avaient une couleur pour le texte et une autre pour le fond. Si l’on s’en tient à ce siècle, les terminaux étaient principalement en 16 couleurs au début, puis certains terminaux ont commencé à gérer des palettes de couleur plus étendues (256 couleurs par exemple) et, aujourd’hui, certains terminaux savent manipuler des couleurs sur 24 bits.

De même, les terminaux utilisaient surtout des jeux de caractères où un caractère était codé sur un octet, mais la prise en charge d’Unicode est maintenant répandue. Il faut néanmoins se méfier, certains terminaux annoncent gérer l’Unicode mais ne savent pas afficher les caractères codés sur quatre octets comme les émojis.

La prise en charge des polices peut également réserver certaines surprises. Tous les terminaux ne savent pas afficher des ligatures comme on peut trouver dans Fira Code ou les polices avec les symboles Powerline.

Et l’on peut également citer la possibilité d’avoir des coins arrondis ou de la transparence parmi les fonctionnalités proposées par des terminaux.

Terminaux multiples

Certains logiciels proposent de gérer plusieurs terminaux. Cela peut se faire avec un seul processus qui contrôle plusieurs fenêtres pour gagner en mémoire vive, mais l’approche la plus courante consiste à avoir une seule fenêtre avec plusieurs onglets. Enfin, il existe des terminaux qui reprennent l’approche des gestionnaires de fenêtres par pavage : une seule fenêtre peut être découpée pour afficher plusieurs terminaux et des raccourcis clavier permettent de contrôler le placement des terminaux et passer de l’un à l’autre.

Performances

A priori, un terminal ne serait pas l’endroit où l’on accorderait la plus grande importance aux performances. Pourtant, la latence des terminaux n’est pas toujours suffisamment faible pour se faire oublier.

On peut également citer la vitesse de défilement ou la quantité de mémoire utilisée.

Simplicité et fonctionnalités

Certains terminaux se veulent volontairement limités en termes de fonctionnalités. D’autres font plus de choses, et certains vont jusqu’à proposer des greffons ou des API pour permettre des usages avancés.

Dans les fonctionnalités que l’on retrouve chez certains mais pas chez d’autres, il y a la possibilité de remonter dans l’historique du terminal (le scroll‐back est parfois laissé à un logiciel tiers comme tmux dans certains terminaux), pouvoir cliquer sur les liens, pouvoir lancer des commandes au démarrage du terminal, l’affichage d’images directement dans le terminal, la prise en charge de Wayland, etc.

Les terminaux

Les grands classiques

Tout d’abord, il y a les grands classiques. Le plus connu est xterm, suivi par rxvt et son dérivé rxvt-unicode.

Ceux intégrés à un environnement de bureau

Les principaux environnements de bureau ont leur terminal : Konsole pour KDE, GNOME terminal pour GNOME, Xfce terminal pour Xfce et Terminology pour Enlightenment.

Les terminaux légers

st est un terminal codé en peu de lignes de C, avec un choix fort de ne pas prendre en charge certaines fonctionnalités et de ne pas faire de gros efforts pour les performances.

qterminal est un terminal léger s’appuyant sur Qt.

Les pavants

GNOME Terminator et Tilix sont deux terminaux qui mettent en avant la possibilité de découper leur fenêtre pour afficher plusieurs shells à l’intérieur.

Ceux utilisant la bibliothèque VTE

Il existe plusieurs terminaux s’appuyant sur la bibliothèque VTE (ou des dérivées de cette bibliothèque). Citons termite, sakura et GTKTerm.

Ceux pour les amoureux de Quake

Quake avait une console qui s’ouvrait en appuyant sur la touche ² et qui se déroulait depuis le haut de l’écran. Certains terminaux s’en sont inspirés, comme Yakuake, Guake et Tilda.

Les rapides, en OpenGL

Alacritty est un terminal récent qui utilise le processeur graphique (via OpenGL). C’est probablement le terminal le plus performant aujourd’hui. En revanche, il ne couvre que peu de fonctionnalités (pas encore d’historique, par exemple).

kitty est un autre terminal qui tire parti du processeur graphique. Il propose également pas mal de fonctionnalités.

L’artillerie lourde

Hyper est un terminal en HTML/CSS/JS (c’est du Electron derrière). Ça ouvre des possibilités intéressantes pour les greffons et l’affichage d’images ou de vidéos, mais ça a également des inconvénients (on peut, par exemple, se poser la question des performances).

Terminus est un dérivé d’Hyper.

Upterm, anciennement nommé Black Screen, est également un terminal qui tourne avec Electron. Il fournit également le shell et une auto-complétion graphique des commandes.

Les originaux

cool-retro-term est un terminal avec un aspect qui fait penser aux vieux tubes cathodiques. Pour les nostalgiques donc !

Et le gagnant ?

Il n’y a pas vraiment de gagnant. Différentes personnes ont différents critères. Pour certains, la prise en charge des ligatures est primordiale, alors qu’elle peut être totalement inutile pour quelqu’un d’autre.

À titre personnel, j’ai testé pas mal de terminaux et je suis resté sur urxvt. kitty me semble particulièrement intéressant, mais un bogue de ma carte graphique m’empêche de l’utiliser. Alacritty me semble encore un peu trop jeune et limité en fonctionnalités. Je ne suis pas à l’aise avec les versions extrêmes : st est trop limité à mon goût, alors que Hyper est trop lourd. Je n’ai pas particulièrement apprécié les terminaux liés à un environnement de bureau (mais je n’utilise pas d’environnements de bureau) et je suis tombé sur plusieurs bogues gênants pour les terminaux avec la bibliothèque VTE.

Wikipédia propose une liste de terminaux et une comparaison de certains d’entre eux.

Et vous, chers lecteurs, qu’utilisez‐vous ? Et pourquoi ?


N. D. A. : Merci aux nombreuses personnes qui ont commenté pour faire découvrir leur terminal préféré. J’ai ajouté ces terminaux à la dépêche, mais je vous encourage à lire les commentaires, c’est plus détaillé et cela permet de mieux comprendre les spécificités de chaque outil !

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 10.06.2017
Optimisations et corrections pour Fim 1.2.3

Fim (File Integrity Manager) sort dans sa version 1.2.3 avec diverses corrections.

Fim est un gestionnaire de fichiers libre (licence GPL v3) qui permet de gérer de nombreux fichiers de n’importe quelle taille. Il peut, par exemple, gérer des musiques, des photos ou des vidéos. Il est capable de gérer des centaines de milliers de fichiers occupant une taille totale de plusieurs téraoctets. Il peut détecter les fichiers dupliqués et les effacer.

Fim Logo

Les nouveautés de la version 1.2.3

Général

  • passage de Gson à Jackson pour avoir un sérialiseur plus efficace  ;
  • réduction de la quantité de mémoire nécessaire pour charger un State.

Corrections de bogues

  • correction du problème no 9 : Exception dans le fil d’exécution « principal » java.lang.IllegalStateException ;
  • correction de l’algorithme de comparaison d’état ;
  • lorsque la taille dépasse 1 Go, Fim n’arrondit plus au Go le plus proche ;
  • utilisation du système international d’unités (SI) pour calculer la taille d’un fichier (1 000 — kilo — au lieu de 1 024 — kibi).

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 25.10.2016
Effacement des doublons et historique complet pour Fim 1.2.2

Fim (File Integrity Manager) sort dans sa version 1.2.2 avec diverses améliorations et un support de présentation en français.

Fim est un gestionnaire de fichiers libre (licence GPL v3) qui permet de gérer beaucoup de fichiers de n’importe quelle taille. Il peut, par exemple, gérer des musiques, des photos ou des vidéos. Il est capable de gérer des centaines de milliers de fichiers occupant une taille totale de plusieurs téraoctets. Il peut détecter les fichiers dupliqués et les effacer.

Fim Logo

French slides

Les nouveautés depuis la version 1.2.0

Général

  • ajout d'un support de présentation en français et en anglais ;
  • effacement des doublons avec la commande rdup ;
  • amélioration de l’affichage de la commande de détection des doublons ;
  • la commande log affiche le détail de toutes les modifications sur les fichiers ;
  • allocation dynamique de files d’exécution pour « hacher » les fichiers en fonction du débit du disque, ce qui permet plus de files d’exécution dans le cas d’un SSD et moins pour un disque dur classique ; ce mode de fonctionnement est activé par défaut ;
  • la commande diff est dépréciée en faveur de la commande status ;
  • l’option -c est dépréciée en faveur de l’option -m ;
  • la commande rdup utilise maintenant l’option -M.

Corrections de bogues

  • détection correcte en mode « super‐fast » des fichiers qui grossissent ;
  • commentaires avec espaces supportés sous Windows ;
  • diverses corrections, plus de détails dans le journal des modifications.

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 21.07.2016
Sortie de it-edit (Integrated Terminals Editor) 2.91

IT-Edit (Integrated Terminals Editor) est disponible en version 2.91.

Cette nouvelle version n'apporte pas de nombreuses améliorations par rapport à la version 2.0, mais constitue une étape importante, car elle est désormais basée sur la nouvelle version majeure de la bibliothèque libvte (bibliothèque implémentant un widget d'émulateur de terminal, utilisé par Gnome-terminal.) IT-Edit se met donc à niveau. À cette occasion, de nombreux bugs et imperfections ont été corrigés.

capture d'éran de it-edit-2.91

La plus importante des améliorations étant l'utilisation du chargeur de fichiers intégré à la bibliothèque gtksourceview3.0, qui permet de charger des fichiers codés dans tous les jeux de caractères (pas seulement UTF-8) ; l'éditeur s'est bien sûr amélioré avec le temps et la sortie des nouvelles moutures d'Ubuntu (Xenial) et de Debian (Jessie) ayant bien évolué depuis les versions précédentes.

Une intégration de la coloration syntaxique pour de nouveaux langages a été faite, comme par exemple le ReST sur lequel se base le générateur de documentation sphinx.

Concernant cette dernière (sur laquelle le nouveau gnome-terminal est basé) de nouvelles fonctionnalités apparaissent dans les menus contextuels des terminaux de it-edit :

  • ouvrir un nouvel onglet dans le panneau latéral de terminaux ;
  • fermer l'onglet actuel depuis ce panneau latéral ;
  • incrémenter la taille de la police (Font-scale, aussi configurable depuis le panneau de configuration) ;
  • décrémenter la taille de la police (Font-scale, aussi configurable depuis le panneau de configuration) ;
  • réinitialiser le terminal ;
  • et d'autres, accessibles depuis le panneau de configuration ;
  • la mauvaise nouvelle étant que libvte ne permet plus de mettre des images en arrière-plan des terminaux…

Mais je vous invite à tester ou à mettre à jour vers cette nouvelle version de it-edit en espérant que vous en serez satisfait(e). Je pense qu'il est utile de réellement tester un outil avant de l'adopter.

PS: it-edit ne se limite pas aux distributions de la famille Debian, il suffit de disposer des bibliothèques nécessaires par le biais du build de it-edit-2.91 basé sur les autotools.

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 02.06.2016
Liquid Prompt 1.10

Le Liquid Prompt est un prompt fluide affichant de manière limpide des informations utiles dans le prompt de votre shell bash ou zsh. Le liquidprompt était déjà bien rempli de fonctionnalités, certaines ont été ajoutées, d'autres corrigées, et leurs performances ont encore été améliorées avec les 216 commits durant les 17 mois écoulés. Il était temps de sortir une nouvelle version officiellement stable.

Je profite de cette dépêche pour remercier chaudement les 35 contributeurs qui par leurs patchs ont contribué à cette version.

Quelques changements sont présentés dans la suite de cette dépêche.

Pour les détails de cette version les curieux sont invités à consulter l'annonce complète, notamment pour quelques changements incompatibles. En voici un extrait traduit :

  • Les configurations de type LP_ENABLE sont désormais statiques et non plus prises en compte immédiatement après leur modification. Ça se passe via le fichier de configuration et la relance de Liquid Prompt. Ceci a permis de réduire drastiquement le coût d'affichage de chaque prompt.
  • Arrivée de la configuration LP_ENABLE_SUDO permettant une adaptation dynamique lors de l'utilisation de sudo. Noter que pour le moment cette configuration est désactivée, par défaut de capacité de différenciation immédiate entre une autorisation et un refus.
  • Beaucoup de corrections de bugs pour les indicateurs d'heure analogique, de température machine, de charge CPU et de batterie.
  • Meilleure prise en compte de l'usage de tmux par l'amélioration de sa détection.
  • Pour Zsh, l'option nopromptsubstest maintenant activée par défaut. Cela peut impacter notamment des définitions de RPS1 (défini en dehors de Liquid Prompt).

Note : deux bugs sur OS X ont déjà été remontés depuis la release, donc il est recommandé d'utiliser la branche master pour ce système d'exploitation.

Copie d'écran de Liquid Prompt

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 25.05.2016
Focus sur les performances avec Fim 1.2.0

Fim (File Integrity Manager) sort dans sa version 1.2.0 avec divers gains de performance.

Fim est un gestionnaire de fichiers libre (licence GPLv3) qui permet de gérer beaucoup de fichiers de n'importe quelle taille. Il peut par exemple, gérer des photos ou des vidéos. Il est capable de gérer des centaines de milliers de fichiers occupant une taille totale de plusieurs téraoctets. Il peut détecter les fichiers dupliqués et aider à les effacer.

Fim Logo

Les nouveautés de la version 1.2.0

Amélioration globale de la performance

  • Diminution de la taille du state en mémoire et sur le disque en utilisant Ascii85 au lieu de Hexa pour stocker les hash
  • Ajout du Super-fast commit
  • Augmentation de la capacité à gérer une très grande quantité de fichiers (1 098 138 fichiers fonctionne pour moi)
  • Optimisation de la comparaison des state pour pouvoir comparer rapidement deux State contenant 1 000 000 de fichiers

Général

  • Fim est maintenant distribué sous forme d'image Docker sur Docker Hub
  • Chaque commit sur Fim est maintenant testé sur Mac OS X grâce au builder Travis Mac

À noter : le format utilisé pour le state est nouveau et non-compatible avec le format précédent. Cela nécessite donc une ré-indexation / une nouvelle table de hashs : fim ci -y -c "Migration vers Fim 1.2.0".

Corrections de bogues

  • Vérification des droits sur le répertoire .fim avant toute exécution de commandes
  • Ignore maintenant les millisecondes des dates de modification (certains JDK ne les écrivent pas ou les écrivent à 0)
  • Ajout de l'option --output-max-lines permettant d'allonger la liste présentée maintenant par défaut : 200 lignes du même type tronquées.
  • Les fichiers vides ne sont plus répertoriés comme dupliqués.

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 13.11.2015
WebVim, une distribution Vim pour le dévelopment web

WebVim est une distribution Vim qui vient avec un lot de greffons pré-configurés et optimisés pour le développement web et JavaScript/node.js.

Logo WebVim

WebVim offre par défaut quelques fonctionnalités sympas, dignes de certains IDE et éditeurs de code spécialisés :

  • coloration syntaxique ;
  • affichage des erreurs de syntaxes et de styles ;
  • auto-complétion ;
  • refactoring ;
  • curseurs multiples ;
  • formatage et alignement automatiques ;
  • prise en compte de conventions d'édition (editorconfig) ;
  • prise en charge de git ;
  • navigation dans les modules nodes.js ;
  • un mode hardcore (où par exemple la touche Esc et les flèches sont désactivées) ;
  • et tout ce que Vim fournit par défaut (par exemple la vérification orthographiques) !

WebVim utilise le gestionnaire de greffons vim-plug en arrière plan et un système de chargement et de configuration avancé.

Historique

J'ai toujours été fasciné par certains de mes collègues et leur dextérité à éditer des fichiers textes plus vite que n'importe qui, mais j'ai utilisé pendant des années des outils tels qu'Eclipse ou Netbeans pour le développement et Vim pour l'édition de fichiers de configuration ou des modifications rapides en mode console.

Au fur et à mesure du temps, alors que mes doigts apprennent tous seuls les raccourcis Vim, je me dis qu'il est possible de migrer complètement vers cet éditeur pour mes tâches de développement. En fonction des besoins j'ai commencé à modifier mon .vimrc ajouter un greffon puis un autre. Comme beaucoup j'ai créé un dépôt de type dotfiles pour partager ma configuration. De fil en aiguille, mon répertoire .vim partagé est devenu WebVim.

Aujourd'hui c'est l'éditeur que j'utilise au jour le jour pour tous mes développements.

Philosophie

Le but est de prendre en charge mes cas d'utilisation bien précis, notamment l'édition de ces types de fichiers au sein de projets web :

  • HTML ;
  • CSS, SCSS ;
  • JavaScript côté client et serveur ;
  • JSON ;
  • markdown.

Édition d'un module JavaScript

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 11.11.2015
Kakoune, un éditeur de texte qui a du caractère

Kakoune est un éditeur de texte en console qui gagne a être connu. Cette dépêche a pour but de le faire découvrir à plus de monde.

NdM : Le logiciel est placé par ses auteurs dans le domaine public.

Présentation

Logo de Kakoune Kakoune avait été évoqué dans le journal Tour d'horizon des éditeurs de texte pour le terminal il y a bientôt 1 an.

Il a depuis continué d'évoluer assez rapidement et s'est doté récemment d'un site web Kakoune.org.

Kakoune, c'est plus de 3 ans de développement et plus de 14000 lignes de code c++11 ; il cumule aujourd'hui plus de 30 contributeurs.
De toute la famille des éditeurs inspiré de vi/vim, c'est le seul qui va au delà du clone et repense l'interaction avec le texte.

Kakoune reprend les grand concepts de la famille vi, à savoir :

  • un éditeur avec plusieurs modes (édition, sélection, commande, …) ;
  • les séquences de touches forment un langage d'édition de texte.

Fonctionnalités — Spécificités

Kakoune se définit lui-même comme :

  • inspiré par Vim (c’est un éditeur modal) ;
  • plus rapide (dans le sens "moins de touches à presser") ;
  • permettant la sélection multiple ;
  • ayant un design orthogonal.

Fonctionnalités

  • sélection multiple comme principale façon d'interagir ;
  • puissantes fonctions de manipulation des sélections :
    • sélection de toutes les correspondances d'une expression rationnelle dans les sélections en cours,
    • conservation de toutes les sélections contenant ou ne contenant pas de correspondances à une expression rationnelle,
    • divisions des sélections en cours avec une expression rationnelle,
    • objets texte (paragraphe, phrase, blocs imbricables) ;
  • puissantes primitives de manipulation du texte :
    • alignement des sélections,
    • rotation du contenu des sélections,
    • manipulation de la casse,
    • indentation,
    • envoi de chaque sélection à un filtre extérieur ;
  • architecture client-serveur :
    • clients multiples sur la même session d'édition,
    • utilise tmux ou votre window manager pour gérer les fenêtres ;
  • interaction facile avec les programmes externes ;
  • aide contextuelle automatique ;
  • complétion automatique lors de la frappe ;
  • macros ;
  • crochets ;
  • coloration syntaxique :
    • prise en charge de plusieurs langages dans le même tampon,
    • coloration différente d'un même tampon dans des fenêtres différentes.

Quelques exemples

Afin d'illustrer la manière de travailler avec Kakoune, voici quelques exemples expliqués.

Le premier exemple permet d'aligner les signes = apparaissant sur trois lignes consécutives.

3Xs=<RET>&
  • 3X sélectionner 3 lignes à partir de la ligne courante
  • s entrée en mode sélection
  • =<RET> on sélectionne le = dans chaque ligne
  • & aligner les sélections

Le second exemple montre comment remplacer un motif par un autre dans le tampon courant (communément appelé "remplacement global").

%sfoo<RET>cbar<ESC>
  • % sélectionner l'intégralité du tampon
  • sfoo<RET> sélectionner les instances de l'expression régulière "foo" dans la sélection courante
  • c entrer en mode d'insertion pour remplacer le contenu des sélections
  • bar<ESC> insérer "bar" puis quitter le mode d'insertion

Pour les vimistes, un document, Migrating from VIm, explique les différences de concepts.

La principale différence étant que dans Kakoune, on sélectionne d'abord le texte à manipuler, puis on lance des actions sur la ou les sélections. Comme tout tourne autour des sélections, le choix a été fait que les commandes avec Shift étendent celles-ci. Par exemple : w sélectionne un mot et Shift-w ajoute le mot suivant à la sélection.

Ce choix a nécessité dans certain cas de rompre la compatibilité avec vim, par exemple J sélectionne vers le bas et c'est Alt-J pour joindre deux lignes.

Compilation — Installation

Kakoune fonctionne sous les Unix, ses dépendances sont :

  • libboost-all-dev
  • libncursesw5-dev

Développé en C++11, il nécessite un compilateur compatible, soit GCC >= 4.8 ou clang = 3.4

Pour les personnes intéressées qui voudraient tester Kakoune, les instructions de compilation sont simples et tiennent en quelques lignes :

git clone https://github.com/mawww/kakoune.git
cd kakoune/src
make
./kak

Il existe aussi beaucoup de recettes (OSX, Arch, Fedora, etc.) dans la documentation principale, section installation

Avenir

Bien que Kakoune continue d'évoluer, il est tout à fait utilisable en tant qu'éditeur principal. Des modifications incompatibles avec l'existant peuvent encore arriver de temps à autres mais se font de plus en plus rares. La prise en charge de l'édition de code C ou C++ est bien en place, et le modèle d’extensibilité semble fonctionnel.

Les prochains points clé pour Kakoune sont désormais :

  • davantage d'utilisateurs afin de développer la prise en charge de plus de langages ;
  • de cas d'utilisations (voir Advertise Kakoune).

Pas de version 1.0 à l'horizon, pas du tout de numéro de version en fait. L'auteur préfère avoir une branche master stable grâce à de nombreux tests (171 à ce jour) et une intégration continue (voir Begin versioning/releasing kakoune?).

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 02.11.2015
Fim 1.1.0

Fim (File Integrity Manager) est un gestionnaire de fichiers libre (licence GPLv3) qui permet de gérer beaucoup de fichiers de n'importe quelle taille. Il peut par exemple, gérer des photos ou des vidéos. Il est capable de gérer des centaines de milliers de fichiers occupant une taille totale de plusieurs téraoctets. Il peut détecter les fichiers dupliqués et aider à les effacer.

Logo de Fim

Les nouveautés de la version 1.1.0 :

  • réécriture de l'algorithme de hachage pour hacher un bloc au début, un au milieu et un à la fin (détails ici) ;
  • détection de corruption due au matériel ou de bug du système de fichiers (détails ici) ;
  • sauvegarde et restauration des permissions des fichiers, utilisation des labels SELinux si disponibles (détails ici) ;
  • prise en compte des fichiers .fimignore pour ignorer des fichiers ou des répertoires (détails ici).

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 28.10.2015
Atelier CLI de la semaine 45/2015 à Bordeaux

Les ateliers CLI (Command Line Interface) permettent de progresser en ligne de commande au sein d'un groupe, autour d'un outil ou d'un thème.

Au cours de l'atelier CLIdu mardi 03 novembre, j'ouvrirais le premier atelier consacré aux contrôles d'accès dont le sujet sera les permissions Unix traditionnelles, abrèv. TUP. Lieu : Le Node 12 rue des Faussets 33000 Bordeaux.

L'atelier CLI suivant, fixé au mardi 10 novembre, sera ouvert à la pratique à l'aide d'exemples concrets. Lieu : Labx, à la Cité numérique, 2 rue Marc Sangnier 33130 Bègles.

Les ateliers CLI ont lieu :

  • débutant : animé par Stéphane Ortega, le lundi de 19h00 à 20h30;
  • avancé : animé par un professionnel ou un expert, le mardi de 20h00 à 22h00.

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 26.10.2015
Katal, catalogue de fichiers

Katal est un projet GPLv3/Python3/CLI/Linux-Windows : il permet de créer un catalogue de fichiers à partir de différentes sources, en filtrant les fichiers à récupérer, en les renommant à la volée; on peut alors étiqueter les fichiers obtenus.

Le répertoire de destination contient les fichiers du catalogue, une base de données, un dossier .trash et un dossier pour les logs. J'ai l'habitude de placer dans le répertoire de destination le script katal.py; ainsi, je déplace le catalogue en même temps que l'outil qui me permet de le gérer.

De l'aide est disponible dans le fichier README.md : voyez ici.
Voyez aussi le résultat de $ katal -h .

Sommaire

L'histoire

Un copain m'avait demandé de l'aider à classer des dizaines de milliers de photos tirées de milliers de répertoires différents, mélangées avec toutes sortes de fichiers (textes, vidéos); beaucoup de photos identiques portaient des noms différents.

Je voulais obtenir un catalogue des fichiers :

  1. qui avaient l'extension de fichiers image (.jpg, .tiff, …) ;
  2. qui avaient une taille supérieure à 2 Mo pour éliminer les vignettes ;
  3. sans doublon (=aucun fichier ayant le même contenu qu'un autre) ;
  4. avec la possibilité d'étiqueter (=avec des tags) les images ;
  5. avec la possibilité de renommer les fichiers ;
  6. avec des fichiers de logs verbeux pour garder la trace de mes essais et de mes erreurs ;
  7. le tout sur Linux/Mac/Windows puisque je passais d'un ordinateur à l'autre.

Installation

$ pip install katal

katal est en effet hébergé sur Pypi.

mais aussi :

$ wget https://raw.githubusercontent.com/suizokukan/katal/master/katal/katal.py

… puisque le projet Katal tient en un seul fichier, katal.py, qui peut être placé dans le répertoire de destination.

Utilisation

Créer le répertoire de destination, qui contiendra les fichiers du catalogue :

$ katal --new=destdir

… et accepter de télécharger le fichier de configuration par défaut qui sera placé dans le répertoire de destination (dans un sous répertoire nommé .katal)

Placez-vous ensuite à l'intérieur du répertoire de destination.

$ cd destdir

Vous pouvez voir ce que pense Katal de ce répertoire en tapant :

$ katal --infos

À l'intérieur du répertoire de destination, modifier le fichier de configuration ./katal/katal.ini :

Changer la source, par exemple :

[source]
path : ~/masource/photos/

Katal recherchera de manière récursive dans ce répertoire.

Changer le nom des fichiers qui seront copiés dans le répertoire de destination, par exemple :

[target]
name of the target files : INTTIMESTAMP_SIZE__DATABASE_INDEX.SOURCE_EXTENSION2

… pour avoir des fichiers du type 1445584562_123__1.jpg (=timestamp du fichier source, taille du fichier source, index dans la base de données du répertoire de destination)

Changer la fonction d'évaluation permettant de faire le tri entre les fichiers de la source, par exemple :

… si vous voulez les fichiers python du répertoire source :
[source]
eval : sieve1
[source.sieve1]
name : .*\.py$
… si vous voulez les fichiers python du répertoire source faisant plus d'un mégaoctet :
[source]
eval : sieve1
[source.sieve1]
name : .*\.py$
size : >1000000
… si vous voulez les fichiers python du répertoire source faisant plus d'un mégaoctet OU les .jpg :
[source]
eval : sieve1 or sieve2
[source.sieve1]
name : .*\.py$
size : >1000000
[source.sieve2]
name : .*\.jpg$

Tester le fichier de configuration ./katal/katal.ini :

$ katal --select

Katal vous montre alors ce qui se passerait si vous acceptiez la copie de la source vers la destination. Par exemple :

  +  selected /home/suizokukan/projets/dysodos/dysodos.py (file selected #1)
  -  discarded "/home/suizokukan/projets/dysodos/.git/description" : incompatibility with the sieves
  -  discarded "/home/suizokukan/projets/dysodos/.git/info/exclude" : incompatibility with the sieves
[...]
  o  everything ok : no anomaly detected. See details above.
  o size of the selected file(s) : 3877 bytes
  o number of selected files (after discarding 36 file(s)) : 1, 2.70% of the source files.
  o required space : 3877 bytes; available space on disk : ~35.62 Go (35619852288 bytes) (ok)
  o e.g. … "/home/suizokukan/projets/dysodos/dysodos.py" would be copied as "/home/suizokukan/projets/katal/target2/5474c904__0.py" .
  Do you want to add the selected files to the target dictionary (".") ? (y/N) 

Si vous êtes d'accord, répondez oui en tapant 'y' + entrée :

    … (1/1) copying "/home/suizokukan/projets/dysodos/dysodos.py" to "/home/suizokukan/projets/katal/target2/5474c904__0.py" .
    = all files have been copied, let's update the database… =
    = … database updated =

Katal affiche automatiquement le contenu du catalogue (ici, un seul fichier) :

   = informations about the "." (path: "/home/suizokukan/projets/katal/target2") target directory =
+--------------------+--------------------+------+--------------------+------------------+
| hashid/base64      | name               | tags | source name        | source date      |
+--------------------+--------------------+------+--------------------+------------------+
| […]f8SfE3Tzc+UP0s= | […]/5474c904__0.py |      | […]odos/dysodos.py | 2014-11-25 19:23 |
+--------------------+--------------------+------+--------------------+------------------+

Vous pouvez à tout moment afficher ces informations sur le catalogue à l'aide de l'option -ti :

$ katal -ti

(ti : target informations)

=======================================================
=== Katal v.0.1.3 (launched at 2015-10-25 17:19:06) ===
=======================================================
  = target directory given as parameter : "." (path : "/home/suizokukan/projets/katal/target2")
  = no config file specified on the command line : let's search a config file in the current directory…
  * config file name : "/home/suizokukan/projets/katal/target2/.katal/katal.ini" (path : "/home/suizokukan/projets/katal/target2/.katal/katal.ini")
    … config file found and read (ok)
  = source directory : "~/projets/dysodos" (path : "/home/suizokukan/projets/dysodos")
  = informations about the "." (path: "/home/suizokukan/projets/katal/target2") target directory =
+--------------------+--------------------+------+--------------------+------------------+
| hashid/base64      | name               | tags | source name        | source date      |
+--------------------+--------------------+------+--------------------+------------------+
| […]f8SfE3Tzc+UP0s= | […]/5474c904__0.py |      | […]odos/dysodos.py | 2014-11-25 19:23 |
+--------------------+--------------------+------+--------------------+------------------+
=== exit (stopped at 2015-10-25 17:19; total duration time : 0:00:00.004414) ===

Vous pouvez enfin étiqueter un ou plusieurs fichiers :

Si vous voulez ajouter le tag "mytag" aux fichiers Python :

$ katal --addtag=mytag --to=*.py

Si vous voulez ajouter le tag "mytag" à un seul fichier :

$ katal --addtag=mytag --to=5474c904__0.py

Vous pouvez aussi :

  • supprimer toutes les étiquettes d'un ou plusieurs fichiers (--rmnotags) ;
  • supprimer un fichier ou plusieurs fichiers du catalogue (--targetkill) ;
  • supprimer les fichiers qui n'ont pas de tags (--rmnotags) ;
  • supprimer de la base de données les fichiers qui n'existent pas dans le répertoire de destination (--cleandbrm).

Et d'autres choses encore, accessibles dans le fichier README.md ou en consultant le résultat de $ katal -h .

Et la suite ?

J'ai essayé d'écrire du code lisible par tous : pylint à 10, documentation abondante, commentaires et documentation en anglais…
Je serais ravi de vos commentaires et de vos suggestions d'amélioration !

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 08.10.2015
Atelier CLI de la semaine 41/2015 à Bordeaux

Les ateliers CLI (Command Line Interface) permettent de progresser en ligne de commande au sein d'un groupe, autour d'un outil ou d'un thème.

L'atelier CLI du 13/10/2015 sera consacrée au langage Python, Alexandre Devert en présentera une introduction.

L'atelier suivant, fixé au mardi 20 octobre, sera ouvert à la pratique à l'aide d'exemples concrets.

Alexandre Devert est chercheur, ou plutôt « fouilleur de données » comme il aime à se décrire. Il écrit de nombreux scripts dans le langage Python afin d'explorer des résultats d'expériences.

Il est l'auteur du livre « matplotlib Plotting Cookbook », aux éditions Packt Publishing. matplotlib est une bibliothèque graphique 2D implémentée en Python.

Les ateliers CLI ont lieu :

  • pour le niveau débutant : animé par Stéphane Ortega, le lundi de 19h00 à 20h30 ;
  • pour le niveau avancé : animé par un professionnel ou un expert, le mardi de 20h00 à 22h00.

Ils se dérouleront dans les locaux du Labx, à la Cité numérique, 2 rue Marc Sangnier 33130 Bègles.

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 08.09.2015
Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers

Fim (File Integrity Manager) est un gestionnaire de fichiers libre (licence GPLv3) qui permet de gérer beaucoup de fichiers de n'importe quelle taille. Il peut par exemple, gérer des photos ou des vidéos. Il est capable de gérer des centaines de milliers de fichiers occupant une taille totale de plusieurs téraoctets. Il peut détecter les fichiers dupliqués et aider à les effacer.

Fim

Fim est un outil ligne de commande qui permet de gérer les fichiers avec un esprit qui ressemble à Git.
Il est différent de Git car il ne conserve pas le contenu des différentes versions des fichiers.
Vous ne pouvez pas utiliser Fim pour retrouver un contenu que vous auriez perdu.

Fim conserve dans le répertoire .fim un état de chaque fichier dans des index qui contiennent :

  • Le nom, la taille et la date de modification du fichier
  • 3 hash du contenu (hash du contenu complet, hash du deuxième bloc de 1 MB, hash du deuxième bloc de 4 KB)

Les deux hash supplémentaires qui sont calculés sont utilisés lors des comparaisons rapides.

Voici les commandes disponibles dans Fim:

  • init : initialise le répertoire .fim et crée le premier index contenant l'état des fichiers,
  • ci ou commit : crée un nouvel index contenant l'état actuel des fichiers,
  • diff : permet de savoir quel fichier a été ajouté, modifié, effacé, déplacé, renommé, dupliqué. On peut avoir un résultat rapide en utilisant les options -m ou -k ou -f ,
  • log : affiche l'historique des différents index et un résumé des modifications qui ont été apportées,
  • fdup ou find-duplicates : affiche la liste des fichiers dupliqués.

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 08.09.2015
Atelier CLI de la semaine 37/2015 à Bordeaux

Les ateliers CLI (Command Line Interface) permettent de progresser en ligne de commande au sein d'un groupe, autour d'un outil ou d'un thème.

Pour cette rentrée, au cours de l'atelier CLI du 15/09/2015, Jean-Maxime Philippeaux présentera le générateur de site Web statique Hugo.

Les ateliers CLI ont lieu :

  • chaque mardi de 20h00 à 22h00 pour les utilisateurs avancés;
  • un mercredi sur deux de 19h00 à 20h30 pour les utilisateurs débutants.

à la Fabrique Pola, rue Marc Sangnier 33130 Bègles.

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 28.04.2015
Atelier CLI de la semaine 22/2015 à Bordeaux

Les ateliers CLI (Command Line Interface) permettent de progresser en ligne de commande au sein d'un groupe, autour d'un outil ou d'un thème.

Au cours de l'atelier du 28/04/2015, on pourra découvrir ou redécouvrir
rsync, une commande dédiée à la synchronisation à distance, autrement dit la sauvegarde de données.

Les ateliers CLI ont lieu :

  • chaque mardi de 20h00 à 22h00 pour les utilisateurs avancés,
  • un mercredi sur deux de 19h00 à 21h00 pour les utilisateurs débutants,

dans les locaux du Labx, à la Fabrique Pola, rue Marc Sangnier 33130 Bègles.

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 21.04.2015
Un point d'avancement sur Neovim

Le logo de Neovim

Neovim est un éditeur de texte, issu d'un fork de Vim. Il vise à le rendre plus moderne. En particulier, faciliter le développement et l'utilisation de greffons, et permettre de l'intégrer plus facilement dans d'autres outils.

Le fork date d'un peu plus d'un an et le travail commence à payer. En plus d'un gros nettoyage de la base de code, les développeurs de Neovim ont mis en place un système de plugins, de greffons, qui peuvent désormais tourner à l'extérieur du processus principal et communiquer avec lui via msgpack. On peut également apprécier la possibilité de lancer un terminal à l'intérieur de Neovim, grâce à l'inclusion récente de la libvterm.

Mais pour accélérer le développement, Neovim a besoin de vous. Le développeur principal, @tarruda passe une partie de son temps sur Neovim et une autre partie à faire des missions en freelance pour gagner sa vie. Grâce à des dons, il pourrait diminuer le temps passé sur les missions, et ainsi passer plus de temps à faire vivre Neovim.

Personnellement, je suis un utilisateur comblé de Neovim depuis quelques mois. Bien que celui-ci soit toujours en version alpha, il est très stable et le passage de Vim à Neovim s'est fait sans aucun souci. Aussi, j'ai participé à l'appel à dons et vous encourage à faire de même pour promouvoir ce projet qui le mérite bien !

Commentaires : voir le flux atom ouvrir dans le navigateur

 


 

Publié le 25.04.2016
Atelier CLI : TDD en Bash, mardi 14 avril 2015 ⌚ 20h ⌘ Bordeaux

Les ateliers CLI (Command Line Interface) permettent de progresser en ligne de commande au sein d'un groupe, autour d'un outil ou d'un thème.

Au cours de l'atelier du mardi 14 avril 2015, vous pourrez découvrir shebang_unit, un framework de test automatisés pour Bash 4 basé sur xUnit, développé et présenté par Michael Borde.

L'atelier se tiendra dans les locaux du Labx, à la Fabrique Pola, rue Marc Sangnier 33130 Bègles.

Les ateliers CLI ont lieu dans les locaux du Labx, à la Fabrique Pola, rue Marc Sangnier 33130 Bègles.

  • chaque mardi de 20h00 à 22h00 pour les utilisateurs avancés,
  • un mercredi sur deux de 19h00 à 21h00 pour les utilisateurs débutants,

    Commentaires : voir le flux atom ouvrir dans le navigateur

     


     

    Publié le 25.04.2016
    Atelier CLI le 31 mars 2015 à Bordeaux

    Les ateliers CLI (Command Line Interface) permettent de progresser en ligne de commande au sein d'un groupe, autour d'un outil ou d'un thème. Au cours de l'atelier du 31 mars 2015, vous pourrez découvrir ou redécouvrir Mutt, un client mail orienté terminal : présentation, configuration et utilisation.

    L'atelier se tiendra dans les locaux du Labx, à la Fabrique Pola, rue Marc Sangnier 33130 Bègles.

    Les ateliers CLI ont lieu dans les locaux du Labx, à la Fabrique Pola, rue Marc Sangnier 33130 Bègles.

    • chaque mardi de 20h00 à 22h00 pour les utilisateurs avancés,
    • un mercredi sur deux de 19h00 à 21h00 pour les utilisateurs débutants,

    Commentaires : voir le flux atom ouvrir dans le navigateur

     


     

    Publié le 13.03.2015
    Programme des ateliers CLI pour la semaine 12 à Bordeaux

    Les ateliers CLI (Command Line Interface) permettent de progresser en ligne de commande au sein d'un groupe, autour d'un outil ou d'un thème.

    Le mardi 17 mars, l'atelier avancé portera sur la syntaxe Markdown et la publication d'articles avec le moteur de pages Web statiques Hugo.

    Les ateliers CLI ont lieu :

    • chaque mardi de 20h00 à 22h00 pour les utilisateurs avancés;
    • un mercredi sur deux de 19h00 à 21h00 pour les utilisateurs débutants;

    dans les locaux du Labx, à la Fabrique Pola, rue Marc Sangnier 33130 Bègles.

    Commentaires : voir le flux atom ouvrir dans le navigateur

     


     

    Publié le 09.03.2015
    Atelier CLI les 10 et 11 mars 2015 à Bègles

    Les ateliers CLI (Command Line Interface) permettent de progresser en ligne de commande au sein d'un groupe, autour d'un outil ou d'un thème.

    Au cours de l'atelier du 11 mars 2015, les débutants découvriront comment visualiser des images avec ImageMagick : visualiser une seule image, plusieurs images, puis une mosaïque d'images.

    Au cours de l'atelier du 10 mars 2015, les utilisateurs plus avancés feront un point à propos des outils des ateliers CLI.

    Les ateliers CLI ont lieu :

    • chaque mardi de 20h00 à 22h00 pour les utilisateurs avancés,
    • un mercredi sur deux de 19h00 à 21h00 pour les utilisateurs débutants,

    dans les locaux du Labx, à la Fabrique Pola, rue Marc Sangnier 33130 Bègles.

    Commentaires : voir le flux atom ouvrir dans le navigateur

     


     

    Publié le 02.03.2015
    Atelier CLI le mardi 03 mars 2015 à Bègles

    Le 3 mars 2015, l'atelier CLI (Command Line Interface) aura pour thème la configuration et sécurisation d'un serveur SSH.

    Les ateliers CLI ont lieu dans les locaux du Labx (à la Fabrique Pola, rue Marc Sangnier 33130 Bègles) :

    • un mercredi sur deux de 19h00 à 20h00 pour les utilisateurs débutants
    • chaque mardi de 20h00 à 22h00 pour les utilisateurs avancés,

    Les ateliers CLI permettent de progresser en ligne de commande au sein d'un groupe, autour d'un outil ou d'un thème.

    Commentaires : voir le flux atom ouvrir dans le navigateur

     


     

    Publié le 14.11.2014
    Liquid Prompt 1.9

    Le Liquid Prompt est un prompt fluide affichant de manière limpide des informations utiles là où vous les verrez : le prompt de votre shell bash ou zsh. Le liquidprompt était déjà bien rempli de fonctionnalités, mais celles-ci ont été stabilisées et leurs performances améliorées durant les mois écoulés. Il était temps de sortir une nouvelle version officiellement stable.

    Pour les détails de cette version surtout composée de correctifs (indicateurs de batterie, température, charge processeur, nom de machine, gestion de code source, chemin, prompt, horloge, etc.) ; les curieux sont invités à consulter le fichier CHANGES : Battery indicator, Temperature indicator, CPU load, Hostname, VCS (Git, Fossil, Subversion, Bazar, Mercurial), Analog clock, etc.

    Je profite de cette dépêche pour remercier chaudement les 15 contributeurs qui par leurs patchs ont contribué à cette version : Anthony Gelibert, Frédéric Mahé, Panayiotis Kkolos, Étienne Deparis, François Schmidts, Linus Wallgren, Alexander Belaev, Bartosz Janda, Brett McBride, Chase Colman, Cosmin L. Neagu, Matthew Micene, Vincent Lara, Wilson Maravilha et Yannack. Mais aussi tous ceux qui ont signalés des bogues ou proposé des patchs refusés ou en attente.

    Copie d'écran de Liquid Prompt

    Commentaires : voir le flux atom ouvrir dans le navigateur

     


     

    Publié le 31.10.2014
    Préparation de documents LaTeX avec BSD Owl

    À l'occasion de la sortie de BSD Owl 2.2.1 — le système de compilation portable pour BSD Make — je vous propose d'apprendre à utiliser BSD Owl pour préparer et publier vos documents LaTeX.

    Ce texte est une traduction de la page du Wiki “Producing LaTeX documents”.

    Sommaire

    Préparer des documents avec LaTeX

    Vous apprendrez dans ce texte comment utiliser les scripts BSD owl (bsdowl) pour :

    • préparer des documents simples et les publier dans l'arborescence des fichiers;
    • préparer la bibliographie de vos documents LaTeX avec BIBTeX;
    • préparer des figures pour vos documents avec METAPOST;
    • gérer des documents dont certains éléments doivent être automatiquement régénérés;
    • gérer des documents dispersés dans différents répertoires.
    • gérer des collections comportant un grand nombre de documents.

    Avertissement: travailler avec TeX ou LaTeX

    Il y a de nombreux formats TeX, plain TeX et LaTeX en sont deux exemples. Le format LaTeX jouit d'une grande popularité et nous avons choisi d'utiliser le module latex.doc.mk dans les exemples. Cependant, ce qui suit s'applique aussi au module tex.doc.mk. Certains paragraphes dans la suite identifient les mécanismes spécifiques à latex.doc.mk.

    Avertissement: BSD Make

    Ne vous trompez pas de version de make : la plupart des distributions Linux installent GNU Make comme programme make principal, la version BSD de make est souvent appelée bmake et installable via un paquet du même nom. Sous les BSD, on trouve naturellement BSD Make comme commande make. Sous Mac OS X, c'est le programme bsdmake.

    Utilisation simple

    La préparation d'un document simple avec LaTeX est en elle-même particulièrement simple, l'utilisation de bsdowl pourrait donc sembler une complication inutile. Cependant, même dans ce cas, l'utilisation de bsdowl rend d'appréciables services, comme l'installation et l'horodatage des fichiers produits.

    Néanmoins, la partie vraiment intéressante se situe dans la partie avancée.

    La première fois

    Supposons que le fichier script.tex contient notre texte et mettons-le dans un répertoire dédié. Créons un fichier Makefile (la majuscule compte) qui contient :

    DOC = script.tex
    .include "latex.doc.mk"

    de sorte que le répertoire dédié contient maintenant script.tex et ce Makefile. Rendons-nous avec un shell dans ce répertoire et tapons make:

    % make
    make build
    ===> Multipass job for script.dvi (aux)
    latex script.tex
    This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
    entering extended mode
    (./script.tex
    LaTeX2e <2003/12/01>
    ...

    S'il n'y avait pas d'erreur dans script.tex, on se retrouve avec les fichiers "compilés" suivants dans le répertoire courant :

    % ls
    Makefile    script.log
    script.aux  script.tex
    script.dvi  script.toc

    Lorsque les produits de compilation ne sont plus nécessaires, vous pouvez nettoyer le dossier de travail avec le mantra make clean:

    % make clean
    rm -f  script.dvi script.log script.aux script.toc

    Le nettoyage du dossier de travail est une étape optionnelle qui évite de voir son dossier personnel rempli de données inutiles, qui peuvent rapidement être recréées. Les fichiers DVI sont habituellement très petits, de l'ordre de quelques centaines de kilobits, mais les fichiers PostScript ou PDF sont habituellement bien plus gros.

    Installation ou publication

    Avant de nettoyer votre dossier de travail avec le mantra make clean, vous pouvez vouloir copier ce document à un emplacement approprié du système de fichiers. Cette étape s'appelle installation du document, car elle est analogue à l'installation d'un programme nouvellement compilé. Vous installez le document grâce à la commande make install mais il faut auparavant dire à make quel emplacement du système de fichiers est approprié. Il faut pour cela assigner à la variable DOCUMENTDIR le chemin du dossier où vous voulez que vos fichiers soient copiés, comme l'illustre le Makefile suivant :

    DOCUMENTDIR = ${HOME}/doc/report
    DOC = script.tex
    .include "latex.doc.mk"

    Vous pouvez alors passer à la commande make install:

    % make install
    install -d /home/michi/doc/report
    install -o michi -g michi -m 440 script.dvi /home/michi/doc/report

    En comparaison avec la copie manuelle du document produit, vous vous épargnez la saisie récurrente du dossier de destination après chaque mise à jour du document. Mais confier cette tâche élémentaire au Makefile a d'autres avantages plus importants :

    • Cela simplifie l'organisation de votre bibliothèque de sources pour vos documents.
    • Cette stratégie s'adapte à une collection importante de documents, cf. Travailler avec une collection de documents plus bas.
    • En mode brouillon, un suffixe horodatant le fichier est automatiquement ajouté, comme expliqué plus bas.

    Choix du format de sortie

    La chaîne de production TeX est capable de produire des documents électroniques dans plusieurs formats, comme DVI, PostScript (PS) ou PDF. La variable TEXDEVICE commande le choix du format de sortie des documents préparés avec latex.doc.mk. Cette valeur est généralement dvi de sorte qu'un fichier DVI sera préparé à partir du document source. D'autres valeurs possibles sont ps ou pdf. Si vous avez configuré une imprimante PostScript avec texconfig(1), disons TEXPRINTER, vous pouvez utiliser ps.TEXPRINTER comme valeur de TEXDEVICE ce qui indique à dvips d'utiliser les réglages pour TEXPRINTER dans la traduction de DVI vers PostScript. Il est enfin possible d'assigner une liste de formats de sortie à TEXDEVICE.

    Brouillons et traitements multiples

    Certains formats — dont LaTeX — et certaines macros exigent de votre manuscrit qu'il soit traité plusieurs fois par TeX ou LaTeX avant que vous n'obteniez la version finale. Le module latex.tex.mk impose un traitement à multiples passes de votre manuscrit, car LaTeX s'appuie sur ce mécanisme pour produire les références croisées associées aux commandes label ou ref de votre manuscrit. Le module doc.tex.mk ne procède pas à un traitement multiple.

    Dans les premiers jets d'un document, les modifications sont probablement fréquentes ; il est donc souhaitable d'éviter de longs traitements multiples. bsdowl a un mode brouillon, activé en assignant la valeur yes à la variable DRAFT de make. Ceci peut être fait en ajoutant la commande suivante dans le Makefile:

    DRAFT?= yes
    DOC = script.tex
    .include "latex.doc.mk"

    La commande DRAFT?= est une forme faible de l'assignement qui permet d'invoquer make DRAFT=no pour rétablir le traitement à plusieurs passes pour une unique invocation de make, sans modifier le Makefile.

    Lorsque les derniers ajustements ont été faits au manuscrit, vous pouvez supprimer la commande manipulant DRAFT et votre texte est prêt pour une dernière exécution de make produisant la version finale de votre document. Si vous en êtes satisfait, vous pouvez l'installer.

    Pendant la mise au point d'un document, il est utile de garder des copies des documents produits à certaines étapes de votre travail. Imaginez envoyer un exemplaire préliminaire de votre travail à un ami qui le lira attentivement et vous fera part de ses commentaires. Pendant ce temps, vous continuez de travailler sur votre texte, si bien que lorsque vous recevrez ses commentaires, votre document aura évolué. Pour pouvoir comparer les commentaires de votre ami à la version de votre document que vous lui avez envoyé, la meilleure manière de résoudre ce problème est probablement d'utiliser un outil de gestion des versions — un logiciel gardant note des différentes révisions d'un fichier. Si vous n'utilisez pas un tel système et désirez en essayer un, vous pourriez être intéressé par GIT, tout particulièrement si vous utilisez les courriels pour organiser votre collaboration.

    Lorsque la variable DRAFT est positionnée à yes et la variable TEXDRAFTSTAMP n'est pas initialisée, elle reçoit la valeur -${TEXDRAFTTIMESTAMP} où le texte de remplacement de TEXDRAFTTIMESTAMP est la date à laquelle la commande make est appelée. Lorsque la variable TEXDRAFTSTAMP est initialisée et n'est pas vide, son texte de remplacement est ajouté à la fin de tous les documents installés par latex.doc.mk ou tex.doc.mk. Si vous ne souhaitez pas que le nom soit modifié, tout en utilisant le mode brouillon, il suffit d'affecter un texte vide à TEXDRAFTSTAMP.

    Un document dans plusieurs fichiers

    Si vous travaillez sur un document complexe, vous aurez certainement découpé votre manuscrit en plusieurs fichiers ; typiquement, un fichier par chapitre ou par section plus un fichier principal contenant le préambule et de multiples commandes input demandant à LaTeX de lire tous les fichiers représentant le véritable contenu du document.

    Supposons donc que votre document est découpé entre un fichier principal galley.tex et deux fichiers part1.tex et part2.tex. Votre galley.tex ressemble probablement à ceci :

    \documentclass{article}
    \begin{document}
    \input{part1}
    \input{part2}
    \end{document}

    Le Makefile correspondant est alors :

    DOC = galley.tex
    SRCS = part1.tex
    SRCS+= part2.tex
    .include "latex.doc.mk"

    Fonctions avancées

    Figures avec METAPOST

    Les modules latex.doc.mk et tex.doc.mk prennent en charge
    METAPOST agréablement. C'est un point particulièrement important à relever, car METAPOST est souvent l'outil le mieux adapté pour tracer des figures destinées à l'inclusion dans un document TeX. Cependant, il n'est que rarement pris en charge de façon adéquate par les interfaces graphiques LaTeX.

    Ces modules font l'hypothèse que votre code METAPOST contient les lignes :

    prologues := 3;
    outputtemplate := "%j-%c.mps";
    

    La première déclaration paramètre l'inclusion des fontes dans le fichier résultat tandis que la seconde change le format des noms utilisés par les produits.

    Supposons donc que vous ayez préparé les illustrations pour votre article avec METAPOST et réparti ces illustrations dans deux fichiers illustr1.mp et illustr2,mp. Pour indiquer à latex.doc.mk qu'il doit les utiliser pour produire leurs figures, définissez la variable FIGS dans votre Makefile:

    DOC = galley.tex
    SRCS = part1.tex
    SRCS+= part2.tex
    FIGS = illustr1.mp
    FIGS+= illustr2.mp
    .include "latex.doc.mk"

    Saisissez donc make à l'invite de commande. Le module latex.doc.mk analysera vos fichiers pour savoir quelles illustrations sont définies dans vos fichiers et produira les fichiers nécessaires à votre TEXDEVICE. Par exemple, si votre TEXDEVICE est dvi et que illustr1.mp contient la description de deux figures définies par beginfig(1) et beginfig(2), alors vous obtiendrez quatre fichiers :

    % ls *.mps
    illustr1-1.mps
    illustr1-2.mps
    illustr1-1.eps
    illustr1-2.eps

    Les deux premiers fichiers sont la sortie de METAPOST, des données intermédiaires dans un format PostScript spécifique. Les deux derniers sont en Encapsulated PostScript et adaptés à l'inclusion dans votre document.

    En utilisant le paquet graphicx, l'inclusion d'image est aussi simple que possible :

    \includegraphics{illustr1-1}%

    Découvrez METAPOST. Il semblerait que de nombreuses personnes ne connaissent pas METAPOST. Si c'est votre cas mais que vous êtes intéressé par la découverte de cet outil merveilleux, la première bonne nouvelle est qu'il fait partie de la plupart — sinon de toutes — les installations de TeX, il est donc probablement déjà installé sur votre système.

    La seconde bonne nouvelle est que de nombreuses informations peuvent être trouvées à son sujet sur le Web. Par exemple le TeX users group a une page dédiée à cet outil. La liste qui s'y trouve est particulièrement longue, j'ajouterai donc que j'ai lu et apprécié l'introduction de André Heck, elle est peut-être un bon point de départ pour vous !

    Enfin n'oubliez pas d'essayer mon projet Metapost blueprint pour produire de splendides graphiques pour accompagner vos projets.

    Bibliographie

    bsdowl peut vous aider à préparer des bibliographies avec BibTeX. Tout d'abord vous devez vous assurer que TeX trouvera les base de données bibliographiques que vous avez énumérées dans vos commandes bibliography. Il est habituel de regrouper ses bases de données bibliographiques dans un dossier, par exemple ${HOME}/share/bib. Pour permettre à bibtex de trouver ses fichiers, il suffit d'ajouter le chemin ${HOME}/share/bib au contenu de la variable BIBINPUTS. Si votre base de données bibliographiques est dispersée dans plusieurs dossiers, vous n'avez qu'à mentionner chacun d'eux dans BIBINPUTS :

    DOC = galley.tex
    SRCS = part1.tex
    SRCS+= part2.tex
    BIBINPUTS = ${HOME}/share/bib
    BIBINPUTS+= ../morebib
    .include "latex.doc.mk"

    Notez que le mantra make clean laissera intacts les fichiers BBL produits par bibtex. Les éditeurs demandent parfois de leur envoyer ces fichiers, ainsi, la commande make clean ou make distclean placera votre dossier de travail dans un état où vous pourrez facilement le redistribuer. Pour vous débarrasser des fichiers BBL, vous devez vous en remettre au puissant mantra make realclean.

    Plusieurs documents dans le même dossier

    Bien qu'il soit souvent une bonne idée de réserver un dossier à chaque document, vous pouvez avoir des raisons de vouloir travailler avec plusieurs documents dans le même dossier. Vous avez vos raisons et elles sont probablement excellentes, et bsdowl fera donc de son mieux pour vous aider.

    Supposons que vous ayez deux documents dont les sources se trouvent dans le même dossier, disons un article et une version abrégée de cet article. Ces deux documents ont en commun un fichier macro.tex, mais sont à part cela relativement indépendants du point de vue de LaTeX. Le texte de l'article est divisé dans deux fichiers section1.tex et section2.tex. Le résumé a un seul fichier summary.tex. Le Makefile correspondant ressemble à ceci :

    DOC = article.tex
    DOC+= summary.tex
    
    SRCS = macros.tex
    
    SRCS.article.tex = section1.tex
    SRCS.article.tex+= section2.tex
    
    .include "latex.doc.mk"

    Génération automatique d'une portion de document

    Supposons que vous travailliez sur un document contenant une table dont le contenu changera vraisemblablement plusieurs fois et devra donc être mis à jour. Une telle table pourrait être un budget : lorsque notre situation évolue, ainsi en va-t-il de notre budget. Il peut être assez délicat de saisir une table en LaTeX, la mettre à jour est encore plus vachard. Dans cette situation, on peut écrire et utiliser à profit un petit programme lisant les données brutes de notre budget et écrivant pour nous le code LaTeX de la table correspondante, contenant cette information brute et les données que nous pouvons en dériver. Écrire un tel programme est très facile, car on a seulement besoin de savoir travailler avec des fichiers texte.

    Ainsi, vous avez rassemblé vos données brutes pour votre table dans le fichier table.raw et écrit un petit programme gentable qui écrit pour vous la table LaTeX sur sa sortie standard. Dans votre manuscrit, vous utilisez le nom table pour inclure le contenu de la table. Voici votre Makefile:

    DOC = galley.tex
    
    table.tex: gentable table.raw
        ./gentable < table.raw > table.tex
    
    REALCLEANFILES+= table.tex
    
    .include "latex.doc.mk"

    Cet exemple suppose que le programme gentable est un filtre, de sorte que l'entrée et la sortie sont effectuées par des redirections. D'autres programmes peuvent utiliser une convention différente pour définir la sortie et l'entrée.

    Si vous envoyez vos fichiers à quelqu'un, cette personne ne voudra probablement pas exécuter votre programme gentable . Il semble donc préférable d'ajouter le nom du produit table.tex à REALCLEANFILES plutôt qu'à CLEANFILES : vous pouvez ainsi nettoyer votre dossier de travail avec make clean et faire une archive du contenu que vous enverrez à un tiers, sans avoir besoin de traiter le fichier table.tex avec une attention particulière.

    Bien sûr, vous pouvez générer un code source pour METAPOST, typographier un fragment de code ou bien encore autre chose, au lieu de générer une table !

    Code source réparti dans plusieurs répertoires

    Certaines méthodes de travail requièrent que vos fichiers source ne soient pas situés dans un répertoire unique mais disséminés dans le système de fichiers.

    Une raison pour travailler ainsi pourrait être que votre organisation utilise pour son courrier une classe de document personnalisée incluant quelques images. Vous ne souhaitez pas copier ces images dans chacun des dossiers utilisant cette classe de document, ni créer des liens symboliques vers ces images : vous souhaitez tout bonnement pouvoir ignorer leur existence ! Une solution à ce problème passe par la variable TEXINPUTS dont le contenu est une liste de dossiers que TeX doit examiner lorsqu'il recherche un fichier.

    Une autre raison motivant la dissémination de fichiers sources dans plusieurs dossiers est la préparation d'un grand document, comme un livre. Si les fichiers de chaque chapitre sont contenus dans un dossier dédié, il est facile de traiter un chapitre isolé avec LaTeX pendant la phase de mise au point du manuscrit. TeX doit donc trouver tous les fichiers nécessaires lorsqu'il traite le fichier principal produisant le livre, ce qui est accompli en positionnant TEXINPUTS à la valeur adéquate, comme expliqué ci-dessous.

    Vous pouvez définir la variable TEXINPUTS dans votre environnement, dans votre Makefile ou bien même écrire une version personalisée de latex.doc.mk définissant cette variable.

    Supposons que l'image représentant visuellement votre organisation soit dans ${HOME}/share/texmf/tex/organisation/visual.eps, afin que TeX examine le dossier contenant cette image, vous écrivez une affectation à TEXINPUTS dans votre Makefile, comme ceci :

    DOC = galley.tex
    TEXINPUTS = ${HOME}/share/texmf/organisation
    .include "latex.doc.mk"

    Exécuter make dans le dossier contenant le Makefile fera apparaître ceci dans votre terminal :

    % make
    make build
    ===> Multipass job for galley.dvi (aux)
    env TEXINPUTS=".:${HOME}/share/texmf/organization:" latex galley.tex
    This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
    ...

    Examinons la liaison associée à TEXINPUTS par la commande env. Elle se distingue notamment de la spécification du Makefile par la présence d'un élément . au début et d'un élément vide à la fin. Ceux-ci indiquent à TeX de rechercher aussi les fichiers dans le dossier courant et dans les dossiers de l'installation TeX.

    Si dans un cas particulier vous souhaitez avoir un contrôle total sur TEXINPUTS, il vous suffit de positionner USE_STRICT_TEXINPUTS à yes dans votre Makefile. S'il trouve ce positionnement, bsdowl n'ajoutera pas le point et l'élément vide à TEXINPUTS.

    La prise en charge de METAPOST tient compte des valeurs de TEXINPUTS ET USE_STRICT_TEXINPUTS. Une variable analogue nommée MPINPUTS et sa compagne USE_STRICT_MPINPUTS permettent de configurer le chemin de recherche des fichiers par METAPOST.

    Travailler avec des collections contenant un grand nombre de documents

    Nous montrons comment utiliser le module bps.subdir.mk pour organiser une collection de documents. Pour les besoins de cet exemple, nous supposerons que vous préparez un journal électronique et souhaitez distribuer chaque article du journal comme un document individuel. Vous utilisez l'organisation suivante :

    1. Vous avez préparé un répertoire contenant chaque numéro du journal, disons ${HOME}/journal.
    2. Chaque numéro du journal est matérialisé par un sous-répertoire du dossier précédent.
    3. Chaque article du journal est représenté par un sous-répertoire du dossier correspondant au numéro auquel il appartient.

    Supposons que vous avez déjà préparé plusieurs articles, comme le suggère la commande suivante :

    % find ./journal -type f
    ./journal/issue-2013-1/01-galdal/Makefile
    ./journal/issue-2013-1/01-galdal/article.tex
    ./journal/issue-2013-1/02-arathlor/Makefile
    ./journal/issue-2013-1/02-arathlor/article.tex
    ./journal/issue-2013-2/01-mirmilothor/Makefile
    ./journal/issue-2013-2/01-mirmilothor/article.tex
    ./journal/issue-2013-2/02-eoron/Makefile
    ./journal/issue-2013-2/02-eoron/article.tex
    ./journal/issue-2013-2/03-echalad/Makefile
    ./journal/issue-2013-2/03-echalad/article.tex

    Les noms comme galdal, arathlor, etc. sont les noms des auteurs fictifs des articles non moins fictifs de votre journal. Chaque contribution est associée à un répertoire contenant le texte de l'article proprement dit article.tex et un Makefile semblable à ceux décrits plus haut dans cette dépêche et qui est utilisé pour préparer l'article correspondant.

    Chacun de ces Makefile peut être aussi simple que:

    DOC=    article.tex
    .include "latex.doc.mk"

    Pour coordonner la préparation de tous nos articles, il nous suffit d'écrire quelques Makefile supplémentaires :

    ./journal/Makefile
    ./journal/issue-2013-1/Makefile
    ./journal/issue-2013-2/Makefile
    ./journal/issue-2013-3/Makefile
    

    Chaque Makefile contient essentiellement la liste des sous-répertoires que make doit explorer pour atteindre les cibles build, install ou clean. Ainsi le fichier ./journal/Makefile doit contenir :

    SUBDIR=     issue-2013-1
    SUBDIR+=    issue-2013-2
    SUBDIR+=    issue-2013-3
    .include "bps.subdir.mk"

    Quant à lui, ./journal/issue-2013-1/Makefile doit contenir :

    SUBDIR=     01-galdal
    SUBDIR+=    02-arathlor
    .include "bps.subdir.mk"

    Les fichiers restants ./journal/issue-2013-2/Makefile et ./journal/issue-2013-3/Makefile doivent être préparés de façon similaire. Avec ces ajustements, les cibles all, build, clean, distclean, realclean et install sont déléguées aux Makefile trouvés dans les dossiers énumérés par SUBDIR.

    La variable _SUBDIR_PREFIX peut être utilisée pour personnaliser le dossier d'installation pour chaque article. Changeons le Makefile associé à chaque article en :

    DOC=    article.tex
    DOCDIR= ${HOME}/publish/journal${_SUBDIR_PREFIX}
    .include "latex.doc.mk"

    Avec ce réglage, le document ./journal/issue-2013-1/01-galdal/article.dvi sera installé dans ${HOME}/publish/journal/issue-2013-1/01-galdal/article.dvi et ainsi de suite. Il est possible d'ajuster ceci pour utiliser un police de nommage complètement arbitraire pour l'installation des produits.

    Contribuer

    Le but de bsdowl est de fournir un système de déploiement de logiciel portable pour les systèmes UNIX modernes. Il se distingue d'autres approches par l'utilisation de simples fichiers Makefile et d'un programme standard : BSD Make. L'utilisateur de bsdowl écrit donc des fichiers Makefile, il n'est pas utile d'apprendre un énième langage de script pour écrire une spécification de compilation.

    Pour la version 3.0 en préparation, je projette de réorganiser grandement le logiciel. Les projets sont :

    • Mise en avant des notions de module et de produit, pour se rapprocher du schéma d'organisation des projets dans les grands IDE classiques.
    • Concilier le point précédent avec une approche non bureaucratique pour les petits projets.
    • Utiliser de façon systématique un mode de développement axé sur les tests.

    Si vous êtes intéressé(e) par bsdowl vous pouvez :

    • témoigner de votre intérêt en lui ajoutant une petite étoile dans GitHub ;
    • rapporter vos succès et vos infortunes, je suis notamment très intéressé par la préparation d'une liste de compatibilité.
    • contribuer des programmes de type hello-world ou de plus complexes pour m'aider à écrire des tests pour les langages que vous aimeriez voir pris en charge.

    Commentaires : voir le flux atom ouvrir dans le navigateur