Por que 'env var = value' permite nome arbitrário em var?

Question

Lendo documentação do env POSIX :

Some have suggested that env is redundant since the same effect is achieved by:

name=value ... utility [ argument ... ]

The example is equivalent to env when an environment variable is being added to the environment of the command, but not when the environment is being set to the given value. The env utility also writes out the current environment if invoked without arguments. There is sufficient functionality beyond what the example provides to justify inclusion of env.

AFAICT, a declaração acima que significa var=value command será igual a env var="value" command e não quando usar como env -i var="value" command .

Agora, pelo menos com a implementação de env no sistema GNU, FreeBSD e Solaris 11, percebo que eles não são equivalentes, porque env permite todos os caracteres, exceto = e var in BASH_FUNC_foo%%='() { echo foo; }' nome:

$ env 'BASH_FUNC_foo%%=() { echo foo; }' bash -c foo

print foo , enquanto você não pode usar BASH_FUNC_foo%% em qualquer shells, porque bash claramente não é um nome de variável válido.

Em shells POSIX, exceto BASH_FUNC_foo%% , isso deixou uma variável chamada env var=value em variáveis de ambiente, que o shell não pode acessá-lo.

Então, qual é o propósito de permitir o nome arbitrário no formulário %code% e foi permitido pelo POSIX?

    

Answer 1

So, what is the purpose of allowing arbitrary name in form env var=value and was it allowed by POSIX?

Citações de POSIX: Variáveis de ambiente :

Environment variable names used by the utilities in the Shell and Utilities volume of POSIX.1-2008 consist solely of uppercase letters, digits, and the ( '_' ) from the characters defined in Portable Character Set and do not begin with a digit. Other characters may be permitted by an implementation; applications shall tolerate the presence of such names.

Note: Other applications may have difficulty dealing with environment variable names that start with a digit. For this reason, use of such names is not recommended anywhere.

Portanto, implementações de env podem permitir nomes arbitrários de variáveis de ambiente - ea maioria, se não todas, implementações o fazem, aceitando todos os caracteres não-NUL à esquerda de um '=' - e implementações de outros utilitários (como o shell) pode ou não permitir nomes arbitrários.

A declaração de que name=value ... utility é equivalente a env var="value" utility só será verdadeira se a implementação de env e o shell permitirem que name seja uma variável de ambiente.

Há um tópico interessante do Grupo Austin sobre esse assunto aqui: Invalid shell atribuições no ambiente . Um ponto mencionado é que as shells geralmente permitem apenas variáveis de ambiente cujos nomes podem ser representados como variáveis de shell. Vários participantes desse segmento participam do unix.stackexchange.com e podem adicionar mais informações sobre o assunto.

    

Answer 2

Você é verdadeiro, env permite colocar coisas no ambiente que podem não ser válidas para um shell. Não vejo problema com esse fato, pois env é um programa separado e o ambiente não está limitado ao que um shell aceita como shell variables .

Olhando um pouco mais de perto os resultados mostram que nenhum dos shells usuais se comporta de uma maneira que resulta em variáveis de shell inacessíveis:

• O Bourne Shell não importa nem não propaga essas variáveis

• ksh (todas as versões desde o ksh88) e zsh apenas mantêm as variáveis no ambiente, mas não as propagam para a lista de variáveis do shell

O único shell problemático parece ser bash , pois importa o ambiente para a lista de variáveis do shell, mas não permite acessar a variável do shell relacionado.

Eu recomendo que você faça um relatório de bug contra o bash.