Il faut importer les bons modules avant. Au delà d'être lourdingue, cela oblige à bien connaître les fonctions de la doc.
Oui bref, c'est un peu longuet et tout par rapport au shell, mais l'avantage c'est qu'on a un vrai langage de programmation (but recherché). Si la concision est vraiment importante on peut se poser la question d'écrire un PPX – ce qui est a priori bien plus simple que d'écrire un langage complet!
Dans un sens dans Gufo, j'ai deux langages qui s'imbriquent: un langage fonctionnel basique qui peut contenir un sous-langage de commande (qui vise a imiter bash). C'est aussi une façon d'aider le nouveau venu: il peut au début utiliser la partie commande et découvrir au fur et à mesure le langage au dessus.
Je comprends bien, mais il ne faut pas perdre de vue qu'il y a une longue histoire de remplacements au shell qui sont tous de façon tout à fait défendable mieux que le shell de Bourne (le /bin/sh historique) mais en pratique ils restent d'utilisation relativement marginale et presque uniquement pour l'usage interactif. La seule explication que j'y trouve est le problème du déploiement que j'évoque dans le commentaire auquel tu réponds: les solutions les plus faciles sont soit d'utiliser ce qui est déjà là soit d'utiliser un langage plus complet qu'on connaît bien et qui permet de programmer concisément, comme par exemple OCaml, Common Lisp, Python, Perl, Ruby, TCL, ou autre...
Je sens qu'a ce moment on va me dire, "oui donc pourquoi c'est mieux que bash", moi, je vais répondre parce que:
À mon avis ce n'est pas du tout la question qui se pose, je pense que tout le monde sera d'accord pour dire que Gufo est mieux que bash, puisque bash est assez limité comme langage de programmation: encore une fois le problème c'est le choix d'une solution par un programmeur qui veut décrire un traitement sur une machine: si je connais bien Bourne et perl disons, qu'est-ce qui me pousserait à apprendre et installer gufo au lieu de soit utiliser Bourne qui est déjà là soit si mon programme est plus complexe, installer perl et toutes les libraries dont j'ai besoin pour programmer ma solution?
2) bash ne dispose pas de vrai fonction (je crois que toute les variables sont globales ou des choses comme ça).
C'est inexact, il y a deux mécanismes qui permettent de limiter la portée des variables: le mot clef local et l'exécution d'un sous-shell.
[^] # Re: Rashell
Posté par Michaël (site web personnel) . En réponse au journal Gufo: un langage de shell moderne!. Évalué à 4.
Oui bref, c'est un peu longuet et tout par rapport au shell, mais l'avantage c'est qu'on a un vrai langage de programmation (but recherché). Si la concision est vraiment importante on peut se poser la question d'écrire un PPX – ce qui est a priori bien plus simple que d'écrire un langage complet!
Je comprends bien, mais il ne faut pas perdre de vue qu'il y a une longue histoire de remplacements au shell qui sont tous de façon tout à fait défendable mieux que le shell de Bourne (le /bin/sh historique) mais en pratique ils restent d'utilisation relativement marginale et presque uniquement pour l'usage interactif. La seule explication que j'y trouve est le problème du déploiement que j'évoque dans le commentaire auquel tu réponds: les solutions les plus faciles sont soit d'utiliser ce qui est déjà là soit d'utiliser un langage plus complet qu'on connaît bien et qui permet de programmer concisément, comme par exemple OCaml, Common Lisp, Python, Perl, Ruby, TCL, ou autre...
À mon avis ce n'est pas du tout la question qui se pose, je pense que tout le monde sera d'accord pour dire que Gufo est mieux que bash, puisque bash est assez limité comme langage de programmation: encore une fois le problème c'est le choix d'une solution par un programmeur qui veut décrire un traitement sur une machine: si je connais bien Bourne et perl disons, qu'est-ce qui me pousserait à apprendre et installer gufo au lieu de soit utiliser Bourne qui est déjà là soit si mon programme est plus complexe, installer perl et toutes les libraries dont j'ai besoin pour programmer ma solution?
C'est inexact, il y a deux mécanismes qui permettent de limiter la portée des variables: le mot clef
localet l'exécution d'un sous-shell.