Citation
youp
et j'aimerais savoir comment récupérer le premier caractère de la liste

A mon avis, il faut éviter de coder ça en shell! Tu pourrais bien sûr utiliser sed sur chaque mot, mais ce n'est pas raisonnable....

Pourquoi n'utilises tu pas un vrai langage de script (Ruby, Perl, Python, Ocaml, Lua, ...) pour ça?

Je crois vraiement que pour ce genre de tâche, un script en shell est péniblement faisable, mais ce n'est pas raisonnable de le coder en shell (bash ou zsh ou même Posix shell)?

Pourquoi t'interdis tu d'utiliser un autre language de script?

On peut théoriquement tout faire en shell -ou dans tout langage Turing complet- mais ce n'est pas raisonnable. Par exemple, ce n'est pas sans raison qu'aucun compilateur C ou SGBD n'est écrit en shell... C'est possible, mais ce n'est pas sensé!

Pour moi, le shell doit être restreint à des petits traitements simples, qui enchainent des commandes... Le shell ne doit pas être la panacée universelle, et quand on se pose la question de comment faire un traitement non trivial en shell, c'est qu'il est temps de passer à un autre langage.

Pourquoi n'essaies tu pas de coder ton programme en Ruby par exemple?

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 12 December 2006 17:52:40

Citation
youp
et j'aimerais savoir comment récupérer le premier
caractère de la liste

Pour récupérer le premier caractère de quelque chose (quoi que ce soit)

recup=`echo <le_quelquechose_en_question> |cut -c1`

L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Tuesday 12 December 2006 19:58:21

Citation
Sve@r
Pour récupérer le premier caractère de quelque hose (quoi que ce soit)
recup=`echo le_quelquechose_en_question |cut -c1`

C'est exact que ça fonctionne, mais:

d'abord, ce n'est pas évident,

et surtout, ca fait créer au moins un (et plutot deux) processus à chaque caractère ainsi calculé. Il y a donc un processus créé pour cut par caractère (et en fait deux, car l'antiquote fork un shell).

Je crois que ça illustre bien mon propos sur le shell. On peut tout faire avec, mais ce n'est pas l'outil approprié (car la solution est peu lisible et inefficace).

L'avantage des langages de scripts, c'est qu'ils ont été conçus pour faire des scripts, pas seulement pour lancer des programmes!




Très heuristiquement:

pour une application qui tient en une douzaine de lignes de shell (et développée en moins d'une demi-heure) et dépend de plusieurs autres programmes, on peut coder en shell

pour une application plus conséquente (jusqu'à mille lignes et moins d'un mois de développement), un langage de script (celui avec lequel on est à l'aise et qui offre des bibliothèques pour nos besoins)

au delà, un langage de programmation compilé (si possible avec inférence de types)


Bien sûr que je caricature et que je simplifie à outrance ....
Mais il est important de bien choisir son outil (donc le langage) quand on développe, que ce soit un petit truc de 10 minutes ou un effort de plusieurs années!



----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 12 December 2006 20:23:48

Avant de proposer une solution bash, je voudrais faire une petite remarque à Basile STARYNKEVITCH qui à chaque intervention propose systématiquement d'apprendre un autre langage, sans jamais proposer une solution au problème dans un langage alternatif.

Tu n'utilises jamais le shell script ? soit ! c'est un choix, mais le shell script bash est un langage de script puissant, rapide et multi-fonctionnel ! A l'image des outils petits outils spécialisé de Unix.


Il est très adapté à beaucoup de taches différentes et fait partie des outils standard de tout administratreur unix.

Pour faire avancer les choses sur chaque post, soit tu arrêtes ce déni systématique du shell script, soit tu proposes une solution dans un autre langage de ton choix.

La solution SHELL

echo ${liste[index]:0:1} # index 0, longueur 1

--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Tuesday 12 December 2006 20:51:13

Citation
Basile STARYNKEVITCH
d'abord, ce n'est pas évident,

Tout dépend de sa connaissance du langage. L'enchainement de commandes via des tubes et la commande cut sont des outils basiques et indispensables pour pouvoir faire un peu de développement shell.

Citation
Basile STARYNKEVITCH
Je crois que ça illustre bien mon propos sur le
shell. On peut tout faire avec, mais ce n'est pas
l'outil approprié (car la solution est peu lisible
et inefficace).

L'avantage des langages de scripts, c'est qu'ils
ont été conçus pour faire des scripts, pas
seulement pour lancer des programmes!

Un script shell a des qualités que n'ont pas python, ruby,...
L'utilisation du shell (POSIX) permet de développer pour quelque soit l'unix/linux de destination sans avoir à installer un langage de plus. C'est très appréciable quand on travaille sur des unix propriétaires et des linux divers et variés.
On pourrait installer l'interpréteur sur les différentes machines, mais selon l'utilisation que l'on fait, c'est lourd à mettre en place (surtout quand on a des unix qui datent d'il y a longtemps).

Le shell est également plus lisible. Il est plus facilement lisible et maintenable : au sein d'un service informatique, les compétences en shell sont souvent plus nombreuses que du python. Il est mieux d'utiliser un langage compréhensible par la majorité.

Citation
Basile STARYNKEVITCH
A mon avis, il faut éviter de coder ça en shell! Tu pourrais bien sûr utiliser sed sur chaque mot, mais ce n'est pas raisonnable....

Pourquoi n'utilises tu pas un vrai langage de script (Ruby, Perl, Python, Ocaml, Lua, ...) pour ça?

Je dirais que ça dénote plutôt une méconnaissance du shell. A quoi sert-il si il est déjà trop compliqué pour des traitements simples? Le genre de traitement ici est une chose typique pour laquelle le shell est un bon choix.
Le "la solution est peu lisible" montre ta méconnaissance du shell, car, je le répète, ce qu'a écrit sve@r est très basique.
Je te conseille d'ailleurs son cours pour apprendre un peu plus comment fonctionne le shell.

Enfin, pourquoi le shell n'est pas un vrai langage de script?

Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

Poste le Tuesday 12 December 2006 20:55:45

Si j'utilise le shell, mais pour des choses simples (backup, ....).

De manière générale, je ne code pas de gros scripts shells. Au delà d'une ou deux douzaines de lignes, je passe à autre chose. Et je ne fais jamais de traitement de caractères (ou algorithmiques) non triviaux en shell.

Les seuls scripts shells de plus de 20 lignes que je fais sont des scripts séquentiels (un peu comme certains scripts configure non générés par autoconf).

Enfin, et c'est à mon sens rédhibitoire, un script shell ne peut pas être analysé sans être exécuté.

Et je trouve absurde de forker un (ou deux) processus à chaque caractère traité.

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 12 December 2006 21:15:11

Citation
oudoubah
Je te conseille d'ailleurs son cours pour apprendre un peu plus comment fonctionne le shell.

Je l'ai lu, et j'ai autrefois été (sur SunOS4) un adapte de gros shell scripts (et j'avais même animé de la formation dessus). Ça m'a passé [v]et j'ai oublié certains détails[/v]. Et coder des shells scripts portables est difficile!

Citation
oudoubah
Enfin, pourquoi le shell n'est pas un vrai langage de script?

Parce qu'en soi, le shell n'existe pas, il s'appuie sur les nombreux programmes usuels (ou normalisés) dans /bin /sbin ou /usr/bin.

Voilà un contrargument: dans un environnement chrooté avec comme seul exécutable le shell lui-même, tu ne fais pas grand chose (par exemple tu ne pourrais pas faire un serveur Web). Dans le même environnement avec comme seul exécutable un python, un ruby, ou un Ocaml, tu fais bien plus.

Dis autrement, tu ne peux pas écrire l'équivalent de ls ou wc en bash (sans utiliser aucun programme extérieur). Et tu peux le faire dans un langage de script.

Et d'expérience, la maintenabilité de gros scripts shells sur des équipes de plusieurs développeurs, je n'y crois plus.

Et comme je le disais tout à l'heure, il n'y a pas de gros programmes (compilateur, SGBD, serveur Web réaliste, démonstrateur de théorème, traitement de texte, ...) écrit en shell. C'est symptomatique et significatif.




----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 12 December 2006 21:29:23

Citation
Basile STARYNKEVITCH
Enfin, et c'est à mon sens rédhibitoire, un script
shell ne peut pas être analysé sans être exécuté.

pas moins qu'un autre... si on connait le shell et l'autre langage de script.

Quelque soit le langage, le script doit être commenté pour être repris facilement plus tard.

Citation
Basile STARYNKEVITCH
Et je trouve absurde de forker un (ou deux)
processus à chaque caractère traité.

Je crois que tu n'as pas lu la solution de Frédéric : simple et efficace et beaucoup plus simple : on n'a pas besoin d'apprendre tout un langage, mais seulement une syntaxe. Honnêtement, quel est le plus compliqué?

Toujours rediriger sur un nouveau langage alors que le shell est le plus commun, utilisé et compréhensible par la majorité est le meilleur moyen de décourager quelqu'un qui apprend.

Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

Poste le Tuesday 12 December 2006 21:32:34

Quand je parlais d'être analysé, je voulais dire automatiquement. (Et c'est vrai que certains languages de scripts ont aussi du mal à l'être).



----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 12 December 2006 21:36:33

Citation
Basile STARYNKEVITCH
Et coder des shells
scripts portables est difficile!

Tout dépend des connaissances que l'on a! Au boulot, la plupart des scripts que je suis amené à créer doivent fonctionner sur du linux (de la red hat 8 à celle de nos jours), et du SCO. A la maison, je bosse indifféremment sur du linux que du Solaris.

Citation
Basile STARYNKEVITCH
Et comme je le disais tout à l'heure, il n'y a pas
de gros programmes (compilateur, SGBD, serveur Web
réaliste, démonstrateur de théorème, traitement de
texte, ...) écrit en shell. C'est symptomatique et
significatif.

C'est normal, ce n'est pas l'objectif du shell!
Coder un gros programme en langage de script est une absurdité, que ce soit en shell, ruby,... Ce n'est pas fait pour!

Apprendre et utiliser un autre langage, c'est passer beaucoup de temps pour souvent ne rien gagner (avoir dans sa poche un autre outil plus orienté texte peut être néanmoins utile).

Comment tu fais pour faire fonctionner ton script quand tu n'as pas les librairies et l'interpréteur pour? Et quand tu as l'interpréteur, mais qu'il te manque une librairie?

Avec mes commandes unix standard, je n'ai aucun soucis : ça fonctionnera où je serai.

Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

Poste le Tuesday 12 December 2006 21:50:15

Citation
oudoubah
Coder un gros programme en langage de script est une absurdité, que ce soit en shell, ruby,... Ce
n'est pas fait pour!

Et pourtant, il existe des gros programmes codés en Perl, en Tcl (hélas!), en Ruby, en Python, en Scheme, en Ocaml, en Lua. (mais très peu en shell). Et PHP est à mon sens un langage de script aussi, et on y code des grosses applications....

Par gros, je veux déjà dire plusieurs milliers de lignes. Par exemple, il y a peu (je n'en connais pas, mais il devrait s'en trouver quelques uns) de shell scripts de plusieurs milliers de lignes sur une Debian (sauf les truc très séquentiels genre configure; et encore, on peut considérer que l'existence d'autoconf illustre une faiblesse du shell). Mais on y trouvera des scripts en Python, en Perl, et probablement Ruby.... de cette taille.

Bref, je connais le shell (et c'est vrai que j'en oublie rapidement certaines subtilités, car je ne m'en sers peu) - d'ailleurs je préfère le zsh à bash - mais je ne l'aime guère (et c'est par expérience).

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 12 December 2006 22:07:17

Par définition, un langage de script est lent. Il y en a peut être qui font de grosses applications avec, mais c'est inadapté. J'avais eu connaissance d'un compilateur fait en shell, uniquement pour démontrer que c'était techniquement possible. Il y a eu également un résolveur de sudoku en awk. C'est inadapté car trop lent pour ce genre de tâches (comme les autres langages de script).

Citation
Basile STARYNKEVITCH
Bref, je connais le shell (et c'est vrai que j'en
oublie rapidement certaines subtilités, car je ne
m'en sers peu) - d'ailleurs je préfère le zsh à
bash - mais je ne l'aime guère

Ce n'est pas, amha, une raison pour systématiquement rediriger vers un autre langage alors qu'un posteur attend une réponse à son problème. Dans ce cas, mieux vaut ne pas répondre. Lui dire d'apprendre un langage et que le shell est du brin (chose qui n'engage que toi) n'est pas constructif, surtout pour le posteur. La réponse stéréotypée "utilise Ruby, Lua ou Ocalm" ne résoudra pas le problème du posteur. Il attend une vraie réponse (qui peut venir, ou pas) pour résoudre son problème et progresser. Je doute qu'un "va apprendre un autre langage" ne l'aide ni soit ce qu'il fasse.

Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

Poste le Tuesday 12 December 2006 22:51:34

Je suis tout à fait d'accord avec oudoubah ^^D-*

Quand tu dis que tu "connais" le shell script, tu parles de sunOS 4 qui à sorti sa dernière version en 1994 ( la première date de 1989 ) qui depuis lors ont pas mal évolués !

Tu n'aimes pas le shell ? Rien ne t'empêche de proposer une solution dans le langage de ton choix. je suis persuader que les "débutants" vont se ravir de réinventer la roue pour faire un sort ou un selection dans un fichier

--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Wednesday 13 December 2006 12:30:30

Citation
Frédéric Brugmans
Quand tu dis que tu "connais" le shell script, tu
parles de sunOS 4 qui à sorti sa dernière version
en 1994 ( la première date de 1989 ) qui depuis
lors ont pas mal évolués !

Tu exagères un peu à me taquiner ainsi. J'ai intensivement pratiqué le shell il y a longtemps, mais depuis ça m'a passé, je fais du shell à dose homéopathique.

Je dois faire quelques shell scripts (de moins de 20 ou 30 lignes) par mois. Mais depuis fort longtemps, j'ai appris que quand je passe plus de 10 minutes sur un shell script, il est temps (pour moi) de le coder en entre chose.

je patch aussi quelques gros scripts autoconf-esques (ceux de GCC pour ne rien te cacher). Et je trouve ça très pénible: c'est mal documenté, ca me prend du temps, et déboguer ce genre de truc prend une demi-heure pour chaque essai.

je dois dire aussi que je n'ai jamais été sysadmin à temps plein, je l'ai été autrefois à temps partiel sur un réseau de quelques douzaines de stations (et j'ai trouvé cette tâche ingrate, surtout pour des raisons sociales...) - et je le suis évidemment sur la poignée de machines dont je dispose. Je suis plus à l'aise et plus heureux à coder des applications assez grosses (ou à y contribuer) qu'à passer ma vie à coder chaque jour un nouveau script.

Et par dessus tout, apprendre un nouveau formalisme ou langage est agréable pour moi...



----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Wednesday 13 December 2006 20:27:16

Citation
oudoubah
Par définition, un langage de script est lent.

Plus ou moins lent. Le shell est obligé de forker un processus pour presque chaque opération, et ne fournit pas des structures de données ni des mécanisme de modulatités intéressants (autre que les chaines et les tableaux de chaines pour les données, et les scripts et fonctions pour la modularité). Un interprète (comme Ruby, Lush, Tcl, Perl ...) est capable de representer un arbre de syntaxe interne, fournit des structures de données plus puissantes (tables associatives arbitrairement imbriquées), applique les primitives du langage plus rapidement. Certains interprètes (Lua, Ocaml, Gnu Clisp) traduisent le code en une représentation code octet très rapidement interprètable, et certains le compilent même à la volée vers du C ou du code machine.
Par exemple, SBCL traduit le texte d'une fonction interactivement tapée en code machine. En réalité, toute implémentation peut être plus ou moins compilée ou interprétée, et il y a un continuum entre ces 2 extrèmes. Même le langage C a (dans la plupart de ses implémentations) dans sa fonction printf un interprète (la routine qui parse les formats).

Citation
oudoubah
Il y en a peut être qui font de grosses applications avec, mais c'est inadapté. J'avais eu connaissance d'un compilateur fait en shell, uniquement pour démontrer que c'était techniquement possible.

J'ai vaguement entendu parler de ça aussi mais je n'ai aucune référence, et je serais ravi d'en trouver une. En connais tu?


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Wednesday 13 December 2006 20:55:45

Citation
Basile STARYNKEVITCH
oudoubah a écrit : Il y en a peut être qui font de
grosses applications avec, mais c'est inadapté.
J'avais eu connaissance d'un compilateur fait en
shell, uniquement pour démontrer que c'était
techniquement possible.

J'ai vaguement entendu parler de ça aussi mais je
n'ai aucune référence, et je serais ravi d'en
trouver une. En connais tu?

L'archive s'appelle shasm.tgz. Par contre, je ne l'ai pas trouvée (les sites demandent soit un login password, soit sont HS). Cela date de 2001.
[www.linuxjunkies.org]

Citation
Basile STARYNKEVITCH
Je dois faire quelques shell scripts (de moins de 20 ou 30 lignes) par mois. Mais depuis fort longtemps, j'ai appris que quand je passe plus de 10 minutes sur un shell script, il est temps (pour moi) de le coder en entre chose.

je patch aussi quelques gros scripts autoconf-esques (ceux de GCC pour ne rien te cacher). Et je trouve ça très pénible: c'est mal documenté, ca me prend du temps, et déboguer ce genre de truc prend une demi-heure pour chaque essai.

je dois dire aussi que je n'ai jamais été sysadmin à temps plein, je l'ai été autrefois à temps partiel sur un réseau de quelques douzaines de stations (et j'ai trouvé cette tâche ingrate, surtout pour des raisons sociales...) - et je le suis évidemment sur la poignée de machines dont je dispose. Je suis plus à l'aise et plus heureux à coder des applications assez grosses (ou à y contribuer) qu'à passer ma vie à coder chaque jour un nouveau script.

Et par dessus tout, apprendre un nouveau formalisme ou langage est agréable pour moi...

Ne le prend pas mal, mais tu considères peut être à tort que tes préférences sont forcément les meilleures solution aux problèmes et que ce qui te plait plaira automatiquement aux autres. Lorsqu'on a un problème quand on fait un script shell, ce n'est pas adapté de devoir apprendre un nouveau langage.

Ton expérience est justement limitée par ce que tu as vu. <ma vie>je suis un des sysadmin d'un centre informatique multi-sites, avec 150 serveurs sur site + une centaine au total sur les sites distants(du windows NT4 à 2003, avec du SCO, du vieux linus et du neuf). Certaines machines (les linux, au hasard :-))) ont des contraintes d'haute disponibilité (serveurs de téléphonie). Tout autre langage sous unix/linux que le shell et les commandes unix n'est pas adapté, aussi bien pour les petites tâches d'administrations que certains développements</ma vie>
Si ton gros script est mal documenté, c'est de la faute à l'auteur, et non au shell (il ne sait pas encore générer spontannément les commentaires).



Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles
ou non. Lire la doc, c'est le Premier et Unique Commandement de
l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

Poste le Wednesday 13 December 2006 21:32:46

je dirais même n'importe quel code un peu volumineux non commenté / documenté n'est pas du "bon" code

--
Brugmans Frédéric

[www.brugmans.net]
[triathlon.sport-challenge.be]

Poste le Wednesday 13 December 2006 23:25:28

Citation
Frédéric Brugmans
La solution SHELL

echo ${liste:0:1} # index 0, longueur 1

Toujours d'une élégante simplicité. Faudra vraiment que je me mette à apprendre le bash. Le pb c'est que j'arrive toujours à tout faire en pur Bourne et que je ne tente jamais d'optimiser en bash...

Citation
Oudoubah
ce qu'a écrit sve@r est très basique

Totalement. Cela est la base de la programmation shell ou le grand principe est de dire "je délègue ce que je ne sais pas faire à un programme qui sait le faire et je récupère le résultat"

Citation
Oudoubah
Je te conseille d'ailleurs son cours pour apprendre un peu plus comment fonctionne le shell.

];-)

Citation
Basile STARYNKEVITCH
Parce qu'en soi, le shell n'existe pas, il s'appuie sur les nombreux programmes usuels (ou normalisés) dans /bin /sbin ou /usr/bin.

Ben non. Il existe mais son code est réduit au minimum. Des variables, des structures et c'est tout... PLUS son plus grand atout: la possibilité de déléguer aux autres programmes Unix TOUT ce qu'il ne sait pa faire par lui-même. Et je dis "Programme Unix" par généricité car rien ne t'empêche de créer ton propre programme en n'importe quel langage (C, C++ ou autre) qui sera lui-aussi utilisable par un shell. Seule contrainte: Afficher les sorties à l'écran. Ensuite le shell se chargera de récupérer cet affichage par les backquottes. Au détriment d'un fork, certes, mais les systèmes sont aussi un petit peu là pour bosser à notre place...

Citation
Oudoubah
Par définition, un langage de script est lent

Ca dépend de quel langage. J'ai eu un truc à faire en juin. Il s'agissait de transformer un fichier texte tabulé en XML et chaque ligne du fichier texte générait une quarantaine de ligne XML. Le fichier étant assez conséquent (50000 lignes), mon script le traitait en 1h30.

Ayant appris Python, je me suis mit dans l'idée de faire le même truc en Python. Une fois fait, mon script Python traitait le tout en 37 secondes !!!
Je présume que l'écart exponentiel tient dans la bufférisation des IO mais il n'empêche que Python est quand-même un langage de script...

Citation
Basile STARYNKEVITCH
Tu exagères un peu à me taquiner ainsi. J'ai intensivement pratiqué le shell il y a longtemps, mais depuis ça m'a passé, je fais du shell à dose homéopathique.

Sans déconner ? Moi je m'éclate à faire des trucs complètement fou en shell. Il y a quelque temps, je me suis même amusé à coder la division telle qu'on l'apprend au primaire. Je pose le diviseur, je calcule le quotient et le reste puis je descend le chiffre suivant etc. Le code assez long il est vrai mais totalement fonctionnel se trouve dans le cours dont parle Oudoubah.

Citation
Basile STARYNKEVITCH
Le shell ne fournit pas des structures de données ni des mécanisme de modulatités intéressants (autre que les chaines et les tableaux de chaines pour les données, et les scripts et fonctions pour la modularité)

Faut se replacer dans le contexte. Le shell n'est pas là pour faire de l'objet ou de l'évènementiel. Son but reste encore et toujours fournir un langage simple permettant d'automatiser les traitement d'administration de fichiers texte ou de log (car dans les Unixoides, tous les fichiers de config et/ou de log sont des fichiers texte). Et il n'a pas besoin de fournir tout ce que tu lui demandes puisqu'il peut le prendre là où ça se trouve. Le shell est probablement le langage du fainéant et c'est pour ça que je le trouve si extra...

Bon, je veux bien qu'on néglige le MsDOS qui ne sait absolument rien faire mais on ne peut pas négliger le shell sous prétexte que ceci ou que cela. Ca reste quand-même la base du programmeur Unix et son tout premier outil de communication avec le système et il présente, comme je l'ai dit, une puissante simplicité de programmation inégalée.
J'aurais pu aussi écrire ma commande en C++ mais je trouve que cela aurait été un trop gros investissement pour le résultat à obtenir.
Je ne dis pas non plus qu'il ne faut pas le faire en Ruby malheureusement je ne connais pas ce langage. J'aimerais aussi m'intéresser au zsh qui, à te lire, semble extra mais comme d'hab j'ai pas non plus le temps de m'y investir.
Mais comme le dit Brugmans, ce serait bien, la prochaine fois que tu as une solution dans un langage alternatif, de nous la proposer afin que ceux qui ne connaissent pas ce langage puissent comparer et, à la limite, leur donner envie de l'apprendre...

L'homme qui murmurait à l'oreille des pingouins
[fr.lang.free.fr]

Poste le Wednesday 13 December 2006 23:38:07

Bonjour,

Intéressant débat... :-)

Citation
Basile STARYNKEVITCH
Pour moi, le shell doit être restreint à des petits traitements simples, qui enchainent des commandes... Le shell ne doit pas être la panacée universelle, et quand on se pose la question de comment faire un traitement non trivial en shell, c'est qu'il est temps de passer à un autre langage.

Je ne crois pas que personne dise que le shell est la panacée universelle. Je suis bien d'accord que c'est lent à l'exécution et pas très mignon, pour reprendre en gros tes griefs.

Maintenant, je pense que c'est justement lorsqu'on admet ça qu'on peut être efficace en shell et faire beaucoup de choses. Un script devient énorme ? et bien il faudra apprendre à modulariser. C'est lent ? il va falloir évaluer la qualité de l'algorithme, les commandes utilisées, etc. En fait c'est comme dans n'importe quel langage, si le programme a un design pourri et des algo qui collent à l'interpréteur à force d'être touillés, ce sera ignoble à lire et inefficace.

Et c'est justement ce que j'aime avec le shell. Là où d'autres langages vont puiser dans les ressources de l'interpréteur pour compenser la faiblesse du code, le shell atteindra tout simplement ses limites, renvoyant au codeur le doux signal : tu codes vraiment comme un goret.

Donc, d'accord, si tu as des contraintes fortes en vitesse d'exécution, le shell est à proscrire. Mais si tu veux juste des temps d'exécution raisonnables, genre moins d'une seconde entre l'entrée et la sortie (hors éventuel temps d'affichage), tu peux déjà te permettre beaucoup de choses.

Citation
Basile STARYNKEVITCH
Mais il est important de bien choisir son outil (donc le langage) quand on développe

Oui, mais là c'est très subjectif :

1- Soit un niveau en programmation de 1 à 10, si on est de niveau 8 dans un langage et qu'une chose est de niveau 6 dans celui-ci alors qu'elle est de niveau 3 dans un autre langage qu'on ne connait pas, il est rationnel de prendre malgré tout le langage qu'on connait.

2- Plus on fait de choses difficiles dans un langage et plus on progresse car plus on est obligé de l'explorer. D'où quelque part, il est mauvais de changer chaque fois de langage parce qu'avec un tuto rapide on peut faire des choses qui seraient beaucoup plus avancées dans celui qu'on connaît.

3- Il faut apprendre les nouveaux langages, ce qui est un investissement de temps assez conséquent, parfois proche du sacerdoce si on veut acquérir un niveau fonctionnel (pour apprendre Ocaml tout seul, par exemple, faut se lever de bonheur :-))).

4- Il y a beaucoup de langage qui peuvent faire une même chose. Si donc on veut choisir, il faudra connaître ce qu'on veut globalement faire en programmation, ce qui n'est pas toujours évident.


Perso, je dirais qu'il faut d'abord choisir un langage qu'on aime et dans lequel on a le sentiment de progresser. En shell (qui est àmha un excellent candidat, déjà en ce qu'il n'empoisonne pas la vie du débutant avec des questions de typage dont il n'a pas besoin pour ses scripts de débutant) comme en n'importe quoi, on peut apprendre à bien coder. Après seulement se pose la question d'un deuxième langage lorsqu'on atteint les limites réelles (au delà des possibilité d'optimisation) du sien. Dans le présent topic, le problème posé est largement dans le scope du shell. :-)


PS. Pour le compilateur shell "shc", il est visiblement toujours maintenu ici (j'ai pas testé) : [www.datsi.fi.upm.es]

Poste le Saturday 16 December 2006 17:08:14