Homebrew place le binaire OpenVPN dans sbin, pas dans votre PATH

L'installation se termine, brew annonce qu'openvpn est là, et le shell répond command not found. Le binaire existe, il se trouve dans un répertoire dont le shell n'a jamais été informé. Homebrew lie les binaires de type démon dans le répertoire sbin du préfixe, et un PATH macOS par défaut inclut généralement le répertoire bin et non celui de sbin. Rien n'est cassé, et aucune réinstallation n'y changera quoi que ce soit.

Quatre vérifications confirment le mécanisme avant que vous ne modifiiez le moindre fichier de shell.

Ce que la formule installe réellement

La formule openvpn construit un démon en ligne de commande, son exécutable atterrit donc sous sbin plutôt que sous bin. Homebrew lie ensuite ce binaire dans le répertoire sbin du préfixe, et c'est pourquoi "$(brew --prefix)/sbin/openvpn" --version fonctionne alors qu'un appel nu ne fonctionne pas. Le répertoire Cellar versionné conserve aussi une copie, et mettre ce chemin dans un fichier de démarrage est la façon dont une machine reste épinglée à une ancienne compilation après une mise à jour.

Le lien symbolique du préfixe est le chemin stable. Le chemin Cellar est un détail d'implémentation avec un numéro de version à l'intérieur.

Interrogez Homebrew, pas le système de fichiers

Commencez par le gestionnaire de paquets, car il sait quelle installation possède la formule : command -v brew, brew --prefix, brew list --versions openvpn, brew --prefix openvpn. Si le dernier affiche un chemin, la formule est présente et la question ne porte que sur la résolution. S'il n'affiche rien, le shell cherche au mauvais endroit un paquet qui n'a jamais été installé, et c'est un autre problème avec une autre solution.

Deux installations de Homebrew sur une même machine, voilà où cela compte le plus : le brew qui répond n'est pas forcément celui qui a installé.

Pourquoi le shell ne voit pas sbin

Un shell de connexion construit PATH à partir des valeurs par défaut du système plus tout ce que vos fichiers de démarrage ajoutent. Le bin de Homebrew est couramment ajouté et le sbin de Homebrew ne l'est généralement pas, donc chaque commande fonctionne sauf les démons. command -v openvpn qui ne renvoie rien tandis que le chemin préfixé renvoie une version, c'est tout le diagnostic en deux commandes. Confirmez que le répertoire contient bien le lien avec ls -l "$(brew --prefix)/sbin/openvpn".

Un lien manquant est une autre panne qu'une entrée PATH manquante, et une seule des deux se corrige en modifiant un fichier de shell.

Corrigez le chemin une fois, à un seul endroit

Pour un test rapide dans le shell courant, eval "$(brew shellenv)" définit les variables d'installation et place les deux répertoires en tête. Pour un réglage permanent, mettez la ligne shellenv dans le seul fichier de démarrage que votre shell lit pour le mode de connexion que vous utilisez, au lieu de disperser des exports dans les fichiers bash et zsh.

Ouvrez ensuite un nouveau terminal et répétez la requête de version, car un shell en cache continue de signaler l'ancien PATH.

Gardez la découverte séparée du service

Trouver un binaire n'est pas la même chose que faire tourner un service VPN. Lancer openvpn automatiquement ajoute des exigences de profil, d'identifiants, de privilèges et de cycle de vie que la découverte de paquets n'a jamais touchées. Tunnelblick embarque aussi son propre moteur, donc la version que vous venez d'afficher n'a peut-être rien à voir avec celle que l'application utilise.

Notez quel exécutable a produit la sortie de version. Cette seule ligne fait gagner une heure la prochaine fois que deux versions divergent.