Por que não consigo definir uma variável somente leitura chamada path no zsh?

TL;DR não reutilize "parâmetros internos especiais" como pathporque uh eles são especiais. Ou de acordo com a lista de discussão , pode-se usar o -hsinalizador:

% () { local -hr path=42; echo $path }
42
% 

(No entanto, mudar pathpara um número inteiro pode atrapalhar o código subsequente que esquece essa substituição e assume que pathé path...)

Mais escavação segue (mas eu perdi totalmente a -hcoisa de esconder ...)

% print ${(t)path}
array-special

Esta é uma propriedade (recurso? bug?) de variáveis ​​especiais, mas não de variáveis ​​semelhantes vinculadas pelo usuário:

% () { typeset -r PATH=/blah; echo $PATH }
(anon): read-only variable: PATH
% typeset -Tar FOO=bar foo
% print $foo
bar
% print ${(t)foo}
array-readonly-tag_local
% () { local -r foo=blah; echo $foo }
blah

Existem vários outros parâmetros que exibem esse comportamento:

% for p in $parameters[(I)*]; do print $p $parameters[$p]; done | grep array-
cdpath array-special
...
% () { local -r cdpath=42 }
(anon): read-only variable: cdpath

Portanto, algumas variáveis ​​​​são como no Animal Farm mais especiais do que outras. Esta mensagem de erro vem de vários lugares em Src/params.cque se isso for modificado para imprimir qual mensagem é a mensagem específica que zshencontramos ao compilar:

% () { local -r path }
% () { local -r path=foo }
(anon): read-only variable (setarrvalue): path

É o código bastante genérico

/**/
mod_export void
setarrvalue(Value v, char **val)
{
    if (unset(EXECOPT))
        return;
    if (v->pm->node.flags & PM_READONLY) {
        zerr("read-only variable (setarrvalue): %s", v->pm->node.nam);
        freearray(val);
        return;
    }

Isso mostra que o problema acontece em outro lugar; as variáveis ​​não especiais sem dúvida não foram PM_READONLYdefinidas, enquanto as variáveis ​​especiais que falharam, sim. O próximo lugar óbvio para procurar é o código localque atende por uma variedade de nomes ( typeset export...). Estes são todos builtins, então podem ser encontrados à espreita nas profundezas doSrc/builtin.c

% grep BUILTIN Src/builtin.c | grep local
    BUILTIN("local", BINF_PLUSOPTS | BINF_MAGICEQUALS | BINF_PSPECIAL | BINF_ASSIGN, (HandlerFunc)bin_typeset, 0, -1, 0, "AE:%F:%HL:%R:%TUZ:%ahi:%lp:%rtux", NULL),

Todas essas chamadas bin_typesetcom vários sinalizadores definidos, então vamos estudar a fonte dessa função... xingamentos nos comentários, confira. Observa que as coisas estão complicadas, confira. Nada realmente salta à vista, embora a toca do coelho (para quando a opção "tratar argumentos como padrões" não-m estiver definida, que é o caso aqui) pareça levar à função ...typeset_single

Existe algum código POSIXBUILTINSrelacionado a readonly, mas está desativado em meus shells de teste

% print $options[POSIXBUILTINS]
off

então vou ignorar esse código (espero. Isso poderia ser um covil de shoggoth e não uma mera toca de coelho?). Enquanto isso! Alguns pontos de depuração para o PM_READONLYsinalizador sendo ativado pathpela seguinte linha

    /*
     * The remaining on/off flags should be harmless to use,
     * because we've checked for unpleasant surprises above.
     */
    pm->node.flags = (PM_TYPE(pm->node.flags) | on | PM_SPECIAL) & ~off;

Que por sua vez vem da onvariável que por sua vez já está ativada quando a typeset_singlefunção é inserida, suspiro, então bin_typesetvamos lá... ok, basicamente tem um TYPESET_OPTSTRque de alguma forma via algumas macros habilita PM_READONLYpor padrão; quando, em vez disso, uma variável fornecida pelo usuário é executada por esse caminho de código, ela PM_READONLYé desativada e tudo está bem.

Se isso pode ser alterado para que variáveis ​​especiais, como pathsejam feitas somente leitura, é uma questão para um desenvolvedor ZSH (tente a lista de discussão zsh-workers?) Caso contrário, enquanto isso, não mexa com as variáveis ​​especiais.