O Homebrew coloca o binário do OpenVPN em sbin, não no seu PATH

A instalação termina, o brew diz que o openvpn está lá, e a shell responde command not found. O binário existe, só está num diretório sobre o qual a shell nunca foi informada. O Homebrew liga binários ao estilo daemon no diretório sbin do prefixo, e um PATH padrão do macOS normalmente inclui o diretório bin e não o sbin. Nada está avariado, e nenhuma reinstalação mudará isso.

Quatro verificações confirmam o mecanismo antes de editar qualquer ficheiro de shell.

O que a fórmula instala realmente

A fórmula openvpn compila um daemon de linha de comandos, por isso o seu executável fica em sbin em vez de bin. O Homebrew liga depois esse binário no diretório sbin do prefixo, e é por isso que "$(brew --prefix)/sbin/openvpn" --version funciona enquanto uma invocação simples não funciona. O diretório Cellar com versão também guarda uma cópia, e colocar esse caminho num ficheiro de arranque é a forma como uma máquina fica presa a uma compilação antiga após uma atualização.

A ligação simbólica do prefixo é o caminho estável. O caminho do Cellar é um detalhe de implementação com um número de versão dentro.

Pergunte ao Homebrew, não ao sistema de ficheiros

Comece pelo gestor de pacotes, porque ele sabe qual instalação possui a fórmula: command -v brew, brew --prefix, brew list --versions openvpn, brew --prefix openvpn. Se o último imprimir um caminho, a fórmula está presente e a questão é só de resolução. Se não imprimir nada, a shell procura no sítio errado um pacote que nunca foi instalado, e isso é outro problema com outra correção.

Duas instalações do Homebrew numa máquina é onde isto mais importa: o brew que responde não é necessariamente o brew que instalou.

Porque é que a shell não vê o sbin

Uma shell de login constrói o PATH a partir dos padrões do sistema mais tudo o que os seus ficheiros de arranque acrescentam. O bin do Homebrew é vulgarmente adicionado e o sbin do Homebrew normalmente não, por isso todos os comandos funcionam exceto os daemons. command -v openvpn que não devolve nada enquanto o caminho com prefixo devolve uma versão é todo o diagnóstico em dois comandos. Confirme que o diretório contém mesmo a ligação com ls -l "$(brew --prefix)/sbin/openvpn".

Uma ligação em falta é uma avaria diferente de uma entrada PATH em falta, e só uma das duas se corrige editando um ficheiro de shell.

Corrija o caminho uma vez, num único sítio

Para um teste rápido na shell atual, eval "$(brew shellenv)" define as variáveis de instalação e coloca os dois diretórios à frente. Para uma configuração permanente, ponha a linha shellenv no único ficheiro de arranque que a sua shell lê para o modo de início de sessão que usa, em vez de espalhar exports pelos ficheiros bash e zsh.

Depois abra um novo terminal e repita o pedido de versão, porque uma shell em cache continua a reportar o PATH antigo.

Mantenha a descoberta separada do serviço

Encontrar um binário não é o mesmo que executar um serviço VPN. Iniciar o openvpn automaticamente acrescenta requisitos de perfil, credenciais, privilégios e ciclo de vida que a descoberta de pacotes nunca tocou. O Tunnelblick também traz o seu próprio motor, por isso a versão que acabou de imprimir pode não ter nada a ver com a versão que a aplicação usa.

Registe qual executável produziu a saída de versão. Essa única linha poupa uma hora da próxima vez que duas versões discordarem.