IFS nulo não é o mesmo que IET não configurado?

Question

Li uma ótima pergunta aqui chamada Noções básicas sobre o IFS . Fiquei surpreso porque as respostas e comentários citam o POSIX, que afirma que o IFS = não é o mesmo que desabilitar o IFS. Se você desabilitar o IFS, aparentemente, o valor padrão será usado. Se você fizer o IFS nulo, não haverá divisor. Eu sabia que tinha visto uma opinião diferente sobre isso e achei isso em meus favoritos:

Programação Bourne Shell

$IFS

The very first statement in your script should be

IFS=

which resets the input field separator to its default value. Otherwise, you inherit $IFS from the user, who may have set it to some bizarre value in order to make sh parse strings differently from the way you expect, and induce weird behavior.

Então isso foi verdade há algum tempo ou o autor está errado?

    

Answer 1

As respostas encontradas no Stack Exchange estão corretas e este tutorial está errado. Você pode fazer experiências sozinho ou pesquisá-lo no padrão . Um unset IFS é equivalente a defini-lo para o valor padrão de space-tab-newline, enquanto um IFS vazio desativa efetivamente a divisão de campos.

Você pode consultar a página de Sven Mascheck sobre IFS sobre implementações históricas. Algumas shells históricas não gostavam de unset IFS , e uma versão muito antiga do ksh tratava-a como uma IFS vazia, mas todas as shells modernas e a maioria das shells antigas tratam uns unset IFS como o valor padrão.

Você não deve iniciar seu script com IFS= , a menos que queira desmembrar campos (o que pode ser uma decisão razoável, mas observe que ainda é preciso colocar aspas duplas em torno das substituições para evitar a globulação, a menos que você desative isso com set -f também). Para redefinir o valor padrão, use unset IFS . É discutível se isso é útil no início de um script; há muitas outras coisas ruins, como um PATH desonesto que o chamador pode fazer para errar o seu script.

Este tutorial também aconselha a redefinir PATH . Isso geralmente é um mau conselho. Na maioria dos casos, você não pode prever qual é o caminho de pesquisa correto, mas o usuário sabe. Como você sabe se /usr/local/bin ou /home/bob/bin contém versões fixas de bug de utilitários em um antigo unix, onde as que estão em /usr/bin têm bugs? Você realmente deseja incorporar toda a lógica para descobrir se colocar /usr/xpg6/bin à frente de /bin ? Em qual posição você quer /usr/gnu/bin ? Não restaure o PATH, a menos que seu script tenha como alvo um sistema específico.

Eu não li este tutorial, mas verifiquei uma coisa: ele não lhe diz desde o começo para sempre colocar aspas duplas em torno de substituições de variáveis e substituições de comandos. Então eu não acho que este tutorial seja bom.