J'ai lu ceci dans le manuel de Gawk :
EXTENSIONS GNU
[…]
La possibilité de diviser des caractères individuels en utilisant la chaîne nulle comme valeur
de FS et comme troisième argument de split().
Cependant, cela ne semble pas être le cas. Cela fonctionne comme prévu :
$ gawk 'BEGIN {print split("quebec", z, "")}'
6
et je peux désactiver d'autres extensions :
$ export POSIXLY_CORRECT
$ gawk 'BEGIN {typeof(1)}'
gawk: cmd. line:1: fatal: function `typeof' not defined
mais je ne peux pas désactiver le comportement de fractionnement :
$ export POSIXLY_CORRECT
$ gawk 'BEGIN {print split("quebec", z, "")}'
6
$ gawk --posix 'BEGIN {print split("quebec", z, "")}'
6
J'ai aussi regardé le manuel de Mawk :
Si FS ="", alors mawk divise l'enregistrement en caractères individuels et,
de même, split(s,A,"") place les caractères individuels de s dans A.[…]
Posix laisse explicitement le comportement de FS ="" indéfini et mentionne
la division de l'enregistrement en caractères comme une interprétation possible, mais
actuellement cette utilisation n'est pas portable d'une implémentation à l'autre.
Alors, avec quelles implémentations ne pouvez-vous pas obtenir des caractères uniques avec FS etsplit ?
Réponse acceptée :
Ce n'est pas POSIX dans la mesure où vous ne pouvez pas l'utiliser dans les scripts POSIX car POSIX laisse le comportement non spécifié . Cela signifie que si une application (un script) ne peut pas l'utiliser si elle veut être portable, une implémentation (un awk implémentation) peut faire ce qu'il veut si vous le faites et toujours être POSIX. POSIX ne nécessite pas awk pour diviser en caractères ou en octets, ou signaler une erreur, ou redémarrer l'ordinateur, il le laisse non spécifié.
Alors gawk n'a aucune raison de modifier son comportement à cet égard lorsque $POSIXLY_CORRECT se trouve dans l'environnement¹, aucun comportement n'est plus POSIX correct que l'autre dans cette instance.
Comme vous l'avez découvert, cette extension se trouve dans gawk (depuis la version 3.0, janvier 1996) et mawk (depuis la version 1.2, janvier 1996). C'est aussi dans busybox awk (depuis le début (2002)), et depuis mai 1996 également dans celui maintenu par Brian Kernighan (le k dans awk ) (les FIXES le fichier fait référence à gawk , etc. comme source d'inspiration). Il semble qu'il ait été ajouté aux 3 en quelques mois, ce qui suggère que cela a peut-être été discuté entre leurs mainteneurs. Je ne sais plus trop qui a eu l'idée en premier.
Avec awk de Brian Kernighan ou ceux basés dessus comme sur FreeBSD ou OpenBSD, notez que tant qu'un FS vide ou un troisième argument vide passé à split() provoque la division de la chaîne en ses caractères individuels (enfin, octets , voir ci-dessous), awk -F '' renvoie une erreur (awk -v FS= est OK cependant).
Sur Solaris, avec les deux nawk et /usr/xpg4/bin/awk (ainsi que l'ancien /bin/awk des années 70), un FS vide semble désactiver complètement le fractionnement. nawk -F '' renvoie une erreur. Je m'attendrais à ce que ce soit la même chose sur d'autres Unix commerciaux basés sur le code AT&T comme AIX ou HP/UX, bien que je ne puisse pas le tester là-bas.
Notez également que mawk , awk de bwk (c'est différent pour certains basés dessus) et busybox awk ne prennent pas en charge les caractères multi-octets. Ainsi, par exemple, en UTF-8 :
echo Stéphane | awk -v FS= '{print $4}'
imprimerait la seconde moitié du troisième caractère de mon prénom. Donc, avec ceux-ci, il est plus correct de dire qu'un FS vide se divise en octets individuels, pas en caractères.
¹ Je réalise maintenant qu'avec POSIXLY_CORRECT, ou --posix , gawk désactive certaines extensions qui, autrement, n'entrent pas en conflit avec POSIX (typeof fait gawk non conforme cependant), on pourrait donc dire que c'est une omission. Maintenant, ce ne serait pas le premier. Par exemple, il ne désactive pas nextfile même s'il est en conflit avec POSIX (awk '{nextfile = 1}' est censé attribuer 1 au nextfile variable mais signale une erreur dans gawk même sous POSIXLY_CORRECT).