IFS null n'est pas le même que IFS non défini?

J'ai lu ici une grande question intitulée Comprendre IFS . J'ai été surpris parce que les réponses et les commentaires citent POSIX qui déclare que IFS = n'est pas la même chose que désarmer IFS. Si vous désactivez IFS, la valeur par défaut est apparemment utilisée. Si vous désactivez IFS à la place, il n'y a pas de séparateur. Je savais que j'avais vu un point de vue différent à ce sujet, et je l'ai trouvé dans mes signets:

Programmation Bourne Shell

$ IFS

La toute première instruction de votre script doit être

IFS =

qui réinitialise le séparateur de champ de saisie à sa valeur par défaut. Sinon, vous héritez de $ IFS de l'utilisateur, qui peut l'avoir défini sur une valeur bizarre afin de rendre les chaînes d'analyse sh différemment de ce que vous attendez, et induire un comportement étrange.

Etait-ce vrai il y a quelque temps ou est-ce que l'auteur a tout simplement tort?

Les réponses que vous avez trouvées sur Stack Exchange sont correctes et ce tutoriel est faux. Vous pouvez expérimenter par vous-même ou le rechercher dans la norme . Un unset IFSéquivaut à lui attribuer la valeur par défaut de space-tab-newline, tandis qu'un vide IFSdésactive efficacement la division du champ.

Vous pouvez consulter la page de Sven Mascheck sur IFS à propos des implémentations historiques. Quelques shells historiques n'aimaient pas unset IFS, et une très ancienne version de ksh le traitait comme un vide IFSmais tous les shells modernes et la plupart des vieux shells traitaient un unset IFScomme la valeur par défaut.

Vous ne devez pas commencer votre script à IFS=moins que vous ne souhaitiez désactiver la division des champs (ce qui peut être une décision raisonnable - mais notez que vous devez toujours mettre des guillemets autour des substitutions pour éviter la globalisation, à moins que vous ne désactiviez cela set -fégalement). Pour réinitialiser la valeur par défaut, utilisez unset IFS. On peut se demander si cela est utile au début d'un script; il y a beaucoup d'autres mauvaises choses, comme une douteuse, PATHque l'appelant peut faire pour que votre script se passe mal.

Ce tutoriel conseille également de réinitialiser PATH. C'est généralement un mauvais conseil. Dans la plupart des cas, vous ne pouvez pas prédire le chemin de recherche correct, mais l'utilisateur le sait. Comment savez-vous si /usr/local/binou /home/bob/bincontient des versions d'utilitaires corrigées de bogues sur un ancien Unix où ceux en /usr/binsont bogués? Voulez-vous vraiment intégrer toute la logique pour savoir s'il faut prendre de l' /usr/xpg6/binavance /bin? À quelle position vous voulez /usr/gnu/bin? Ne réinitialisez pas PATH sauf si votre script cible un système spécifique.

Je n'ai pas lu ce tutoriel, mais j'ai vérifié une chose: il ne vous dit pas dès le départ de toujours mettre des guillemets autour des substitutions de variables et des substitutions de commandes. Je ne pense donc pas que ce tutoriel soit bon.