Une petite news en provenance du [PyCon](http://www.pycon.org/), la convention centrée sur Python. [Xonsh](http://xon.sh/) est un nouvel interpréteur de lignes de commandes, et s'inscrit dans la longues liste des programmes dont la prononciation du nom va nuire à de nombreuses oreilles et va faire l'objet d'intenses discussions autour de la machine à café.
Un nouveau shell est né. C'est le genre de nouvelles qui, chez les sysadmins, fait pousser des hourras pour les uns et fait ricaner doucement les autres. Un petit points sur quelques unes de ses caractéristiques.
Nombreux sont les administrateurs frustrés par les efforts de frappe de texte lorsqu'il s'agit d'utiliser Bash, et qui préfèrent carrément se faire des scripts Python à la place. En effet, si vous vous souvenez de mon tutoriel [Let's Encrypt](/posts/securiser-ses-sites-web-avec-lets-encrypt), vous verrez des commandes Bash assez longues (et encore, ce n'est rien comparé à d'autres).
Xonsh promet d'allier la robustesse de Bash et l'aisance de Python. Car oui, en Python, on tape en une ligne ce que d'autres langages permettent de faire en 10, pour peu que l'on dispose des bonnes bibliothèques. Xonsh dispose apparemment de plus de commandes internes, ce qui lui permet par exemple d'effectuer des calculs tout simplement en les tapant dans le prompt, sans autre forme de procès, par exemple :
On retrouve aussi une grande prise en charge des expressions régulières, utiles pour le _glob_ des noms de fichiers par exemple. De quoi mettre les bons vieux utilitaires comme `grep`, `sed`, `cut` et `awk` à la retraite...
Je vous laisse découvrir ci-dessous une démonstration de l'utilisation de Xonsh.
On ne pourra s'empêcher de se rappeler, et les contributeurs de Xonsh le citent eux-même, le shell Fish, censé être beaucoup plus amusant à utiliser à grand coup de couleurs et d'auto-complétion à tout-va. Même si ce shell est très agréable à utiliser, son seul point fort est sa dorure extérieure. Pour ce qui était du scripting, il utilise des standards pas franchement catholiques, dans le sens qu'ils étaient fondamentalement opposés à ceux de Bash, et qu'il n'a pas réussi à imposer. Car dans le domaine des outils très fréquemment utilisés comme le shell, il n'y a que deux solutions : soit réussir à instaurer ses standards, soit se soumettre à ceux existants. Vous savez, les standards sont des choses très délicates, car par définitions, ils doivent rester très peu nombreux...
