Homebrew mette il binario di OpenVPN in sbin, non nel tuo PATH

L'installazione termina, brew dice che openvpn è lì, e la shell risponde command not found. Il binario esiste, si trova in una directory di cui la shell non è mai stata informata. Homebrew collega i binari in stile demone nella directory sbin del prefisso, e un PATH predefinito di macOS di solito include la directory bin e non quella sbin. Niente è rotto, e nessuna reinstallazione lo cambierà.

Quattro controlli confermano il meccanismo prima che tu modifichi qualsiasi file di shell.

Cosa installa davvero la formula

La formula openvpn costruisce un demone da riga di comando, quindi il suo eseguibile finisce sotto sbin anziché bin. Homebrew collega poi quel binario nella directory sbin del prefisso, ed è per questo che "$(brew --prefix)/sbin/openvpn" --version funziona mentre un'invocazione nuda no. La directory Cellar con versione conserva anch'essa una copia, e mettere quel percorso in un file di avvio è il modo in cui una macchina resta bloccata su una vecchia build dopo un aggiornamento.

Il collegamento simbolico del prefisso è il percorso stabile. Il percorso Cellar è un dettaglio implementativo con un numero di versione dentro.

Chiedi a Homebrew, non al filesystem

Inizia dal gestore dei pacchetti, perché sa quale installazione possiede la formula: command -v brew, brew --prefix, brew list --versions openvpn, brew --prefix openvpn. Se l'ultimo stampa un percorso, la formula è presente e la questione riguarda solo la risoluzione. Se non stampa nulla, la shell cerca nel posto sbagliato un pacchetto che non è mai stato installato, e questo è un altro problema con un'altra soluzione.

Due installazioni di Homebrew su una macchina è dove questo conta di più: il brew che risponde non è necessariamente il brew che ha installato.

Perché la shell non vede sbin

Una shell di login costruisce PATH dai valori predefiniti di sistema più tutto ciò che aggiungono i tuoi file di avvio. Il bin di Homebrew viene comunemente aggiunto e lo sbin di Homebrew di solito no, quindi ogni comando funziona tranne i demoni. command -v openvpn che non restituisce nulla mentre il percorso con prefisso restituisce una versione è tutta la diagnosi in due comandi. Conferma che la directory contenga davvero il collegamento con ls -l "$(brew --prefix)/sbin/openvpn".

Un collegamento mancante è un guasto diverso da una voce PATH mancante, e solo uno dei due si corregge modificando un file di shell.

Correggi il percorso una volta, in un solo posto

Per una prova rapida nella shell corrente, eval "$(brew shellenv)" imposta le variabili di installazione e antepone entrambe le directory. Per un assetto permanente, metti la riga shellenv nell'unico file di avvio che la tua shell legge per la modalità di accesso che usi, invece di spargere export tra file bash e zsh.

Poi apri un nuovo terminale e ripeti la richiesta di versione, perché una shell in cache continua a riportare il vecchio PATH.

Tieni la scoperta separata dal servizio

Trovare un binario non è la stessa cosa che eseguire un servizio VPN. Avviare openvpn automaticamente aggiunge requisiti di profilo, credenziali, privilegi e ciclo di vita che la scoperta dei pacchetti non ha mai toccato. Tunnelblick include anche il proprio motore, quindi la versione appena stampata potrebbe non avere nulla a che fare con la versione che l'applicazione usa.

Annota quale eseguibile ha prodotto l'output della versione. Quella sola riga fa risparmiare un'ora la prossima volta che due versioni non concordano.