Re: Perl or not Perl

Le point nazigrammar avant de poursuivre :
🆗 Je note aussi tout en majuscule pour le langage standardisé, et les commandes en respectant leur casse Unix (souvent tout en minuscule du coup), parfois la casse de titre pour évoquer une saveur particulière.
⛔️ L’autre standard est tout en majuscules aussi... pas en casse de titre et surtout jamais en minuscules (toute façon c’est un sigle ...et il ne viendrait à l’idée d’aucune personne de France et des environs Navarre d’écrire « sncf » ou « edf » par exemple.)

Et j'ajouterai que AWK faisant partie du standard Posix, cela en fait une dépendance sur laquelle on peut quasiment toujours compter, même dans des environnements restreints.

Attention, awk, c’est comme l’eau Cristaline, ce ne sont pas tous le même. Et certaines fonctionnalités utiles ne font pas partie de la version de base.

Je pense que quand on évoque le AWK portable c’est qu’on prend le dénominateur commun des saveurs existantes (Nawk, Gawk, Mawk, et d’autres.)
Et quand on évoque le AWK POSIX c’est qu’on s’en tient aux fonctionnalités standardisées par la norme (donc pas juste le standard de fait qui rend la fonctionnalité portable mais le cachet officiel)
Et du coup si on a besoin de fonctionnalités qui ne font pas partie de la version de base, bah on fait une petite fonction maison qui l’implémente et qui est livrée avec le code. Et au bout d’un moment on sait qu’il est temps de changer d’outil ;)

Comme le shell et contrairement à tous les autres langages de scripts.

C’est pire pour le shell. Si tu ne sais pas si ton script sera exécuté sur bash ou sur un vieux ksh même pas Posix (la dernière fois que j’ai essayé OpenIndiana, c’était le cas de son /bin/sh, pour ne pas casser la compatibilité de vieux scripts écrits il y avait déjà plusieurs décennies), ça limite beaucoup.

J’interprète le « Comme le shell » comme, dans la même logique, d’écrire en « shell POSIX » et donc avec des fonctionnalités garanties même s’il y en a moins et qu’elles peuvent être plus limitées que le supershell...
Donc soit ton OpenIndiana n’est pas vraiment un compatible Unix, soit son /bin/sh tout vieux Korn qu’il soit est compatible POSIX (en fait Ksh l’est —mais on va dire à 99.90% pour laisser une place à une éventuelle subtilité inconnue— tant que tu n’utilise pas de fonctionnalité qui lui soit propre)
Pour poursuivre, "$*" et "$@" ne sont pas des bashismes mais bien des trucs exigés par POSIX. Et non, les deux sont utiles (même si toi tu n’as « réellement » besoin que d’un cas) :

C’est moins logique par rapport à la syntaxe, mais c’est le comportement dont on a réellement besoin.

Revenons un peu en arrière et au sujet.

Je regrette vraiment qu’AWK ait été cantonné à du parcours de fichier. À mon sens, il aurait mérité de remplacer le shell.

Justement non... Le besoin n’était pas d’avoir un autre shell mais juste un outil à utiliser avec les autres shells (Thomson, Bourne, C, Korn, qu’importe)
Ça ne fait que du traitement de fichiers et ça le fait bien, sans devoir s’emmerder avec tous les autres aspects que doit gérer le shell (copier et déplacer des nœuds du système de fichiers, passer des arguments entre des commandes, créer et supprimer des entrées dans le système de fichiers, plein d’autres choses en se préoccupant chaque fois des autorisations d’accès et des différents flux connectés par chaque usager du système.)

Oui, enfin au delà de la substitution, sed devient vite ésotérique (un peu entre les CSS et la configuration de sendmail).

CSS n’a rien d’ésotérique :)
Et sed est très bien quand on l’utilise pour ce pour quoi c’est prévu : c’est juste l’éditeur de texte ed en mode non interactif et sur un flux (la première lettre est pour stream) et non un bout de périphérique bloc... Donc ça fait beaucoup plus que juste de la substitution, et plus simplement que beaucoup d’autres alternatives que j’ai vu par la suite.
Et sinon, tu peux faire de la substitution pareillement avec AWK ...ou ton langage de script favori.

Le problème, c’est que parfois les besoins évoluent.
[...]

Utiliser le bon outil qui répond au besoin du moment. Ne pas optimiser prématurément (s’applique aussi au fait de vouloir adresser trop tôt des besoins dont on ignore l’existence.)
Jean est fier de son vélo qu’il utilise pour faire ses courses. Paul lui explique que les besoins vont évoluer et qu’en plus il est fort probable que la guerre fasse des jolis sentiers des tas de ruines. Donc il lui préconise de laisser tomber le vélo et de s’équiper en char...

"It is seldom that liberty of any kind is lost all at once." ― David Hume