A expansão aritmética é relacionada ao IFS de alguma forma?

0

De link

arithmetic expansions are also subject to split+glob so should also be quoted (shift "$((OPTIND - 1))") (here not a problem though as you're using bash which doesn't inherit $IFS from the environment and you're not modifying IFS earlier in the script, but still good practice).

A expansão aritmética está relacionada ao IFS de alguma forma?

    
por Tim 25.07.2018 / 07:24

1 resposta

3

O resultado de uma expansão aritmética sem aspas passa pelo agrupamento de nomes de arquivos (expansão de caractere curinga) e divisão de palavras (campo), como qualquer outro expansão sem aspas . É bastante inútil e alguns shells não fazem isso, mas é o que shells históricos fizeram (porque era mais fácil de implementar) e é o que o POSIX padronizou.

O resultado de uma expansão aritmética é apenas uma string de - e dígitos, portanto, ele nunca pode conter um caractere curinga. (Alguns shells têm ponto flutuante e também podem incluir . , + e letras.) Como não pode conter espaço em branco, normalmente não está sujeito a divisão de campo. No entanto, a divisão de campo é configurável por meio de IFS : os separadores de campo são os caracteres de IFS . Incluir dígitos em IFS é extremamente raro e é uma coisa muito boba de se fazer, mas se você quiser escrever um código totalmente robusto, você precisa se proteger contra isso. Isso é mais importante se o resultado pode ser negativo, porque incluir um traço em IFS não é tão bobo.

POSIX afirma que o shell deve definir IFS como seu valor padrão quando for iniciado, para que os scripts não sejam afetados por um valor IFS que possa estar no ambiente. (É incomum exportar IFS , mas alguém poderia fazer isso.) No entanto, alguns shells comuns (traço, Busybox sh) mantêm qualquer valor de IFS no ambiente, portanto, um script de shell robusto deve definir explicitamente IFS ao valor padrão (ou desfeito, que tem o mesmo efeito) se contiver qualquer expansão sem aspas.

    
por 25.07.2018 / 08:09