Homebrew legt das OpenVPN-Binary in sbin ab, nicht in deinen PATH
Die Formel installiert den OpenVPN-Daemon unter sbin, das ein Standard-PATH unter macOS nicht enthält. Prüfe das Präfix und behebe dann die Auflösung in einer Datei.
Die Installation endet, brew meldet, openvpn sei vorhanden, und die Shell antwortet command not found. Das Binary existiert, es liegt in einem Verzeichnis, von dem die Shell nie erfahren hat. Homebrew verlinkt Binaries im Daemon-Stil in das sbin-Verzeichnis des Präfixes, und ein Standard-PATH unter macOS enthält normalerweise das bin-Verzeichnis und nicht das sbin-Verzeichnis. Nichts ist defekt, und keine Neuinstallation wird das ändern.
Vier Prüfungen bestätigen den Mechanismus, bevor du irgendeine Shell-Datei bearbeitest.
Was die Formel tatsächlich installiert
Die openvpn-Formel baut einen Kommandozeilen-Daemon, deshalb landet ihre ausführbare Datei unter sbin statt unter bin. Homebrew verlinkt dieses Binary dann in das sbin-Verzeichnis des Präfixes, und deshalb funktioniert "$(brew --prefix)/sbin/openvpn" --version, während ein bloßer Aufruf es nicht tut. Das versionierte Cellar-Verzeichnis enthält ebenfalls eine Kopie, und diesen Pfad in eine Startdatei zu schreiben ist der Weg, wie eine Maschine nach einem Upgrade an einen alten Build gebunden bleibt.
Der Präfix-Symlink ist der stabile Pfad. Der Cellar-Pfad ist ein Implementierungsdetail mit einer Versionsnummer darin.
Frag Homebrew, nicht das Dateisystem
Beginne beim Paketmanager, denn er weiß, welche Installation die Formel besitzt: command -v brew, brew --prefix, brew list --versions openvpn, brew --prefix openvpn. Wenn der letzte Befehl einen Pfad ausgibt, ist die Formel vorhanden, und die Frage betrifft allein die Auflösung. Wenn er nichts ausgibt, sucht die Shell am falschen Ort nach einem Paket, das nie installiert wurde, und das ist ein anderes Problem mit einer anderen Lösung.
Zwei Homebrew-Installationen auf einer Maschine sind der Fall, in dem das am meisten zählt: das brew, das antwortet, ist nicht unbedingt das brew, das installiert hat.
Warum die Shell sbin nicht sieht
Eine Login-Shell baut PATH aus den Systemvorgaben plus allem, was deine Startdateien anhängen. Homebrew bin wird üblicherweise hinzugefügt und Homebrew sbin üblicherweise nicht, deshalb funktioniert jeder Befehl außer den Daemons. command -v openvpn, das nichts zurückgibt, während der Pfad mit Präfix eine Version zurückgibt, ist die ganze Diagnose in zwei Befehlen. Bestätige mit ls -l "$(brew --prefix)/sbin/openvpn", dass das Verzeichnis den Link wirklich enthält.
Ein fehlender Link ist ein anderer Fehler als ein fehlender PATH-Eintrag, und nur einer von beiden wird durch Bearbeiten einer Shell-Datei behoben.
Behebe den Pfad einmal, an einer Stelle
Für einen schnellen Test in der aktuellen Shell setzt eval "$(brew shellenv)" die Installationsvariablen und stellt beide Verzeichnisse voran. Für eine dauerhafte Einrichtung legst du die shellenv-Zeile in die eine Startdatei, die deine Shell für den verwendeten Login-Modus liest, statt Exporte über bash- und zsh-Dateien zu verteilen.
Öffne dann ein neues Terminal und wiederhole die Versionsabfrage, denn eine zwischengespeicherte Shell meldet weiterhin den alten PATH.
Halte die Erkennung vom Dienst getrennt
Ein Binary zu finden ist nicht dasselbe wie einen VPN-Dienst zu betreiben. Openvpn automatisch zu starten fügt Anforderungen an Profil, Anmeldedaten, Rechte und Lebenszyklus hinzu, die die Paketerkennung nie berührt hat. Tunnelblick bringt zudem eine eigene Engine mit, sodass die gerade ausgegebene Version nichts mit der Version zu tun haben muss, die die Anwendung verwendet.
Notiere, welche ausführbare Datei die Versionsausgabe erzeugt hat. Diese eine Zeile spart eine Stunde, wenn zwei Versionen das nächste Mal auseinandergehen.