Por que definir uma variável somente leitura no escopo externo impede a definição de uma variável local com o mesmo nome?

Se readonlyem um escopo impedirá que uma variável com o mesmo nome seja declarada em escopos filhos (nos shells que possuem escopo dinâmico, como bash) varia entre os shells¹.

Isso surgiu durante as discussões do grupo de Austin sobre a especificação localdo escopo para variáveis ​​no POSIXsh (um esforço agora abandonado porque a obtenção de um consenso (sobre muitos outros aspectos) se mostrou impossível).

No bash, isso é intencional e o mantenedor disse que não mudaria isso (pelo menos não no ambiente padrão), pois é considerado uma medida de segurança.

readonlypode ser usado para duas finalidades não totalmente compatíveis:

1. como uma ferramenta de desenvolvimento para definir constantes globais que não devem ser alteradas, então você será avisado quando seu código tentar e poderá corrigi-lo (um pouco como o constde C, embora aqui isso aconteça em tempo de execução).
2. como uma medida de segurança em shells restritos (um recurso de segurança de sandbox muito ruim) onde algumas variáveis ​​especiais, como $PATH, $HISTFILE(embora um administrador que queira fornecer um ambiente de shell restrito provavelmente deseje definir mais variáveis ​​somente leitura, como LD_PRELOAD, PERL5LIB...) precisaria permanecer somente leitura para evitar que os usuários contornassem as restrições.

No bash, as modificações de $PATH(que possui os únicos comandos permitidos) em shells restritos dependem do readonlyatributo, por isso é importante que essas variáveis ​​não possam ser modificadas (incluindo sua lista de atributos ou escopos) mesmo em escopos filhos.

No zsh, $PATHe algumas outras variáveis ​​(incluindo LD_PRELOAD, mas não PERL5LIB, PYTHONPATH...) são restritas , mas não por meio do atributo somente leitura, portanto, readonlypodem ser usadas de forma confiável para o primeiro uso mencionado acima, mas isso significa que se o seu restrito- ambiente tem alguns comandos escritos em perlou python, os usuários podem ignorar as restrições por meio das variáveis PERL5LIB​​/ PYTHONPATHambiente, por exemplo, e torná-los somente leitura não ajudará, pois os usuários podem fazer typeset +r PERL5LIBpara remover esse atributo somente leitura ou sombreá-lo em um escopo filho com um não -somente leitura um.

^{¹ Consulte Lista de shells que suportam a palavra-chave `local` para definir variáveis ​​locais para obter mais detalhes sobre o escopo local em vários shells do tipo POSIX.}

O problema subjacente aqui é que a localpalavra-chave não cria realmente uma variável local, ou pelo menos não no sentido que você espera.

De acordo com o Manual de Referência do Bash :

Variáveis ​​locais para a função podem ser declaradas com o localbuiltin ( variáveis ​​locais ). Normalmente, as variáveis ​​e seus valores são compartilhados entre uma função e seu chamador. Essas variáveis ​​são visíveis apenas para a função e os comandos que ela invoca . Isto é particularmente importante quando uma função shell chama outras funções.

e

localsó pode ser usado dentro de uma função; faz com que o nome da variável tenha um escopo visível restrito àquela função e seus filhos .

(onde negrito representa minha ênfase).

Em termos de ciência da computação, o Bash usa escopo dinâmico em vez de escopo léxico ; mas do ponto de vista de um programador típico que vive no ano de 2024, o que isto realmente significa é que localnão cria uma variável local, apenas modifica temporariamente a variável global. Sua mágica especial é restaurar automaticamente o valor original da variável (e outras propriedades) quando a função retorna, o que é útil, mas não é uma implementação completa de "variáveis ​​locais" no sentido que você espera.

Então, se localpudesse substituir readonly, algo assim:

readonly three=3

print_three() {
  echo "$three"
}

print_four() {
  local three=4

  print_three
}

print_four

imprimiria 4em vez de 3- a variável threenão seria realmente somente leitura.

Como Stéphane Chazelas aponta em sua resposta, alguns shells permitem override . Mas eu diria que isso é um erro em qualquer shell que tenha o mesmo comportamento básico do Bash (ou seja, modificar temporariamente uma variável global em vez de criar uma variável local separada), e esse comportamento realmente entra em conflito com a intenção de . Só posso supor que a motivação deles era fazer com que as variáveis ​​fossem um pouco mais parecidas com variáveis ​​locais verdadeiras, mas isso não ajuda, desde que não sejam verdadeiramente locais.localreadonlylocalreadonlylocal

Isto está documentado localem

www.gnu.org/software/bash/manual/bash.html#Bash-Builtins

O status de retorno é zero, a menos que local seja usado fora de uma função, um nome inválido seja fornecido ou name seja uma variável somente leitura.

Acho isso surpreendente, pois a primeira frase diz:

Para cada argumento, uma variável local chamada nome é criada e um valor é atribuído.

Isso implica que uma nova variável é criada com escopo restrito a essa função. Há um argumento de que uma constante global deve ser preservada de forma confiável.