Não há funções privadas, portanto, funcionará se _other_command_helper_func
já estiver carregado. Como as funções de conclusão são normalmente carregadas automaticamente, isso significa que, com essa abordagem, a conclusão de wrapper
só funcionará se a conclusão do comando original já tiver sido tentada.
Uma solução é forçar o carregamento do arquivo de função de conclusão do comando original, mas isso não é simples. Você pode usar autoload -X +U
para carregar o completer para o comando original, mas o que isso de fato faz é criar uma função _other_command
(supondo que seja o nome do comando original) cuja definição é o conteúdo do arquivo _other_command
, consistindo na definição de funções auxiliares e outra inicialização seguida de uma chamada para a função principal.
_other_command () {
_other_command_helper_func () {
…
}
_other_command () {
…
}
_other_command "$@"
}
Você poderia tentar analisar isso. Se a definição estiver sob seu controle, você pode fazer algumas suposições sobre o código de inicialização. Se vier de um terceiro, é mais arriscado. A maioria dos arquivos de definição de função de conclusão complexos seguem o modelo de inicialização seguido por uma última linha do formulário _main_function "$@"
, então isso geralmente funcionará:
if ((!$+functions[_other_command_helper_func])); then
autoload -X +U _other_command
functions[_other_command]=${functions[_other_command]%$'\n'*}
_other_command
fi
Como alternativa, você pode simplesmente executar a função de conclusão no seu .zshrc
e permitir que ela seque silenciosamente porque não foi executada em um contexto de conclusão. Por exemplo, eu tive esse problema preciso com o CVS; Eu coloquei _cvs 2>/dev/null
no meu .zshrc
.
Se a definição do original está sob o seu controle, então existem soluções melhores. Você poderia usar a mesma função de conclusão para o comando original e para o wrapper (verifique $service
para ver quais argumentos do comando estão sendo concluídos). Ou você pode definir a função auxiliar em um arquivo separado.