Fish, OhMyZsh, etc.

Bon(jour)/(soir),

Je ne possède qu’une connaissance superficielle de Bash et je souhaiterai améliorer ma productivité en tant que développeur avec cet outil. Je me demande ce que vous pensez des alternatives dans le style de celles énoncées ci-haut.

Y a-t-il un intérêt spécifique à se passer de la syntaxe quelque peu austère de Bash ? Est-il possible d’utiliser, par exemple, python à la place ?

Merci pour cette réponse. Quel shell utilises-tu au quotidien ? Je suis vraiment intéressé par Fish.

J’utilise zsh (mais pas OhMyZsh, ce dernier n’est qu’un gestionnaire de plugins qui essaye de faire le café et qui se retrouve assez lent et mal foutu au final). Il y a principalement deux raisons pour lesquelles j’utilise zsh plutôt que fish :

• quand je me suis intéressé à la question il y a environ 10 ans, fish s’était déjà fait un nom mais n’était pas aussi répandu que maintenant donc le support par d’autres outils était plus parcellaire ;
• je suis souvent amené à travailler avec des machines qui n’ont que du support pour bash (ce qui m’effarait déjà il y a 10 ans !), et potentiellement avec des scripts qu’on veut faire tourner presque partout et donc avoir un shell POSIX au quotidien veut dire moins de friction quand je passe de mon environnement à ceux sur ces machines.

La première contrainte est moins valide aujourd’hui (même si le support zsh est généralement plus large que le support fish), et donc le choix entre les deux dépend surtout de si la compatibilité POSIX t’apporte quelque chose ou si tu préfères un shell un peu mieux foutu.

Si tu veux mixer du shell et du Python, y’a xon.sh.

l’intérêt du shell est très limité, tu as intérêt à utiliser des langages plus sains comme Python

Pas d’accord, selon ce que l’on a à faire un script shell est plus adapté (exec. d’autres programmes, piping, tout ce qui interagit avec le système etc.) parfois c’est effectivement Python (librairies, gestion des erreurs etc.).

Le shell est aussi plus performant (j’ai fais l’expérience sur Linux de comparer strace pour un echo hello (de mémoire : bash : 150, Fish : 350 zsh : 900, python 1200 syscalls) et time, et certains shells étaient très proches du C).

L’UX de Fish est très bonne sans être aussi lente que zsh. Le langage Fish rend aussi le script shell plus dev-friendly, mais il n’est donc nécessairement pas compatible avec la norme POSIX.

Pas d’accord, selon ce que l’on a faire un script shell est plus adapté (exec. d’autres programmes, piping, tout ce qui interragit avec le système etc.) parfois c’est effectivement Python (librairies, gestion des erreur etc.).

C’est un peu dommage de citer juste un morceau pour rater l’essentiel et finalement ne rien ajouter de substantiel à ce qui a déjà été dit. Si on est dans le cas où on a juste besoin de piping entre quelques commandes, c’est évident qu’on peut très bien se contenter d’un shell parce que… c’est le seul truc qui s’exprime mieux en shell qu’en n’importe quoi d’autre et ce cas d’utilisation ne demande en pratique aucune connaissance approfondie. Si on parle de scripting qui va plus loin qu’une connaissance superficielle du shell (le sujet du fil de discussion, donc), ce dernier devient un choix beaucoup moins attractif parce qu’il n’offre aucun moyen ergonomique d’abstraire quoique ce soit (et d’une certaine façon, c’est pas vraiment ce qu’on demande d’un shell de toute façon).

Le shell est aussi plus performant (j’ai fais l’expérience sur Linux de comparer strace pour un echo hello (de mémoire : bash : 150, Fish : 350 zsh : 900, python 1200 syscalls) et time, et certains shell étaient très proche du C).

Évidemment (ou peut être pas tant que ça…), ce genre d’argument est parfaitement absurde pour plein de raisons :

• il est complètement contre-productif de parler performance avant d’avoir déterminé un bottleneck réel ;
• un benchmark de solution sur des cas artificiels ne dit rien de pertinent sur ce qui se passe dans un vrai cas d’usage ;
• si on veut vraiment faire un benchmark artificiel, on ne compare pas des technologies sur un hello world parce que le coût métier est complètement masqué par tout le reste (et donc tu mesures effectivement un temps constant qui n’a dans 99.9999% des cas aucune conséquence pratique) ;
• chercher la solution performante pour la machine lorsqu’on parle de tâches où le facteur limitant est humain (avec plusieurs ordres de grandeur de marge !) dans la très vaste majorité des cas n’a aucun sens.

Le shell est aussi plus performant (j’ai fais l’expérience sur Linux de comparer strace pour un echo hello (de mémoire : bash : 150, Fish : 350 zsh : 900, python 1200 syscalls) et time, et certains shell étaient très proche du C).

Le sujet m’intéresse assez peu (j’utilise zsh au jour le jour mais jamais pour scripter, juste comme shell), cependant cette remarque me fait réagir, parce que je pense qu’elle tape doublement à côté de la cible.

D’abord, parmi toutes les méthodologies douteuses pour évaluer les perfs d’un langage, comparer le nombre de syscalls réalisés pour un Hello World tient certainement la palme d’or. Oui, Python va faire une tetrachiée d’appels système au démarrage pour charger sa lib standard et compiler le programme avant de l’exécuter. C’est vrai. Néanmoins ce n’est en rien indicatif des performances d’un programme réel. Une grosse partie des bibliothèques python sont en réalité des bindings écrits en C ou C++. Ce faisant, dès lors que le métier du programme à exécuter est non-trivial, et appelé à tourner pendant plus d’une demi-seconde, la balance va finir par lourdement pencher du côté de Python (sans même parler des abstractions ou des bibliothèques accessibles, où là, pour le coup, cela reviendrait à tirer sur l’ambulance côté shell).

Ensuite, si ce sont de performances que l’on a besoin, alors clairement, ni python, ni un shell ne sont de sérieux candidats.

Ce qui caractérise un script, la plupart du temps, c’est la vitesse à laquelle on l’écrit pour résoudre une tâche donnée et passer à autre chose de plus intéressant dans sa vie. Dans ce contexte, même l’argument de la maintenabilité aurait de quoi faire hausser un sourcil.

C’est toujours amusant de lire ces pseudos comparaisons (encore que je ne comprends pas le besoin de vouloir toujours taper sur un autre pour en défendre un autre.) Bash et Zsh ont à peu près le même âge (encore que, je crois que Zsh est apparu un peu plus tôt ?) et les mêmes fonctionnalités (et donc la même richesse) ne déplaise ! C’est juste que les deux n’ont pas fait les mêmes choix de base, et Bash a voulu rester par défaut au plus proche de Ksh (que les deux voulaient remplacer avant l’apparition de PDKsh)

T’en as de la chance car je suis tombé sur des machines où il n’y avait même pas bash en shell interactif.

Attention aussi que bien que pouvant être plus POSIX-compliant que Zsh, Bash ne l’est pas par défaut. Perso, je n’écris que des scripts POSIX que je teste avec dash ; mais je n’utilise pas du tout celui-ci en shell interactif !

Le souci est que les gens veulent utiliser des scripts shell comme du C/Java/etc. La capacité de scripting du shell est conçue pour faire des batchs avec les contraintes d’une certaine époque, pas pour concurrencer les langages de programmation …même de cette époque.

on ne compare pas des technologies sur un hello world parce que le coût métier est complètement masqué par tout le reste (et donc tu mesures effectivement un temps constant qui n’a dans 99.9999% des cas aucune conséquence pratique)

Je suis d’accord que ce n’est pas la métrique idéale, mais rien ne permet d’affirmer que son usage en tant que dev l’est pour des programmes complexes pour lesquelles les spécificités intrinséques du langage l’emporteraient (les scripts shell sont maintenant surtout utilisé pour des petis scripts pour les raisons que j’ai / tu as cité). à résultat et difficulté constante, c’est normal de chercher un langage avec, (au moins) un temps de démarrage ~10 fois plus rapide, ce n’est à mon sens pas de l’optimisation prématurée.

ne rien ajouter de substantiel à ce qui a déjà été dit

j’ai ajouté des cas d’usage, et à part la comptabilité POSIX que je n’avais pas relevé (je répondais à ton message initial), je n’ai pas l’impression de t’avoir répété.

Le sujet m’intéresse assez peu (j’utilise zsh au jour le jour)

Tu as probablement une machine rapide (moi aussi), sinon c’est une plainte relativement courante, notamment par des gens qui y ajoutent des plugins pour égaler les fonctionnalités que Fish a par défaut, et donc j’estime que ce dernier vaut plus le coup.

c’est évident qu’on peut très bien se contenter d’un shell

si ça l’est, pourquoi conseiller un autre langage quand on ne connait pas l’usage d’OP ?

Salut,

Je suis passé de bash à zsh pour, comme toi, être plus rapide. Avec le temps j’ai fait quelques petites configurations et voici les fonctionnalités que j’utilise le plus aujourd’hui:

1. Le fait de pouvoir définir des raccourcis claviers personnalisés.
2. L’usage des alias globaux et des alias par suffixe (en plus des alias classiques qui sont aussi présents en bash)
3. La définition de fonction dans zsh (pour par exemple afficher ma branche git sur laquel je suis sans ajouté de plugin comme OhMyZsh)
4. La complétion qui me semble être bien plus efficace.

Je ne sais pas si ces fonctionnalités peuvent t’intéresser, en tout cas elles sont disponibles avec zsh. Elles sont aussi peut-être disponibles avec fish ou même bash.

Je pense que pour choisir le mieux est de trouver les fonctionnalités qui te manquent ou que tu souhaites utiliser et de voir si elles sont présentes dans les différents shell.
Je pense aussi qu’il ne faut pas hésiter à te jeter à l’eau et essayer avec l’un et l’autre pour trouver celui qui te conviendra le mieux.

(Personnellement je trouve utile et pertinent de mesurer le temps de démarrage pour certains scripts, comme le suggère Wisseendurst, par exemple ceux qui gèrent l’auto-complétion des commandes dans le terminal. D’ailleurs les développeurs de Python sont conscients des difficultés liées au temps de démarrage et essaient régulièrement de le réduire, ce qui montre bien qu’il y a des cas d’usages pertinents où il pose problème.)

Je ne dis pas le contraire, mais là tu t’appuies sur des usages particulièrement précis (j’aurais presque envie de dire "de niche"), pour finalement dire que oui, il existe des contextes dans lesquels les perfs de démarrage sont importantes. Contextes qui ne sont pas du tout le mien.

À ce moment je pense qu’il serait intéressant, pour être sûr que nous parlons bien tous de la même chose, de définir les cas d’utilisation dans lesquels nous avons recours à des scripts. En particulier l’OP puisque le but du thread est quand même de lui répondre. Il va de soi que pour un script qui se résume à :

#!/bin/bash

find $1 -type f -exec git blame {} \; | grep -oP "Pierre|Paul|Jacques" | sort | uniq --count

On se moque totalement du temps de démarrage ou même d’utiliser des abstractions.

De même tout le monde n’écrira pas forcément un script pour faire la même chose : j’imagine qu’un grand nombre de règles que je colle dans un makefile pourraient être des scripts à part entière, personnellement. De plus, je ne suis pas sûr que l’on puisse trouver deux intervenants sur ce thread dont le métier soit le même, ce qui influence pas mal aussi les points de vue et les réponses.

Par exemple, écrire des programmes en CLI avec autocomplétion, dans mon référentiel ça sort totalement de l’usage d’un langage de script, et perso je fais ça en Go avec cobra qui gère ça parfaitement pour les shells les plus courant, nativement et de façon totalement transparente, parce que l’on rentre dans le besoin de maintenabilité et de découvrabilité du programme, et celui-ci est donc, a priori, amené à être utilisé par un très large panel d’utilisateurs : on est loin de l’usage "one shot rapide et crade" que je réserve aux scripts.

Bref, je pense que la discussion serait plus intéressante si l’on prenait le temps de préciser les cas d’utilisation que nous avons en tête en répondant.

[EDIT @viki53]: Premier paragraphe supprimé car hors-sujet

On va éviter le HS si vous le permettez : ouvrez un nouveau sujet si besoin, mais l’objectif ici est de répondre aux interrogations d’Inoo-vm

En l’occurrence, j’en ai fait un script avec un nom rigolo (whose_problem_is_it.sh) pour le partager parce que cette commande sert de proxy pour évaluer le bus factor sur certains sujets dans mon équipe. Mais un alias aurait tout aussi bien pu marcher dans l’absolu, oui.

Merci pour toutes vos réponses ! Si je comprends donc bien, bash ne fait pas l’unanimité et les outils que j’ai énoncé ont bien leur utilité !

Je suis assez intrigué par fish shell et je pense que je vais y jeter un oeil.

Dans la mesure où les deux derniers points ne m’intéresse pas beaucoup…

J’utilise Fedora partout (notamment avec WSL2) et si je dois changer de système je possède des dotfiles avec ma configuration (actuellement OhMyZsh) enregistrée.