Re: getopt(1)

J’ai écrit un seul script « pour de vrai » en Perl et ce n’était pas pour une autre raison (ie: ce choix de Perl plutôt que Bash ou Python) que m’initier à ce langage dont je sais à sa réputation que c’est un langage qui compte. Je ne savais pas que Perl ne faisait « aucun fork » (sauf j’imagine dans le cas où tu veux avoir du parallélisme, et comme tu l’indiques, pour appeler un autre programme évidemment), je note cet aspect.

tu n'es pas sûr que [ soit un builtin, ça peut très bien utiliser /usr/bin/[.

D’où la recommandation d’utiliser systématiquement [[. Ou c’est pour une autre raison ? je ne sais plus, peut-être pour une autre raison mais sauf erreur c’est recommandé d’utiliser [[ systématiquement.
Par ailleurs en Bash (je ne sais pas pour ksh et zsh mais il y des chance qu’il en soit de même) tu peux t’assurer que [ et test appellent bien les built-in avec la commande enable.

Vraiment si le coût du fork t'es insupportable, rend-toi service, apprend perl.

Comme je te disais je m’y suis initié, je connais les grands principes et si je dois faire du Perl ça ne me pose aucun problème, c’est un beau langage. C’est pas comme si je me retrouvais obligé de faire du PowerShell par exemple (et ça m’est arrivé, je ne dis pas ça gratuitement selon un bête préjugé). Maintenant, je préfère le paradigme "tout fichier" de Bash à la manipulation de pointeurs et je ne peux de toute manière pas explorer à fond les deux langages (surtout qu’il me faut du temps pour explorer le Chuck, qui est encore d’un type bien différent, et que j’ai très peu de chance de mettre en œuvre dans un contexte devops ^^ (mais qui sait...)).

Sans être insupportable, si on peut faire en Bash un traitement en 1 seconde (et que c’est un temps acceptable dans le contexte) au lieu de 10 (et qui serait un temps tout aussi acceptable dans le même contexte) en évitant des forks inutiles, le fait qu’on puisse faire ce traitement en 0,1 s en Perl, et que même à 10 secondes tout le monde est content, ce n’est pas une raison ni pour passer à Perl ni pour se foutre que son script Bash en prenne 10. Et j’ai bien conscience du caractère légèrement maniaque de cette philosophie. Tout comme des problèmes que peut poser un souci d’optimisation précoce.

Pour tout te dire, je suis en train de développer un programme, en Bash, sans cahier des charges très précis (c’est pas pour le boulot, c’est expérimental et a clairement le caractère d’un loisir) dont je sais, sans pratiquement aucun doute, que si j’arrive à un truc qui ressemble à l’idée flou que j’ai en tête, je devrais me heurter aux limitations de la vitesse d’exécution de Bash (pas réputé comme le plus rapide parmi les shells par ailleurs). Je verrai bien ce que ça donne mais je me dis que si à ce moment là je veux dépasser cette limitation, ce sera une excellente occasion de refaire du C, ou m’initier à un autre langage compilé (Rust par exemple, mais je pense que je partirai plus sur du C). Parce que si j’ai un programme en Bash qui fonctionne, j’aurais tout de même un prototype pour savoir où je veux aller avec mon programme en C. Et quitte à devoir manipuler des pointeurs... :)