Journal Enfin un shell pour moi ?

Posté par  (site web personnel) .
Étiquettes :
1
27
mai
2005
Sur le site de LWN ( http://lwn.net/Articles/136232/(...) ) on peut lire un long article sur un nouveau shell linux : Fish (Friendly Interactive Shell).
Selon l'auteur depuis 10 ans les GUI ont fait des gros progrès mais les shells ont stagné et sont plus complexes à exploiter pour les non informaticiens que cela ne devrait.
Il a repris le problème à zéro et propose avec Fish une solution séduisante et assez novatrice.
Les ajouts immédiatement visibles sont : coloration syntaxique ; tab complétion activée par défaut ; aide intégrée et browsable en direct ; syntaxe du shell révisée.

C'est vraiment cette nouvelle syntaxe qui me tente beaucoup (le reste est très cool mais je pense qu'avec beaucoup de sueur on doit pouvoir configurer d'autres shells pour avoir ces features).
L'auteur a constaté l'illogisme de certaines commandes et de leur syntaxe et a décidé d'uniformiser et de simplifier le tout.
C'est très frappant dans quelques exemples de commandes qu'il donne de voir l'uniformité logique de Fish et le foutoir grotesque de la syntaxe POSIX habituelle.


POSIX command :
if true; then echo hello; fi
fish command :
if true; echo hello; end

POSIX command :
for i in a b c; do echo $i; done
fish command :
for i in a b c; echo $i; end

POSIX command :
case $you in *) echo hi;; esac
fish command :
switch $you; case '*'; echo hi; end

POSIX command :
hi () { echo hello; }
fish command :
function hi; echo hello; end


L'article donne beaucoup d'autres arguments et exemples et le projet me semble très prometteur pour des gens comme moi qui sont rebutés par la complexité des Bash, Zsh et autres Tcsh.
Je crains malgré tout qu'au final ce ne soit un des commentateurs de l'article qui ne soit prophétique : I wonder whether fish is a bit like Esperanto -- the right idea, for the right reason, but never attracting enough support to really be useful.

PS : Fish est bien entendu sous GPL.
  • # Le Shell Fish ne serait il pas egoiste ?

    Posté par  . Évalué à 5.

    ;-)


    Je veux dire en regard de ta citation : I wonder whether fish is a bit like Esperanto -- the right idea, for the right reason, but never attracting enough support to really be useful.

    Le gaillard a pris comme nom pour son shell exactement le meme qu'un protocole réseau ssh+ftp (en gros)

    http://www.linux-france.org/prj/inetdoc/cours/admin.reseau.tp/admin(...)


    Ca va pas aider sa visibilité sur google ( sans parler du bestiau qui porte le meme nom )


    Malgré tout certaines options ont l'air vraiment trés interessantes.
  • # POSIX

    Posté par  . Évalué à 8.


    POSIX command :
    for i in a b c; do echo $i; done
    fish command :
    for i in a b c; echo $i; end


    Y'a pas a dire quand on voit les avancées magnifiques que propose l'outil sur la syntaxe. Ca vaut le coup de ne pas respecter les standards et la compatibilité !

    Franchement soit tu as choisi des exemple bien pourris soit c'est du grand n'importe quoi. Ne pas respecter POSIX pour supprimer un do et un then.... Aller moi aussi je vais aller revisiter le C99 et le xhtml ce sont des foutoirs grotesques.
    • [^] # Re: POSIX

      Posté par  . Évalué à 4.

      Ha oui j'oubliai

      > zsh provides command-specific tab completions, a history file, tab completion of strings with wild cards and many, many other advanced functions. But none of them are turned on by default. In fact, a user who starts zsh for the first time would think it was a small improvement over the original Bourne shell

      Ca serait pas un peu le rôle de la distrib ?

      Tu sais ton noyau linux, il est tout plein de fonctionnalités avec a peu près autant de documentation que le balais que je viens d'acheter. Ca permet de faire plein de choses super mais si je lis pas le code source ou lkml je pourrai jamais m'en servir et savoir comment ca marche. Tiens ca me donne une idée, je vais coder un nouveau noyau et pas POSIX compliant par ce que quand tu vois les incohérences dedans tu te dis que la priorité était peut être pas le shell....
    • [^] # Re: POSIX

      Posté par  (site web personnel) . Évalué à 6.

      >> Franchement soit tu as choisi des exemple bien pourris soit c'est du grand n'importe quoi.

      Bon je pense qu'il faut que tu essaye de te mettre dans la peau d'un newbie comme moi. Peut-être que ça fait 10 ans que tu mange du shell tous les jours et que tu est capable de pondre du code ultra-vite mais ce n'est pas le cas de tout le monde.
      Qu'est ce que je vois moi dans ces exemples ?

      on note que dans la syntaxe POSIX si c'est un if on termine par un fi, si c'est un for on termine par un done, si c'est un case on termine par un esac, si c'est une fonction on termine par un }....ou est la logique ?
      Dans le cas de fish on termine toujours par un end : c'est propre, c'est facile, c'est consistant.

      Et c'est tout comme ça !
      Dans la syntaxe POSIX si c'est un if alors il faut un then, si c'est un for alors il faut un do...Fish balaye ces différences comme tu peux le voir dans l'article : il fait son echo machin sans avoir a mettre then ou do : c'est facile de s'en souvenir.

      Je sais bien que casser une compatibilité c'est emmerdant (et je te rassure je n'ai absolument aucune illusion sur le percée de Fish) mais pour les débutants comme moi et beaucoup d'autres ce serait indéniablement mieux.
      • [^] # Re: POSIX

        Posté par  (site web personnel) . Évalué à 4.

        Super les arguments...

        Alors tu vois, dans pas mal de langage de haut niveau genre ADA, du différencie les fin de bloc via une instruction différente: end loop; end if; end; suivant si tu te situe dans une boucle, dans un if ou dans un nouveau bloc.

        Avec ton truc, sur un script shell bien complexe et malgre une identation correcte, tu es sur de te retrouver avec un mal de tete pour savoir à quel bloc fait référence le end;

        d'ou l'interet d'avoir des do...done, then...fi , un soucis de clarté que tu n'auras pas avec ton truc.

        De plus, son langage aurait apporté une syntaxe totalement différente et nouvelle, j'aurais applaudit, mais la, franchement, pas être capable de retenir la syntaxe du if et du for, autant arreter de faire des scripts shell ...
        • [^] # Re: POSIX

          Posté par  (site web personnel) . Évalué à 5.

          >> Avec ton truc, sur un script shell bien complexe et malgre une identation correcte, tu es sur de te retrouver avec un mal de tete pour savoir à quel bloc fait référence le end

          En même temps est-ce que le shell est vraiment fait pour écrire des gros scripts bien complexes ? Est-ce qu'il ne faudrait pas réserver ça à Python/Perl/Ruby ?
          Pour écrire un petit truc rapide le shell c'est bien....mais la consistance et le principe de surprise minimale c'est bien aussi.

          >> pas être capable de retenir la syntaxe du if et du for, autant arreter de faire des scripts shell

          Il me semble sentir un petit relent de condescendance et de mépris pour les gens inexpérimentés dans cette phrase non ?
          • [^] # Re: POSIX

            Posté par  (site web personnel) . Évalué à 6.

            Quand tu es sur des serveurs de prod hétérogènes AIX/SOLARIS/... et que tu n'as pas accès à l'installation de nouveaux langages : Ruby/Python ou que perl n'est pas installé (et oui, tous les OS ne l'installent pas par défaut) et quand bien même tu ne peux pas lui rajouter de modules CPAN, pas les droits, pas de compilo, ..., le shell en POSIX permet de faire beaucoup de choses : le projet sur lequel je suis on a des scripts KSH de plus de 2000 lignes qui fonctionne sur plusieurs OS différents. Heureusement que l'on utilise pas Fish car on peterait un cable pour si retrouver : le end la il correspond à quoi déjà ??
          • [^] # Re: POSIX

            Posté par  (site web personnel) . Évalué à 5.

            >Il me semble sentir un petit relent de condescendance et de mépris pour les
            >gens inexpérimentés dans cette phrase non ?

            Non, pour les gens qui font aucun effort.
            Je suis désolé, mais le shell, comme tout langage, ca s'apprend.

            Et oui le shell est mieux que perl & co des qu'il s'agit de faire du systeme! J'ai jamais fait un script perl de ma vie, je fais tout en shell et tu peux faire plus de truc que tu semble l'imaginer.

            Moi, je vois plus python et perl pour faire des programmes qui manipule des type de données complexes, mais pour le reste, je reste fidele au shell ;)
            • [^] # Re: POSIX

              Posté par  (site web personnel) . Évalué à 3.

              >> Je suis désolé, mais le shell, comme tout langage, ca s'apprend.

              On est d'accord. Tout ce que je dit (et pour reprendre l'analogie déja évoquée) c'est que l'espéranto est aussi puissant que le français. Il permet d'exprimer les mêmes idées, les mêmes finesses....mais il est bien plus simple à apprendre et bien plus logique.
              Si tu partais de zéro au moment d'apprendre une langue (et je te répète que je suis conscient qu'on doit tous faire un effort d'apprentissage au début) je pense que tu choisirais un truc simple et logique non ?
      • [^] # Re: POSIX

        Posté par  . Évalué à 6.

        > Bon je pense qu'il faut que tu essaye de te mettre dans la peau d'un newbie comme moi. Peut-être que ça fait 10 ans que tu mange du shell tous les jours et que tu est capable de pondre du code ultra-vite mais ce n'est pas le cas de tout le monde.

        Ce semestre j'ai participé à l'enseignement des bases du shell/grep/sed/awk/cut/paste à des licences première année, niveau débutant j'ai du en voir passer quelques uns quand même...

        J'ai pas le temps de developper mais grosso modo il me semble que l'auteur voudrait un shell qui n'est pas plus simple mais que ne le pertube pas dans ses habitudes de codeur C. Pour cela il retire de l'expressivité en ne proposant rien de neuf, il retire des fonctionalités et propose un coup de peinture.

        Je n'ai rien contre expérimenter des choses, quand les standards sont mauvais il faut chercher des solutions pour les tuer, qui à dit que je pense au C :-) Mais là en l'occurence c'est une couche de vernis qui casse tout pour des apports bien maigres. Soit il a trop d'ambitions soit pas assez.

        Cela dit il y a quelques bonnes idées la dedans. En faire profiter un shell aurait peut être été plus judicieux mais l'avenir le dira.
  • # Coloration syntaxique

    Posté par  . Évalué à 1.

    A mon avis la coloration devrait être externe au shell, le gestionnaire de terminal pourrait s'en charger. Je me demande pourquoi personne n'y a pensé, ça doit pas être beaucoup plus dur de faire ça dans une fenêtre de terminal que dans un fichier texte où l'on code... Ainsi quel que soit le shell tout le monde en profite.
    • [^] # Re: Coloration syntaxique

      Posté par  . Évalué à 2.

      le gestionnaire de terminal pourrait s'en charger.


      ... ou un éditeur de texte qui pourrait (entre autre) lancer un shell !?!
    • [^] # Re: Coloration syntaxique

      Posté par  (site web personnel) . Évalué à 3.

      je ne comprends pas très bien, la coloration syntaxique, moi ça marche très bien dans vi (ou vim) et dans gedit

      c'est du même acabit que la complétion automatique, elle est activée par défaut... sur RHEL et sur Mandriva GNU/Linux en tout cas, les autres distribs je ne sais plus.
    • [^] # Re: Coloration syntaxique

      Posté par  (site web personnel) . Évalué à 2.

      Enfin, si quand tu fait un ls -l sur un rep de plusieurs entrée, si le terminal doit tout analyser pour savoir comment colorier(rep, fichier, ...), ca va ramer sec...
    • [^] # Re: Coloration syntaxique

      Posté par  (site web personnel) . Évalué à 3.

      > A mon avis la coloration devrait être externe au shell...


      Ça tombe bien, c'est pas le shell qui s'en occupe mais ls !

      > Je me demande pourquoi personne n'y a pensé

      Je me demande pourquoi certains ne pense pas tout court !
      • [^] # Re: Coloration syntaxique

        Posté par  . Évalué à 2.

        > > A mon avis la coloration devrait être externe au shell...

        > Ça tombe bien, c'est pas le shell qui s'en occupe mais ls !

        Le monsieur parle de la coloration de la ligne de commande, pas de la sortie d'une commande!

        > Je me demande pourquoi certains ne pense pas tout court !

        Contrairement à une idée répandue, se regarder le nombril n'est pas toujours un tord!
  • # Je vais vous dire...

    Posté par  . Évalué à 2.

    ...parce que je suis toujours inspiré avant le week-end:

    le jour où on me propose un bon shell en python, j'achète. Les yeux fermés. D'ici là... bof.
    • [^] # Re: Je vais vous dire...

      Posté par  (site web personnel) . Évalué à 2.

      ipython fait un peu shell. D'après la notice au début du shell:

      Alias -> System Command
      ------------------------------
      cat -> cat
      clear -> clear
      cp -> cp -i
      lc -> ls -F -o --color
      ldir -> ls -F -o --color %l | grep /$
      less -> less
      lf -> ls -F -o --color %l | grep ^-
      lk -> ls -F -o --color %l | grep ^l
      ll -> ls -lF
      ls -> ls -F
      lx -> ls -F -o --color %l | grep ^-..x
      mkdir -> mkdir
      mv -> mv -i
      rm -> rm -i
      rmdir -> rmdir
      ------------------------------

      Mais on ne peut pas (encore ?) lancer de progs

      http://ipython.scipy.org/(...)
      • [^] # Re: Je vais vous dire...

        Posté par  (site web personnel) . Évalué à 2.

        Mais on ne peut pas (encore ?) lancer de progs

        Si si...

        http://ipython.scipy.org/doc/manual/node12.html(...)

        IPython as a system shell

        IPython ships with a special profile called pysh, which you can activate at the command line as `ipython -p pysh'. This loads InterpreterExec, along with some additional facilities and a prompt customized for filesystem navigation.

        Note that this does not make IPython a full-fledged system shell. In particular, it has no job control, so if you type Ctrl-Z (under Unix), you'll suspend pysh itself, not the process you just started.


        Et:

        Special syntax

        Any lines which begin with `~', `/' and `.' will be executed as shell commands instead of as Python code. The special escapes below are also recognized. !cmd is valid in single or multi-line input, all others are only valid in single-line input:

        !cmd
        pass `cmd' directly to the shell
        !!cmd
        execute `cmd' and return output as a list (split on `\n')
        $var=cmd
        capture output of cmd into var, as a string
        $$var=cmd
        capture output of cmd into var, as a list (split on `\n')


        Donc, c'est pas parfait, mais ça peut très largement dépanner.

        Le GROS inconvénient, c'est qu'il faut installer Python et iPython, alors que sh est toujours (presque) là.

        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

  • # Intéressant

    Posté par  . Évalué à 2.

    Des idée intéressante, je vais essayer un peu pour voir à l'usage. Ceci dit, il est vrai que l'introduction de syntaxe non-Posix ne soit pas forcément une bonne idée.

    Pour la lisibilité decertaines commandes, voila un petit exemple (inutile):
    Mon prompt bash:
    alf[Wintermute]>~ [14:20:44] $ echo $PS1
    \[\033[35;01m\]\u\[\033[34;01m\][\h]\[\033[37;00m\]>\[\033[32m\]\w\[\033[33m\] [\t] \[\033[37m\]\$

    Le même écrit pour fish:
    alf[Wintermute]>~[14:24] $ echo $FISH_PROMPT
    set_color magenta; whoami;set_color blue;echo \[; hostname; echo \]; set_color normal ; echo '>'; set_color green; pwd; set_color yellow; echo '['; date +%H:%M; echo ']'; set_color normal;echo ' $ ';

    :-)
    • [^] # Re: Intéressant

      Posté par  . Évalué à 3.

      Pour la lisibilité decertaines commandes, voila un petit exemple (inutile):
      genial, tu peux faire la meme chose sous bash avec

      PS=`(set_color magenta; whoami;set_color blue;echo \[; hostname; echo \]; set_color normal ; echo '>'; set_color green; pwd; set_color yellow; echo '['; date +%H:%M; echo ']'; set_color normal;echo ' $ ';) | tr -d '\n'`

      et la commande set_color qui retourne les bon carracteres d'echapement...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.