Zsh: Coloca todos os parâmetros não globais na função interna anônima / local

Question

Corrija-me se esta afirmação estiver errada: Todas as variáveis / parâmetros definidos dentro de um script zsh mantêm seu escopo persistente globalmente na sessão atual do shell.

Se a afirmação acima for verdadeira, evite mexer nas variáveis de ambiente do shell atual / outros scripts zsh. Devemos colocar todas as variáveis / parâmetros de um script zsh na função interna anônima / local, se possível?

As possibilidades podem ser contadas como:

1. Usamos essas variáveis imediatamente nesse escopo local = > função anônima
2. Marque seu escopo usando o criador always = > func interno usando always
3. Marque, mas use as armadilhas usadas raramente para marcar = > func interno usando armadilhas

A questão e o propósito é que todas as variáveis / parâmetros devem ser locais dentro de um script zsh e devem ser destruídos após serem usados dentro do script zsh.

EDIT: Eu confundi sobre runing e sourcing script de shell.

Eu quero source de um script dentro de um script, mas tento continuar minimizando o efeito do script de fornecimento para atrapalhar o ambiente do script de chamada.

@ Stéphane Chazelas respondeu a pergunta, mas eu gostaria de deixar claro como entendi, corrija se eu estiver errado.

A execução de um script de shell dentro de um script de shell ./script.zsh invocará um novo shell para executar o script e, em seguida, retornará o código de saída para o script de chamada.

O fornecimento de um script de shell dentro de um script de shell . ./script.zsh criará um subprocesso do shell atual e quaisquer alterações - definir novas variáveis, funções .. serão colocadas no ambiente do shell atual, esse é o comportamento esperado porque na maioria das vezes usuário quer usá-los após o processo de terceirização, mas você pode excluir partes indesejadas usando a função anônima como @ Stéphane Chazelas mencionado no comentário. Com nota que alias sempre aparece com escopo global.

    

Answer 1

Não, quando você executa um script, seu shell cria um novo processo no qual o interpretador desse script é executado para interpretar o conteúdo desse script.

Qualquer atribuição de variável afetará apenas as variáveis do shell de essa invocação do shell no processo esse . Depois que esse processo morrer, as variáveis do shell de chamada não serão afetadas.

A única exceção que eu sei é com o fish shell ao usar set -U var value para definir fish variáveis universais , onde fish passa o valor da variável usando algum mecanismo IPC entre processos executando fish e usam armazenamento permanente para reter o valor da variável quando nenhum processo fish estiver sendo executado.

Agora, quando você gera um script (em oposição a executá-lo ) com o comando . ou source builtin dentro do seu shell, então diga > seu shell para interpretar o código nesse script (não há subprocesso envolvido aqui, . ./script.zsh é semelhante a eval "$(<script.zsh)" ). Mas, em seguida, você geralmente usa apenas source quando faz as atribuições de variáveis que afetam o seu shell, como quando arquivos de ambiente sourcing .

Agora você pode imaginar scripts criados para serem usados em algumas variáveis , funções , aliases ... a serem definidos em o shell de chamada, mas alguns que são apenas variáveis auxiliares que não são. E então sim, você poderia usar uma função anônima com escopo local como:

myfunc() echo hi # function meant to be defined for the invoker
myvar=value  # same for a variable

(){ local i # i variable local
  for i in foo bar
    alias $i='echo x' # alias defined globally
  done
}

(note que o zsh apenas implementa o escopo local para variáveis e opções, não para funções, aliases ...)