[gull] {Content?} Re: Truc et astuces: bash connector

[Laurent Franceschetti]

Je vous comprends tout à fait votre point de vue et je l’admire. S’il n’y avait pas le désir de se dépasser, il n’y aurait personne pour faire de la moto ou de l’escalade — ou pour innover quoi que ce soit en logiciel libre!

> Parce que shell a ses applications. En particulier, l'administration
> système implique shell. Que ``bash'' est l'un des plus répandus et
> reste tres utile pour toutes les tâches liées aux fichiers, montages,
> interaction avec des applis, etc...
> 
> Bash est interactif, cette démo est réalisable en ligne de commande,
> les sous-process restent ouverts, accessibles et efficaces...


Je suis entièrement d’accord avec vous et ce n’était pas du tout le sens de ma remarque (veuillez me pardonner si ça été perçu comme ça). Le shell est un élément fondamentaux de l’écosystème Unix et c’est le liant de la mayonnaise.

Dans le cas particulier, j’ai recouru à Python comme outil du shell, comme si ça avait été awk. C’est la raison pour laquelle mon script a été écrit pour être appelé en ligne de commande (il lit le fichier d’entrée). Et vous noterez que les données sont imprimées sur la sortie standard, alors que le temps d’exécution a été envoyé sur stderr. La raison est que je veux pouvoir mettre ce programme dans une séquence de pipes.

J’irais même plus loin: plus j’écris d’utilitaires, plus je pense à l’interaction avec le shell. Raison pour laquelle j’intègre des paramètres de ligne de commande (le package argparse <https://docs.python.org/3/library/argparse.html> est un vrai bonheur, et en quelques minutes j’ai mes paramètres obligatoires et optionnels ET un help qui tient la route). 

Je ne suggère pas une seule seconde que quiconque renonce à son expertise indispensable du bash. Dans l’administration système, Python doit être utilisé comme un outil de scripting d’une puissance considérable (comme j’ai pratiqué aussi Perl, je peux dire que Python est plus productif pour moi). La raison est qu’il permet de très fortes abstractions qui s’adaptent à ma façon naturelle de penser (il y des briques pour à peu près tout ce qu’on peut imaginer), et donc je peux écrire en quelques minutes ce qui pourrait prendre des heures en Perl ou bash… et le programme est très WORM (Write once read many).

Mais quand il s’agit de faire des utilitaires rapides, je n’hésite pas à recourir au piping et aux scripts shells, parce que ça va plus vite.

Bref, je préconise une approche pragmatique et respectueuse de l’environnement...

Bien à vous,
L.







> Le 16 févr. 2018 à 07:59, felix <felix at f-hauri.ch> a écrit :
> 
> Re,
> 
> On Thu, Feb 15, 2018 at 11:25:04PM +0100, Laurent Franceschetti wrote:
>> Désolé si je passe pour un Philistin, mais pourquoi ne pas faire ça en
>> séquentiel et en Python? 
> 
> Parce que shell a ses applications. En particulier, l'administration
> système implique shell. Que ``bash'' est l'un des plus répandus et
> reste tres utile pour toutes les tâches liées aux fichiers, montages,
> interaction avec des applis, etc...
> 
> Bash est interactif, cette démo est réalisable en ligne de commande,
> les sous-process restent ouverts, accessibles et efficaces...
> 
> Si je l'avais fais en perl, c'aurait été nettement plus rapide egallement!
> Python est bien pour developper ou prototyper des applications...
> On aurait pu le faire en PHP ou javascript, mais ce n'est pas le propos.
> 
> Avec ce système, mon script passe de 120" à 8", en restant bash!
> Ceci démontre assez bien le coût des forks.
> 
> J'ai déjà gagné 112 secondes sans changer de language, alors si
> pour gagner 2 secondes supplémentaires, je dois passer à Python...
> 
> -- 
> Félix Hauri  -  <felix at f-hauri.ch>  -  http://www.f-hauri.ch
> _______________________________________________
> gull mailing list
> gull at forum.linux-gull.ch
> http://forum.linux-gull.ch/mailman/listinfo/gull
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20180216/efdf9636/attachment.html>