Et du coup si on a besoin de fonctionnalités qui ne font pas partie de la version de base [d’AWK], 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 ;)
Enfin comme Perl n’est pas plus compliqué qu’AWK pour ce que celui‐ci sait faire, si on prend Perl dès le début, on s’épargne justement le changement d’outil et la réécriture.
Donc soit ton OpenIndiana n’est pas vraiment un compatible Unix,
Ce n’est pas le mien, c’est la reprise open source de Sun Solaris.
Il est donc directement issu d’un Unix historique, contrairement à Linux, et à l’époque, Sun Solaris était certainement certifié POSIX (question de sous).
Je n’appréciais pas Sun Solaris à l’époque (si on l’aimait avant l’an 2000, il suffisait de tenter le « jumbo patch » an 2000 pour être vacciné) et pas tellement plus OpenIndiana, que je n’ai utilisé que pour des tests, mais on peut difficilement nier que c’est un Unix.
soit son /bin/sh tout vieux Korn qu’il soit est compatible POSIX
Non, en tout cas pas dans la version d’il y a quelques années, la dernière fois que je l’ai utilisé. C’était officiellement un vieux shell pourri conservé pour être bug compatible avec des scripts faits il y a plusieurs dizaines d’années...
Il lui manque par exemple les variables locales. Le truc, c’est qu’il y a un existant avant qu’on fasse une norme et que parfois, il en subsiste des bouts (voir la totalité : on attend toujours que les claviers Azerty s’alignent sur la norme).
OpenIndiana a bash installé par défaut, en /bin/bash. Mais si on compte sur /bin/bash, pour le coup, on se coupe des OS BSD où il n’est pas installé par défaut.
Il n’y a pas de /bin/posixsh. Si on veut distribuer un script qu’il n’y a juste qu’à rendre exécutable pour lancer, on doit se contenter de /bin/sh et il y a donc au moins un cas où il n’est pas POSIX. L’autre piste serait de chercher au début du script un shell décent sur le système et de relancer le script avec.
Pour poursuivre, "$*" et "$@" ne sont pas des bashismes mais bien des trucs exigés par POSIX.
Ah ? $@ n’était pas mentionné dans la doc à laquelle je me suis fié, mais ce n’était pas la norme officielle.
Il semble que maintenant la norme POSIX soit accessible en ligne gratuitement (pas comme celle pour le clavier français...). Si elle l’était déjà il y a quelques années, je ne m’en étais pas aperçu...
[AWK] ne fait que du traitement de fichiers et ça le fait bien
Oui. C’est le shell qui n’est pas terrible. Passage des arguments par chaîne de caractères uniquement, retour de commande ou de fonction uniquement par code d’erreur et sortie standard, ça gêne pour des besoins un peu complexes et c’est sujet à bugs.
Du coup, si on utilise Perl à la place pour avoir un vrai passage de paramètres, des valeurs éventuellement complexes en retour de fonctions, des objets, etc., et pour éviter d’avoir de grosses catastrophes parce qu’on a oublié de quoter une variable et qu’il est arrivé une valeur avec des espaces dedans... et bien on a plus besoin d’AWK.
[^] # Re: Perl or not Perl
Posté par _Laurent_ (site web personnel) . En réponse au journal écriture d'un script AWK de transformation de Markdown en HTML. Évalué à 1. Dernière modification le 07 décembre 2025 à 10:43.
Enfin comme Perl n’est pas plus compliqué qu’AWK pour ce que celui‐ci sait faire, si on prend Perl dès le début, on s’épargne justement le changement d’outil et la réécriture.
Ce n’est pas le mien, c’est la reprise open source de Sun Solaris.
Il est donc directement issu d’un Unix historique, contrairement à Linux, et à l’époque, Sun Solaris était certainement certifié POSIX (question de sous).
Je n’appréciais pas Sun Solaris à l’époque (si on l’aimait avant l’an 2000, il suffisait de tenter le « jumbo patch » an 2000 pour être vacciné) et pas tellement plus OpenIndiana, que je n’ai utilisé que pour des tests, mais on peut difficilement nier que c’est un Unix.
Non, en tout cas pas dans la version d’il y a quelques années, la dernière fois que je l’ai utilisé. C’était officiellement un vieux shell pourri conservé pour être bug compatible avec des scripts faits il y a plusieurs dizaines d’années...
Il lui manque par exemple les variables locales. Le truc, c’est qu’il y a un existant avant qu’on fasse une norme et que parfois, il en subsiste des bouts (voir la totalité : on attend toujours que les claviers Azerty s’alignent sur la norme).
OpenIndiana a bash installé par défaut, en
/bin/bash. Mais si on compte sur/bin/bash, pour le coup, on se coupe des OS BSD où il n’est pas installé par défaut.Il n’y a pas de
/bin/posixsh. Si on veut distribuer un script qu’il n’y a juste qu’à rendre exécutable pour lancer, on doit se contenter de/bin/shet il y a donc au moins un cas où il n’est pas POSIX. L’autre piste serait de chercher au début du script un shell décent sur le système et de relancer le script avec.Ah ?
$@n’était pas mentionné dans la doc à laquelle je me suis fié, mais ce n’était pas la norme officielle.Il semble que maintenant la norme POSIX soit accessible en ligne gratuitement (pas comme celle pour le clavier français...). Si elle l’était déjà il y a quelques années, je ne m’en étais pas aperçu...
Oui. C’est le shell qui n’est pas terrible. Passage des arguments par chaîne de caractères uniquement, retour de commande ou de fonction uniquement par code d’erreur et sortie standard, ça gêne pour des besoins un peu complexes et c’est sujet à bugs.
Du coup, si on utilise Perl à la place pour avoir un vrai passage de paramètres, des valeurs éventuellement complexes en retour de fonctions, des objets, etc., et pour éviter d’avoir de grosses catastrophes parce qu’on a oublié de quoter une variable et qu’il est arrivé une valeur avec des espaces dedans... et bien on a plus besoin d’AWK.
Prendre une bonne disposition : beop.free.fr