Re: getopt(1)

bash fais aussi bien que python avec un script bash qui consiste à donner un code à manger à cpython

Je pense d’abord aux utilitaires tels que bc ou find, pour ne citer que ceux-là, qui sont définis dans POSIX et pas implémentés en Python. Je considère qu’il font parti du « langage » au sens large. Comme par exemple la bibliothèque "sys" fait partie de Python.

Le shell a été pensé comme un outil destiné à articuler ces autres programmes (les articuler autour du noyau), programmes implémentés en C pour des raisons évidente de performance. Je ne t’apprends rien.

Si tu utilise un binaire écrit en C ou autre langage, ou un script dans un autre langage, serait-ce du python, tu ne cesses pas pour autant de « faire du shell ».

Dirais-tu que tu cesses de faire du Python si tu utilises numpy ?

La différence que je vois c’est qu’en Bash tu appelles rarement d’autres outils « pure bash », au contraire de Python où tu vas trouver des bibliothèques « pure Python » (paramiko par exemple). Mais ça finira toujours par exécuter du C à un moment (cpython et bash étant eux-mêmes implémentés en C), même de l’assembleur si on continue le raisonnement... je ne trouve pas que ce genre de considération a le moindre de sens pour distinguer les deux langages. Ah si, peut-être celle-ci : pour reprendre l’exemple de paramiko, vu que c’est implémenté en Python tu peux modifier ce composant tout en continuant à à « parler Python », tu peux surcharger par exemple. Et voilà comment on en arrive à ce que je disais : des scripts Pythons qui pètent à un moment donné parce que celles et ceux qui l’ont écrit ont surchargé telle ou telle bibliothèque et que les chances que cette surcharge résiste à l’évolution de la bibliothèque s’amenuisent avec le temps, d’où on se retrouve avec des requirements.txt longs comme le bras.

Évidemment on peut faire le « sagouin » tout pareil en shell en faisant reposer son script sur un binaire à telle version ou compilé avec telles options, on peut... mais :

• Bash n’incite pas à cela puisque ça implique soit de compiler du C, soit « faire du Python » ou autre

• Je pense qu’on peut comparer la stabilité de l’interface du binaire ssh, mise en œuvre de référence de libssh (ie: OpenSSL en pratique bien souvent...) et livré avec celle-ci, et la stabilité de l’interface de paramiko, je ne suis pas sûr que paramiko soit aussi figé (quoi qu’aujourd’hui j’ose espérer que c’est plutôt le cas) que le premier.

Donc pour conclure, l’un dans l’autre, Perl, Python et Bash (leurs écosystèmes) ont des différences d’architecture mais fondamentalement aucune : ce sont des langages interprétés, point barre. C’est juste que le « système d’import » de Bash c’est... le systèmes de fichiers ! ;)

tu as pour chacun pleins de façons de t'en sortir ou de te tirer une balle.

D’accord suivant ce que je viens de dire, mais le danger de balle dans le pied n’est pas de même nature je dirais.

Si je sais que je vais partir dans un contexte ou je ne veux pas m'embêter avec les dépendances au déploiement j'utilise des binaires statistiques et je n'ai plus qu'à vérifier la libc.

Et voilà comment un Pythonien se retrouve à faire du shell ! ^^

Avec assez d’ouverture d’esprit je pense d’ailleurs qu’on pourrait utiliser Python ou Perl comme on utilise Bash, comme shell interactif pour les opérations quotidiennes, manuelles, comme regarder le contenu d’un répertoire, supprimer un fichier, etc... Ce qui montre bien que les trois ne sont fondamentalement pas différents.