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 Ju. . É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.linuxfr-france.org.invalid/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 ckyl . Évalué à 8.
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 ckyl . Évalué à 4.
> 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 patrick_g (site web personnel) . É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.
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 gnumdk (site web personnel) . Évalué à 4.
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 patrick_g (site web personnel) . Évalué à 5.
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 Bapt (site web personnel) . Évalué à 6.
[^] # Re: POSIX
Posté par yoho (site web personnel) . Évalué à 1.
[^] # Re: POSIX
Posté par gnumdk (site web personnel) . Évalué à 5.
>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 patrick_g (site web personnel) . Évalué à 3.
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 ckyl . Évalué à 6.
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 C2RIK . Évalué à 1.
[^] # Re: Coloration syntaxique
Posté par PachaFonk . Évalué à 2.
... ou un éditeur de texte qui pourrait (entre autre) lancer un shell !?!
[^] # Re: Coloration syntaxique
Posté par BAud (site web personnel) . Évalué à 3.
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 gnumdk (site web personnel) . Évalué à 2.
[^] # Re: Coloration syntaxique
Posté par Christophe Merlet (site web personnel) . Évalué à 3.
Ç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 fusible . Évalué à 2.
> Ç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 bobert . Évalué à 2.
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 Nicolas Évrard (site web personnel, Mastodon) . Évalué à 2.
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 lolop (site web personnel) . Évalué à 2.
Si si...
http://ipython.scipy.org/doc/manual/node12.html(...)
Et:
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à.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Intéressant
Posté par THE_ALF_ . Évalué à 2.
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 M . Évalué à 3.
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.