Herdar modificações de caminho vs. Herdar aliases

pathé a variável de matriz do shell que está vinculada à PATHvariável do shell que, por sua vez, está vinculada à PATHvariável de ambiente.

Ao executar um comando, toda a memória de um processo é apagada.

Variáveis ​​de ambiente são uma maneira de passar dados pela execução. Assim como os argumentos de comando, elas são uma lista de strings delimitadas por NUL, mas, ao contrário dos argumentos, por convenção:

• eles assumem a forma deVAR=values
• comandos (sejam eles shells ou qualquer outra coisa) lembram a lista de variáveis ​​de ambiente que receberam quando foram executados, e as passam adiante para os comandos que eles executam se eles ou seus filhos o fizerem, de modo a implementar uma forma de ambiente herdado e herdável. Há uma API C padrão ( putenv()variável setenv(), , unsetenv(), environ) para manter essa lista de variáveis ​​de ambiente lembradas (o environ), e para executar comandos, passando essa lista adiante ( execl(), execvp()... que são wrappers em torno da execve()chamada do sistema).

Shells especificamente, além de fazer isso, criam uma variável em sua linguagem para algumas das variáveis ​​de ambiente que recebem e cujo nome é compatível com o de uma variável de shell. E os do tipo Bourne podem promover uma variável de shell para uma variável de ambiente com o exportbuiltin (outros shells têm equivalentes).

csh, tcsh, zsh, yash e fish shells têm maneiras de vincular $PATHou outras variáveis ​​com :valores separados por - (geralmente os de ambiente, como PATH) a variáveis ​​de array.

Para efeito de comparação, o Perl (também um interpretador de linguagem de programação, mas não um shell) mapeia variáveis ​​de ambiente para seus %ENVarrays associativos (por exemplo, a PATHvariável de ambiente está disponível em $ENV{PATH}), awko mesmo que o ENVIRON["PATH"], vimtem $varpara variáveis ​​de ambiente enquanto é apenas varpara suas próprias variáveis ​​ou @xpara registradores, etc.

Para resumir, variáveis ​​de ambiente, como PATHsão algo universal, compreendido por tudo e herdado (por convenção) ao longo da execução.

Não há equivalente para aliases de shell, que é um recurso (ruim) de alguns shells (não todos) inicialmente do csh, cuja sintaxe varia de shell para shell, nem de outras estruturas de dados de qualquer linguagem.

Alguns shells como rce derivados ou bashpodem exportar suas próprias funções (também arrays em rce derivados), e para fazer isso, eles sequestram variáveis ​​de ambiente, onde a definição da função é armazenada em um formato específico, mas somente outras instâncias do mesmo shell podem carregar essas variáveis ​​do ambiente e recriar as funções (ou arrays) que eles codificaram. Essas variáveis ​​não fazem sentido para outros shells (ou perl, vim, awk...) cuja sintaxe é diferente de qualquer maneira.

Para poder passar sua lista de aliases zsh para bashque aliases bash equivalentes sejam criados, você precisa criar um código na bashlinguagem que, uma vez avaliado, recriaria esses aliases. bashe zshtêm alguma sintaxe em comum, em particular a aliassintaxe básica interna foi copiada em ambos do shell Korn em vez do csh, mas o zsh adicionou mais recursos, como aliases globais ou aliases de sufixo, e não tem as mesmas limitações do bash quando se trata de nomes de aliases, e os do bash não podem conter NULs nem no nome nem no valor, então nem todos os aliases zsh podem ser convertidos em aliases bash.

A sintaxe de aspas também é diferente entre os dois shells, embora eles entendam aspas simples da mesma maneira (desde que rcquotesnão estejam habilitadas em zsh). O zsh disponibiliza a lista de seus aliases simples na $aliasesmatriz associativa especial e, da mesma forma, bashpode despejar uma lista de definições de alias com alias -L.

Mas no último, ele nem sempre usa aspas simples e pode despejar aliases cujos nomes ou valores não funcionariam no bash, então seria melhor fazer um loop $aliases, filtrar aqueles que não funcionam bashe fazer as aspas manualmente (como com o qqsinalizador de expansão de parâmetros).