Fish, OhMyZsh, etc.

a marqué ce sujet comme résolu.

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 ?

+0 -0

Salut,

Ça va dépendre beaucoup de l’utilisation que tu en fais, en fait. Si c’est pour du shell interactif, bash est quand même assez pourri face à zsh ou fish (ne serait-ce qu’en terme de complétion et de richesse de l’environnement en général).

Si le but est de faire du scripting, l’intérêt du shell est très limité, tu as intérêt à utiliser des langages plus sains comme Python si t’as pas la contrainte de devoir écrire des scripts qui doivent tourner sur des machines obscures où Python n’est pas disponible (ce cas survenant assez rarement…). Utiliser Python (ou n’importe quel langage avec des abstractions raisonnables pour manipuler les chaines de caractères et les fichiers et appeler d’autres programmes) permet bien plus qu’éviter la "syntaxe austère" des shells : au delà de la lisibilité (qui compte déjà beaucoup !), les possibilités d’abstractions et donc de maintenabilité des scripts n’est même pas comparable entre les shells et Python (qui n’est pourtant pas un modèle en terme de maintenabilité et pouvoir d’abstraction, c’est dire !). Une exception à surveiller potentiellement est nushell, mais le projet est encore loin d’être assez mûr et répandu pour être une alternative viable comme shell principal.

+1 -0

Salut,

Ça va dépendre beaucoup de l’utilisation que tu en fais, en fait. Si c’est pour du shell interactif, bash est quand même assez pourri face à zsh ou fish (ne serait-ce qu’en terme de complétion et de richesse de l’environnement en général).

Si le but est de faire du scripting, l’intérêt du shell est très limité, tu as intérêt à utiliser des langages plus sains comme Python si t’as pas la contrainte de devoir écrire des scripts qui doivent tourner sur des machines obscures où Python n’est pas disponible (ce cas survenant assez rarement…). Utiliser Python (ou n’importe quel langage avec des abstractions raisonnables pour manipuler les chaines de caractères et les fichiers et appeler d’autres programmes) permet bien plus qu’éviter la "syntaxe austère" des shells : au delà de la lisibilité (qui compte déjà beaucoup !), les possibilités d’abstractions et donc de maintenabilité des scripts n’est même pas comparable entre les shells et Python (qui n’est pourtant pas un modèle en terme de maintenabilité et pouvoir d’abstraction, c’est dire !). Une exception à surveiller potentiellement est nushell, mais le projet est encore loin d’être assez mûr et répandu pour être une alternative viable comme shell principal.

adri1

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

+0 -0

J’utilise fish car l’expérience utilisateur n’a rien à voir avec bash. Je n’utilise pas oh-my-fish.

je souhaiterai améliorer ma productivité en tant que développeur avec cet outil

Tout ce que tu as à savoir c’est le chaînage de commandes, quelques opérateurs et surtout une pléthore de petits programmes comme wc (word count) ou tr (translate). Pour le reste si tu veux améliorer ta productivité, n’utilise pas cet outil, utilise autre chose.

Je ne code pas vraiment en fish, ce que je fais au plus, ce sont des petits scripts ad-hoc que je tapes directement dans le terminal. Dès que je dois faire un truc, je passe à Python ou Go.

+0 -0

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.

+0 -0

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.

+1 -2

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.
+3 -0

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.

+6 -0

Si c’est pour du shell interactif, bash est quand même assez pourri face à zsh ou fish (ne serait-ce qu’en terme de complétion et de richesse de l’environnement en général).

adri1

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)

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.

adri1

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.

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.

adri1

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 !

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 interragit avec le système etc.) parfois c’est effectivement Python (librairies, gestion des erreur etc.).

Le shell est aussi plus performant […]

Wissensdurst

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 ?

+0 -3

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. :D

+2 -0

(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

+2 -0

À 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.

J’affirme justement que le gain de productivité que j’ai avec fish est sur ce genre de commande. Que je ne tape même pas dans un fichier, je l’utilise directement dans le shell.

Si j’en ai besoin plus souvent, je crée un alias.

+0 -0

À 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.

J’affirme justement que le gain de productivité que j’ai avec fish est sur ce genre de commande. Que je ne tape même pas dans un fichier, je l’utilise directement dans le shell.

Si j’en ai besoin plus souvent, je crée un alias.

ache

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.

+1 -0

En fonction de ton utilisation, perso je conseillerais :

  • écrire des scripts facilement : Fish
  • être executable sur beaucoup de systèmes par défaut : Bash
  • performance et conformité POSIX : Dash (utilisé par Debian/Ubuntu (symlinké en sh)).
Wissensdurst

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.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte