Perso, comme certains ont déjà pu le remarquer vu que j'en poste de temps en temps ici, j'utilise beaucoup Bash (plus ses amis type sed et compagnie) pour les p'tits scripts faits à l'arrache.
Grosso modo, ce que j'apprécie, c'est que ça se prête bien à une approche incrémentale. On peut faire des trucs déjà utiles et fonctionnels directement sur la ligne de commande, et c'est comme ça que ça commence en général, avec un simple "one-liner". Parfois ça en reste là (j'en fais juste un alias), et parfois ça grossit parceque je l'améliore petit à petit, et alors, pour l'éditer plus facilement, je le colle dans un fichier et je l'indente. Voilà, un script crade est né.
Éventuellement, si il mérite d'être partagé, je le nettoie et complète encore un peu jusqu'à en faire un vrai programme présentable, avec des options et tout et tout. Et aboutir ainsi à des "vrais programmes" en Bash, c'est possible : prenez
media-sound/abcde par exemple, il est super bien fini, non ? Pourtant, je m'avance un peu mais je doute que son auteur visait, quand il a écrit la première ligne du code, à faire le rippeur de CDs ultime. À mon avis, il est plutôt parti de quelques one-liners à usage personnel, et il a brodé autour pour en arriver là.
Le deuxième langage que j'utilise pour les p'tits scripts, c'est Python. Par rapport à Bash et ses amis, l'inconvénient est qu'on doit tout de suite faire un "vrai" script, que c'est souvent plus verbeux pour des choses très simples en Bash/grep/sed/etc. Mais on gagne un langage plus puissant, avec notamment des structures de données difficiles à feindre en Bash. Donc selon les cas, on peut avoir :
- des oneliners bash/sed/etc. qui demandent 30 lignes de code pour être faits en Python ;
- des opérations simples de Python sur des structures complexes (des dictionnaires de listes de tuples, ou que sais-je), qui demande 10 lignes, 5 evals et 12 pipes pour être faits en Bash.
Et puis avec Python, on a accès à plein de modules super utiles pour éviter de réinventer la roue. Pour un gentooiste par exemple, un "
import portage" vaut souvent bien des
find,
grep ou autre
sed sur les fichiers de
/usr/portage ou
/var/db/pkg.
Bref pour moi, Python ou Bash, ça dépend des besoins... Je choisis plutôt Python quand je sens que les choses ne pourront pas rester simples bien longtemps au niveau des structures de données, ou quand j'ai besoin d'un module spécifique. Le pire évidemment, c'est de se planter sur ce choix et de se rendre compte qu'on doit recoder en Python un truc commencé en Bash.
Quant à Perl, je peux pas en dire grand chose, j'ai jamais vraiment appris. Mais du peu que j'en connais et des utilisations que j'en vois de ci de là, je pense que c'est un bon candidat pour concurrencer à la fois les scripts Bash et les scripts Python :
- l'accès aux fichiers texte et les opérations sur chaines de type grep/sed/etc. y sont beaucoup plus concises qu'en Python, donc il permet probablement de faire, sans exploser le nombre de lignes de code, ce que moi j'aurai tendance à faire en Bash.
- il se prête aussi assez très bien aux one-liners (comme Bash, et contrairement à Python).
- les structures de données complexes ou les modules utilitaires valent ceux de Python, donc là non plus, pas de soucis.
Bref, ça pourrait bien être le langage qui réconcilie tous les usages du quick hack, mais bon, je crois que je ne le saurai jamais avec certitude, parceque sa syntaxe n'est vraiment pas à mon goût, et que j'ai pas envie de faire des efforts pour apprendre un truc dont je n'ai pas réellement besoin (ayant déjà le Bash et le Python dans ma besace).
Et enfin, pour l'anecdote, récemment j'ai vu un utilisé OCaml pour un machin que typiquement moi j'aurais fait en Python :
http://www.linux-france.org/lug/gullive ... 00361.html
Et bah en fait, là ça s'y prêtait pas mal. Enfin je suis pas sûr que ça ait été le meilleurs choix possible non plus, mais disons que ça n'était pas complètement absurde : le programme est lisible (suffisament pour que j'envoie qlqs patchs à l'auteur alors que je n'avais pas fait d'OCaml depuis très longtemps), et pas trop long pour ce qu'il fait, donc bref, pourquoi pas...