Dans mon commentaire, je dis que awk montre ses limites quand on a besoin de Unicode et tu réponds que ce n'est pas le cas parcequ'on a en pratique pas très souvent d'Unicode: c'est une réponse à côté de la plaque!
Non, dans ma réponse, je dis plusieurs choses :
tu parles d'Unicode, mais dans le contexte du travail en shell, il vaudrait mieux parler d'UTF-8, qui sera soit l'encodage Unicode des documents sources, soit pourra être obtenu en passant ceux-ci à iconv (ex. une page HTML UTF-16 peut sans problème se traduire en UTF-8) ;
les cas où on a un réel besoin de l'UTF-8 pour travailler sont rares ;
au pire, si vraiment on en a besoin, on a GAWK. qui gère (très bien) l'UTF-8 (comme lo Heirloom d'ailleurs, mais je ne sais pas ce qu'elle vaut).
Plus généralement, le problème que tu pointes n'a encore ici que peu à voir avec Unicode, mais plus avec le support de l'encodage en général. On pourrait plutôt dire que dès que tu ne peux plus supposer que l'utilisateur traite des documents en accord avec son LC_CTYPE, le shell ne convient pas (même en Perl, ce n'est pas une partie de plaisir : extraire l'encodage du source, langinfo &cie pour obtenir le charset local, configuration des différents descripteurs... )
[^] # Re: Presque d'accord ...
Posté par Ignatz Ledebur . En réponse à la dépêche Revue des techniques de programmation en shell. Évalué à -2.
Non, dans ma réponse, je dis plusieurs choses :
Plus généralement, le problème que tu pointes n'a encore ici que peu à voir avec Unicode, mais plus avec le support de l'encodage en général. On pourrait plutôt dire que dès que tu ne peux plus supposer que l'utilisateur traite des documents en accord avec son LC_CTYPE, le shell ne convient pas (même en Perl, ce n'est pas une partie de plaisir : extraire l'encodage du source, langinfo &cie pour obtenir le charset local, configuration des différents descripteurs... )