momh

De Oh my ZSH à Antidote & Oh My Posh

Brice Boucard — 2026-02-18T19:36:05Z

Un léger ennui, une petite lassitude, une impression de lourdeur... Et me voilà donc à rechercher des alternatives à Oh My Zsh que j'utilisais depuis quelques temps, à la fois pour gérer mes plugins et le thème de prompt que j'utilisais.

Et j'ai donc découvert Antidote https://antidote.sh, un gestionnaire de plugins pour ZSH léger et performant ainsi que Oh My Posh https://ohmyposh.dev.

Antidote

Antidote is a Zsh plugin manager made from the ground up thinking about performance.
It is fast because it can do things concurrently, and generates an ultra-fast static plugin file that you can easily load from your Zsh config.

L'installation peut se faire soit via Git :

git clone --depth=1 https://github.com/mattmc3/antidote.git ${ZDOTDIR:-~}/.antidote

soit via des gestionnaires de paquets, par exemple avec Brew sous MacOS :

brew install antidote

Ensuite, il faut éditer notre ~/.zshrcde la sorte :

# # Lazy-load antidote and generate the static load file only when needed # # Lazy-load antidote and generate the static load file only when needed zsh_plugins=${ZDOTDIR:-$HOME}/.zsh_plugins if [[ ! ${zsh_plugins}.zsh -nt ${zsh_plugins}.txt ]]; then ( source $HOMEBREW_PREFIX/opt/antidote/share/antidote/antidote.zsh antidote bundle <${zsh_plugins}.txt >${zsh_plugins}.zsh ) fi source ${zsh_plugins}.zshfile. source ${zsh_plugins}.zsh

Les plugins sont listés dans le fichier .zsh_plugins.txt, par exemple :

# some plugins support deferred loading zdharma-continuum/fast-syntax-highlighting kind:defer zsh-users/zsh-autosuggestions kind:defer zsh-users/zsh-history-substring-search kind:defer

Il est également possible d'appeler des plugins en provenance de Oh My Zsh :

# # Using Oh My Zsh plugins # getantidote/use-omz # https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/eza ohmyzsh/ohmyzsh path:plugins/eza # https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/fzf ohmyzsh/ohmyzsh path:plugins/fzf

Un coup de source ~/.zshrc et votre terminal devrait donc désormais bénéficier de ces plugins, avec leurs alias respectifs, etc.

Oh My Posh

The most customizable and fastest prompt engine for any shell.

Oh My Posh (https://ohmyposh.dev) permet donc très aisément de configurer son prompt .
Une fois installé, il suffit d'ajouter une ligne à la fin de ~/.zshrc afin de le charger :

eval "$(oh-my-posh init zsh)"

Pour utiliser un thème existant (https://ohmyposh.dev/docs/themes), il suffit de le passer en option à la commande insérée précédemment ; ainsi par exemple :

eval "$(oh-my-posh init zsh --config 'quick-term')"

Bien sûr, il est possible de configurer son propre thème (https://ohmyposh.dev/docs/configuration/general).

SPIPer avec DDEV (bis)

Brice Boucard — 2024-05-21T04:37:58Z

Si nous parvenions dans notre premier article à obtenir un environnement de développement sous SPIP rapidement grâce à DDEV, la méthode proposée aboutit à rendre problématique l'usage de PHP en CLI. La solution, pour ce qui est de SPIP en tout cas : ne plus utiliser le paramètre --docroot.

Installer une version 4.3

On commence par cloner le dépôt de SPIP, puis l'on configure notre environnement DDEV avant d'utiliser la commande checkout pour basculer sur la branche qui nous intéresse :

git clone https://git.spip.net/spip/spip.git spip43 cd spip43 ddev config --project-type=php --php-version=7.4 ddev checkout ddev checkout spip -b4.3 public

Si vous êtes confronté au message suivant :

fatal: detected dubious ownership in repository at '/var/www/html' To add an exception for this directory, call: git config --global --add safe.directory /var/www/html

Il suffit d'exécuter la commande indiquée, au sein du container bien évidemment :

ddev exec git config --global --add safe.directory /var/www/html

Installer la branche `master`

git clone https://git.spip.net/spip/spip.git master cd master ddev config --project-type=php --php-version=8.2 ddev composer install ddev composer local mode-dev rm -rf web/plugins-dist ddev composer local install

SPIPer avec DDEV

Brice Boucard — 2024-03-21T12:26:32Z

DDEV est, pour le dire vite, une surcouche à Docker permettant de mettre en place extrêmement rapidement des environnements de développement Web. Nous allons tenter de décrire ici comment nous l'utilisons pour nos développements avec SPIP.

Je ne vais pas ici décrire l'installation de DDEV, sa documentation se suffisant à elle-même plus que largement.

SPIP-Cli & checkout

Ces outils en ligne de commande que sont checkout (méthode unifiée d'installation et de mise à jour) et SPIP-Cli (installation, mise à jour, manipulation...) m'apparaissent comme indispensables ; un grand merci à nicod donc pour en proposer une intégration à DDEV.

Personnellement, j'ai commencé par cloner le dépôt dans un répertoire ~/sources avant de créer un lien (non symbolique) pour chacun des deux scripts vers le répertoire ~/.ddev/commands/web/ :

Ainsi, pour chacun de nos projets, ces deux commandes seront accessibles une fois le conteneur web lancé (seul bémol, il conviendra de réinstaller les utilitaires à chaque redémarrage, mais les scripts proposés par nicod s'en charge très bien).

Installer SPIP dans un environnement DDEV

Avant d'installer SPIP, il convient de préparer notre environnement de développement : création d'un répertoire, configuration du projet et initialisation :

mkdir mon_site && cd mon_site ddev config --project-type=php --webserver-type=apache-fpm --docroot=web --composer-root=web ddev start

Une fois cela fait, on peut procéder à l'installation de SPIP (sur sa branche master ici) avec SPIP-Cli (il convient de lancer la commande spip une première fois pour procéder à son installation) :

ddev spip ddev spip dl git -b master -d web

Là, on tombe sur ce message, auquel il faut répondre par l'affirmative :

Le répertoire existant web a été renommé en web__OLD. Souhaitez vous le supprimer ? (yes/no) [yes] :

Puis, on peut poursuivre l'installation, comme indiqué dans le README de SPIP, en prenant bien soin de faire précéder certaines commandes de ddev :

ddev composer install ddev composer local mode-dev rm -rf web/plugins-dist ddev composer local install

Enfin, il suffit de procéder à l'installation de SPIP, en utilisant les informations de connexion à la base de données retournées par la commande describe :

ddev describe

Eclipse : bulles contextuelles hors de l'écran

Brice Boucard — 2022-10-12T12:13:35Z

Sous Gnome Shell dans sa version 42, sous Wayland, les bulles contextuelles d'Eclipse affichant la JavaDoc associée aux méthodes suggérées lors de la saisie dépassent de l'écran...

La chose n'est pas extrêmement simple à décrire et les recherches sont de fait relativement délicates à mener... Plutôt qu'un long discours, voici une capture d'écran présentant le souci :

Eclipse sous Wayland

Retrouver un Eclipse utilisable

Je ne saurais expliquer trop précisément mais la solution consiste à lancer Eclipse en utilisant X11 comme backend ; dans un terminal, il suffit de lancer la commande suivante :

export GDK_BACKEND=x11; eclipse

Et vous devriez alors non seulement retrouver vos bulles contextuelles correctement positionnées mais aussi pouvoir utiliser véritablement les fenêtres de création de projet, de génération de constructeurs ou d'accesseurs... puisqu'elles prennent alors toute la hauteur de l'écran et n'en débordent pas. Ce qu'illustrent les deux captures ci-dessous.

Eclipse avec X11 comme backend

Fenêtre de création de projet sous Eclipse

Lanceur

J'avais installé Eclipse via Snap ; pour modifier le lanceur, il convient tout d'abord de copier le lanceur original dans .local/share/applications :

sudo cp /var/lib/snapd/desktop/applications/eclipse_eclipse.desktop ~/.local/share/applications

Et de modifier la ligne Exec de ce nouveau fichier, afin qu'il ressemble au final à ceci :

[Desktop Entry] X-SnapInstanceName=eclipse Version=1.0 Type=Application Name=Eclipse (X11) Icon=/snap/eclipse/61/icon.xpm Exec=env GDK_BACKEND=x11 /snap/bin/eclipse %f Comment=Eclipse IDE Categories=Development;IDE; Terminal=false StartupWMClass=eclipse

Il se peut que vous ayez à fermer et réouvrir votre session pour que le lanceur soit mis à jour.

Installer Microsoft SQL Server sur Ubuntu 22.04

Brice Boucard — 2022-09-23T09:42:49Z

Dans le cadre de ma formation de Concepteur développeur d'application auprès de ENI École, je vais ête amené à étudier le SQL et à le mettre en pratique sous Microsoft SQL Server.

Microsoft fournit un paquet mssql-server pour Ubuntu 20.04 ainsi qu'une documentation bien faite concernant son installation et les premiers pas sous SQL Server. Cependant, l'installation sous Ubuntu 22.04 se heurte à différents soucis...

Signature du dépôt

Pour éviter d'avoir un avertissement concernant l'utilisation de apt-key, il convient de procéder différemment pour importer la clé du dépôt. On commence par télécharger la clé fournie, avant de la convertir et de la conserver dans le répertoire /usr/share/keyrings/ :

wget https://packages.microsoft.com/keys/microsoft.asc gpg --dearmor microsoft.asc mv microsoft.asc.gpg /usr/share/keyrings/microsoft.gpg rm microsoft.asc

Ensuite, la déclaration du dépôt diffère quelque peu ; dans un fichier /etc/apt/sources.list.d/mssql-20_04.list, il convient de lui préciser la clé à utiliser :

deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft-mssql.gpg] https://packages.microsoft.com/ubuntu/20.04/mssql-server-2019 focal main

libldap

Le premier souci provient d'une dépendance à libldap dans sa version 2.4, alors qu'Ubuntu 22.04 ne propose plus que la version 2.5.

La solution est alors de télécharger le paquet d'une version d'Ubuntu précédente depuis le site ubuntu packages puis de l'installer (la commande ci-dessous peut être différente, notamment en cas d'architecture autre que amd64) :

sudo apt install ./Téléchargements/libldap-2.4-2_2.4.49+dfsg-2ubuntu1.9_amd64.deb

Le paquet mssql-server devrait désormais s'installer sans autre problème.

libcrypto.so & libssl.so

Lors de l'installation à proprement parler de SQL Server avec la commande

sudo /opt/mssql/bin/mssql-conf setup

on se heurte à une erreur puisqu'il ne trouve pas ces deux bibliothèques libcrypto.so et libssl.so dans le répertoire /opt/mssql/lib/.

La solution que j'ai retenue dans mon cas, parmi celles proposées sur ce sujet du forum de learn.microsoft.com, est d'utiliser celles fournies par les Snap core20 et de créer des liens symboliques ; dans mon cas :

sudo ln -s /snap/core20/1587/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 libcrypto.so sudo ln -s /snap/core20/1587/usr/lib/x86_64-linux-gnu/libssl.so.1.1 libssl.so

Il suffit de relancer alors l'installation

sudo /opt/mssql/bin/mssql-conf setup

et ce devrait être bon !

Outils en ligne de commande

Microsoft propose deux outils en ligne de commande pour interagir avec SQL Server : sqlcmd et bcp.

Pour les installer, il convient de définir un nouveau dépôt, mettons dans le fichier /etc/apt/sources.list.d/msprod.list :

deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft-mssql.gpg] https://packages.microsoft.com/ubuntu/20.04/prod focal main

Ensuite :

sudo apt update sudo apt install mssql-tools unixodbc-dev

Plutôt que d'ajouter le répertoire /opt/mssql-tools/bin à mon $PATH, j'ai choisi de me créer deux alias.

Mais l'on peut aussi utiliser l'outil Azure Data Studio disponible également sous Ubuntu.

SPIP-Cli sur serveur mutualisé

Brice Boucard — 2022-04-27T16:24:45Z

SPIP-Cli est « une interface en ligne de commande pour SPIP ». Sa documentation nous guide parfaitement pour une installation avec un accès root ou sudo. Sur un hébergement mutualisé, avec a minima un accès SSH relativement ouvert, il faut adapter la procédure.

Une fois connecté via SSH à votre serveur, il convient tout d'abord de créer un répertoire ~/.local/bin :

mkdir -p ~/.local/bin

Ensuite, dans ce répertoire, on clone le dépôt de SPIP-Cli et on lance l'installation avec composer (chez alwaysdata, il faut utiliser composer2) :

cd ~/.local/bin/ git clone https://git.spip.net/spip-contrib-outils/spip-cli.git cd spip-cli/ composer install

Ensuite, ne nous reste plus qu'à créer un lien symbolique afin de faciliter l'usage de la commande spip :

ln -s /home/$USER/.local/bin/spip-cli/bin/spip /home/$USER/.local/bin/

Pour ce qui est de l'autocomplétion, il suffit d'éditer le fichier ~/.profile ainsi :

source ~/.local/bin/spip-cli/bin/spip_console_autocomplete

Une fois Bash relancé, la commande devrait être disponible et l'automplétion de ses options fonctionner.

Installer « globalement » PHP_CodeSniffer

Brice Boucard — 2022-04-26T20:05:01Z

PHP_CodeSniffer est un outil de contrôle de votre code PHP afin d'en garantir la conformité au standard de votre choix.
Plutôt que de l'installer dans chacun de vos projets, il est possible de l'installer « globalement » et de le configurer pour permettre d'autres standards que ceux fournis de base, ceux de SPIP par exemple.

Préalables

Si vous n'avez pas de répertoire ~/bin/ dans votre /home, on commence par le créer :

mkdir ~/bin

Puis, on installe composer de façon « globale » dans ce répertoire ~/bin qui se trouve dans notre $PATH ; on commence par suivre les instructions de la documentation de Composer mais la troisième commande devient :

php composer-setup.php --install-dir=~/bin --filename=composer

Installation de PHP_CodeSniffer

Une fois cela fait, on peut installer « globalement » PHP_CodeSniffer :

composer global require squizlabs/php_codesniffer composer global require spip/coding-standards

Par défaut, chez moi, on retrouve les packages dans ~/.config/composer/vendor/ et les exécutables dans ~/.config/composer/vendor/bin/

Ne nous reste plus qu'à créer des liens symboliques dans notre ~/bin/ des exécutables de PHP_CodeSniffer :

ln -s ~/.config/composer/vendor/bin/phpcs ~/bin ln -s ~/.config/composer/vendor/bin/phpcbf ~/bin

On relance Bash et on peut alors déclarer le répertoire des standards SPIP à PHP_CodeSniffer :

phpcs --config-set installed_paths /home/$USER/.config/composer/vendor/spip/coding-standards/src/,/home/$USER/.config/composer/vendor/phpcompatibility/php-compatibility

Vous pouvez vérifier que la configuration est bien correcte en éditant le fichier ~/.config/composer/vendor/squizlabs/php_codesniffer/CodeSniffer.conf.

Utilisation

Il est alors possible de lancer les commandes phpcs et phpcbf où que vous soyez.
Il peut alors être intéressant de profiter d'une configuration locale, propre à votre projet : cela se passe dans le fichier phpcs.xml placé à la racine de votre projet :

  ./ **/*.js **/*.css **/*.scss node_modules/* vendor/*

Pour découvrir plus précisément les possibilités de configuration, je vous laisse consulter le fichier phpcs.xml.dist de PHP_CodeSniffer.

Optimisation des images sous SPIP

Brice Boucard — 2022-04-01T08:20:50Z

Travaillant sur divers sites présentant de nombreux visuels bien souvent extrêmement lourds, je cherchais un moyen d'optimiser ces images afin d'améliorer les « performances » de ces sites.

Après une recherche rapide sur contrib.spip.net et sur plugins.spip.net, je n'ai pas trouvé mon bonheur [1] et ai donc développé un petit plugin, Images optimisées (optimages), en me basant sur le package image-optimizer proposé par Spatie.

Le plugin Images optimisées est installable via SVP puisque disponible sur plugins.spip.net ou via Git.

Le fonctionnement de ce plugin se veut très simple : si leur format est compatible (en l'état JPEG, PNG et GIF bien que la librairie prenne également en charge les SVG ou WEBP), les images sont compressées dès leur téléversement grâce aux utilitaires jpegoptim, pngquant et optipng, ou enfin gifsicle.

Le plugin fournit une interface de configuration permettant de modifier, s'il détecte les binaires de ces utilitaires, les arguments passés à ceux-ci (par défaut, ce sont les valeurs utilisées par la librairie image-optimizer).

En l'état, sur un échantillon loin d'être représentatif, nous obtenons des résultats de l'ordre de 60% de réduction du poids des PNG et de 40 à 50% pour les JPEG.

[1] Il s'avère qu'il existe le plugin SmushIt au fonctionnement quelque peu différent, puisqu'il n'agit pas sur les images lors de leur téléverserment mais seulement lors de leur affichage.

Faire cohabiter plusieurs versions de PHP sous Debian

Brice Boucard — 2022-03-12T17:58:39Z

Surtout par curiosité, je me suis penché sur la possibilité de faire cohabiter plusieurs versions de PHP sur ma Debian Bullseye et surtout sur la façon de basculer aisément de l'une à l'autre.

Installation

Pour installer plusieurs versions de PHP conjointement, il faut ajouter le dépôt Sury :

sudo apt update sudo apt -y install apt-transport-https lsb-release ca-certificates curl sudo curl -sSLo /usr/share/keyrings/deb.sury.org-php.gpg https://packages.sury.org/php/apt.gpg sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/deb.sury.org-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list' sudo apt update

De là, il est possible d'installer diverses versions de PHP et de ses modules ; ainsi, sous Bullseye, je me vois proposer les versions 5.6, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0 et 8.1 :

apt search php | grep "php[0-9]\.[0-9]/" [...] php5.6/bullseye 5.6.40-57+0~20211119.60+debian11~1.gbp8a9bd1 all php7.0/bullseye 7.0.33-57+0~20211119.61+debian11~1.gbp5d8ba5 all php7.1/bullseye 7.1.33-44+0~20211119.61+debian11~1.gbp448fbe all php7.2/bullseye 7.2.34-28+0~20211119.67+debian11~1.gbpf24e81 all php7.3/bullseye 7.3.33-1+0~20211119.91+debian11~1.gbp618351 all php7.4/stable-security,now 7.4.28-1+deb11u1 all [installé, pouvant être supprimé automatiquement] php8.0/bullseye 8.0.16-1+0~20220221.30+debian11~1.gbp8b91a5 all php8.1/bullseye,now 8.1.3-1+0~20220223.13+debian11~1.gbp7757b9 all [installé, automatique]

Changer facilement de version de PHP

Afin de faciliter le basculement d'une version à une autre, j'ai compilé différentes sources pour finalement produire un petit script, très certainement imparfait, qui permet de choisir de manière interactive parmi les versions de PHP installées celle à utiliser.

touch ~/bin/php-switch chmod +x ~/bin/php-switch nano ~/bin/php-switch

#!/bin/bash # based on https://askubuntu.com/a/883140 # and on https://stackoverflow.com/a/68905711 # Déterminer la version de PHP actuellement utilisée par Apache VAR=$(ls /etc/apache2/mods-enabled/php*) IFS=' ' read -r -a array <<< "$VAR" array[0]=${array[0]#*php} array[0]=${array[0]%.conf} OLDVERSION=${array[0]} echo "La version de PHP actuellement utilisée est la" $OLDVERSION. echo "Liste des versions de PHP disponibles :" # Lister les versions de PHP installées RAWPOSSIBILITIES=$(update-alternatives --list php | sed 's/.*\(...\)/\1/') POSSIBILITIES=($RAWPOSSIBILITIES) # Demander la version de PHP à activer PS3='Choisissez la version de PHP à activer : ' select opt in "${POSSIBILITIES[@]}" "Annuler"; do case "$REPLY" in $((${#POSSIBILITIES[@]}+1))) echo "Salut!"; exit;; esac [ $REPLY -gt $((${#POSSIBILITIES[@]}+1)) -o $REPLY -lt 1 ] && echo "Choix invalide" || break done echo "Activer la version ${POSSIBILITIES[(($REPLY-1))]} ? Entrée pour valider, Ctrl-C pour annuler." read x # On reconfigure Apache sudo a2dismod php${OLDVERSION} sudo a2enmod php${POSSIBILITIES[(($REPLY-1))]} # On met à jour la version par défaut sudo update-alternatives --set php /usr/bin/php${POSSIBILITIES[(($REPLY-1))]} sudo update-alternatives --set phar /usr/bin/phar${POSSIBILITIES[(($REPLY-1))]} sudo update-alternatives --set phar.phar /usr/bin/phar.phar${POSSIBILITIES[(($REPLY-1))]} # On relance le service Apache sudo systemctl restart apache2

Node.js et autocomplétion avec Tmux

Brice Boucard — 2022-02-22T21:12:10Z

Si je bénéficiais parfaitement de l'autocomplétion des commandes fournies par node.js dans mon terminal classique, celle-ci ne fonctionnait plus sous Tmux : une sombre histoire de différence entre interactive shell et login shell.

Mon .bashrc contenait pourtant bien le code nécessaire mais, au-delà de l'autocomplétion de node.js, il ne semblait pas du tout être lu, puisque même mon invite de commande ne correspondait pas à celle configurée...

Cependant, mes recherches se focalisaient sur le problème de l'autocomplétion de node.js et ne me fournissaient guère de solution... C'est en changeant de perspective que je suis tombé sur le sujet « New tmux sessions do not source bashrc file » sur Stack Exchange et surtout sur la réponse très complète de Simba qui présente donc la différence entre les interactiven non-login shells — qui sourcent le fichier .bashrc — et les login shells — qui sourcent quant à eux les fichiers .profile et .bash_profile notamment.

Deux solutions sont alors possibles :

soit on « source » le fichier .bashrc depuis l'un de ces deux derniers fichiers — cette solution étant celle que recommande Simba justement :
```
# if running bash if [ -n "$BASH_VERSION" ]; then # include .bashrc if it exists if [ -f "$HOME/.bashrc" ]; then . "$HOME/.bashrc" fi fi 
```
soit on « intègre » l'autocomplétion de node.js dans le fichier .profile avec la simple commande :
```
npm completion >> ~/.profile 
```